I disagree with the fundamental premise put forward here.
Software should be written to meet specific needs.
And those needs should be defined.
And it’s likely a software project will have many tens of needs defined.
And amongst all those needs it will become clear what technologies fit the needs.
A blanket statement like “choose boring technology” only fits projects where the project needs result in that outcome.
Saying “projects should be built with boring technologies” is the equivalent of saying “projects should be built to NASA launch spec reliability”. That MIGHT be true, but having a predefined idea of what the requirements are puts the cart before the horse.
Requirements come first, then after that come statements about how things will be done.
My guess is that systematic definition of requirements will result in very very few projects “built using boring technology”.
My experience is that requirements are almost orthogonal to what stack will be chosen. CTO going to a conference, tech lead being bored, founder having a friend who knows "shit", developers padding resume and so own impact the choice way more than actual requirements. 99.999% of the projects can be done using any mature lang + PostgreSQL or PostgreSQL compatible newSQL variant.
If I was to rewrite my blogpost to fit your second sentence I would title it: "Please consider onboarding new staff as a need for your software". This is just another consideration when architecting. I absolutely will use cutting edge tools if they are needed. But we just need to think about it a little.
Indeed the availability of developers who know the tech stack is a key requirement that should be defined and assigned an importance level.
And if you’re working in a business building a modern web application then it’s extremely hard to imagine the stakeholders being happy with software developed using absolute lowest common denominator tools techniques and libraries, as advocated by the “boring software” movement.
Competitive advantage and the expectations of customers leads to the need to use modern tools techniques and libraries.
And in fact developers deserve these things too because they tend to make things easier more powerful and more reliable.
If the stakeholder who is paying for the project says “can we have an animated user education intro”, and you say “no because we use boring technologies and our developers might not understand how to use the animation APIs” them I think your job would be at risk pretty quick.
Some cases need a very boring CRUD setup, yet other will require distributed events passing around CRDTs.
I've worked on terrible projects built with boring tech that was perfect for simple CRUD, but where the project wasn't anything CRUD at all but parsed huge datasets of time series, combined with events and changesets. The 'boring tech' was such a bad fit, that the project ground to a halt, cost enormous budgets just to keep running, and was impossible to move forward.
Couldn’t disagree more. I think you’re missing the point. You can use boring technology (Golang) and simple patterns (no generics) and build something that works, and is readable, and maintainable, and secure as a consequence of this. I’ve seen this again and again. Then you can expand your code as business needs change, but making your code flexible from the start is in the same basket as over engineering and premature optimization.
Your example and conclusion aren’t a good match IMO. Choosing a restrictive language is not something you can easily pivot from later when you need more flexibility. It’s a huge commitment, so making the right choice for the future is not premature.
Software should be written to meet specific needs.
And those needs should be defined.
And it’s likely a software project will have many tens of needs defined.
And amongst all those needs it will become clear what technologies fit the needs.
A blanket statement like “choose boring technology” only fits projects where the project needs result in that outcome.
Saying “projects should be built with boring technologies” is the equivalent of saying “projects should be built to NASA launch spec reliability”. That MIGHT be true, but having a predefined idea of what the requirements are puts the cart before the horse.
Requirements come first, then after that come statements about how things will be done.
My guess is that systematic definition of requirements will result in very very few projects “built using boring technology”.