I don’t think the opposite of “novelty for novelty’s sake” should be “tradition for tradition’s sake”. I like the choose boring technology post because that author allows that sometimes, the usual way of doing things is “expensive and difficult” and in those cases it makes sense to be more adventurous in solution choice. I wouldn’t necessarily always pick the same “boring except where you spent your innovation tokens” approach but it’s a position that is reasoned rather than reactionary.
Agreed, I was actually almost on the authors side until I read the examples, all of which are extremely subjective. Microservices, NoSQL, and SPA’s all make sense in some contexts, and both sides of those dichotomies can be architected well or terribly.
Kinda tempted to write a “Careful Research Manifesto”, with statements like
“A month in the laboratory can save an hour in the library” is one of my favourite quotes and is relevant here :)
This seems almost entirely a reaction to a set of values (“new shiny technology is good!”) rather than a set of values that stands on it’s own merits. The examples in particular list a set of technologies - microservices, NoSQL, single-page apps - that while possibly used often where they don’t need to be still have real cases where they are appropriate, valuable solutions.
Well, I guess ignorance is bliss. My suggestion is to rename this the NIHS manifesto.
I disagree. I don’t need more than a superficial understanding of Blockchain to know that I don’t need/want to build my next webapp on it.
Sure, but I wouldn’t either.
This is because people have got excited that they finally understand what a block is and want to play with encryption. I would argue that blockchain isn’t anything new, it just has received a ton of popularity and a fancy buzzword now.
It’s not like people didn’t link things together with CFB before blockchain existed. Everyone has just jumped on it because they think it’s fancy now. 🤷♀️
Personally, what I see from you here is an extremeist response and a lack of accurately and fairly representing the points being discussed.
I would agree that this is a weak point of the manifesto. Learning and understanding the benefits and drawbacks of a new technology should be considered a good thing and should be something to strive for, even if they’re hyped to hell and back. Every bit of software that people are using today was at some point unknown by everyone except the creator(s) themselves.
How else will you know when something dramatically better comes along and should rightfully obsolete whatever you’re currently using? There was some guy on the internet that said 90% of all advice is useless and that we should hear as much as we can and take what is useful. While the numbers aren’t going to be the same I think the idea fits the state of software tools fairly well. Maybe one day people will realize that SOAP apis were the best tool/access method by far. I doubt it but it doesn’t mean that give the state of things way into the future it couldn’t happen.
Don’t close off, just choose.
I totally agree that understanding the trade-offs for your decisions is an essential skill, but I still feel like this article’s intention feels more like they want to persuade us all into NIHS than it even remotely represents a fair discussion about accepting poor trade-offs.
While I agree with some of the “examples” listed, I don’t think it’s fair to say microservices are “hyped and volatile”. Microservice architecture isn’t some advent to the computing world. Conceptually, it’s been around for a long long time when you look at operating system kernels. I’d also argue that building software that “does one thing and does it well” is not a new idea either (i.e. UNIX design philosophy).
While the author has some good points, that one seems poorly thought out. Perhaps microservice means something different to the author?
Conceptually many ideas, including NoSQL, have been around for ages. It seems clear to me that the criticism in both cases are in references to the fad of microservices-for-microservices-sake and NoSQL-for-NoSQL’s-sake fads in Web Application Architecture, where there is often no real rationale behind their choice other than they are the trendy topics on the web conference circuits.
(And yes, obviously, there are circumstances in which a microservices approach or a particular NoSQL solution make good sense – these are frequently not, unfortunately, the circumstances in which I have tended to see them used professionally).