It feels like there is an article like this every other week. They reflect the same generic view which is broadly true yet I think is not very useful as an advice. In a highly creative field like software competitive advantage often outweighs comparative disadvantage. In other words it might very well be the case that a company that takes a chance on something unusual with a higher opportunity cost will outcompete competitors. How to make the "right" choice of unusual is where the interesting questions lie but that is highly context-dependent and can't easily be generalised into a blog post.
Whether you code is declarative/imperative or whether it has all the hot new packages as featured in HN has very little to do with making software products "competitive" or having "comparative advantage". It's always going to be about whether the product is solving the customer's problem more conveniently than the competition does.
Yes, but whether it will continue to do so, once again, has little if nothing to do with the tech stack.
I think you’re getting at the point about how tech debt can bog down product development and the progress of a business, and I fully agree that it should be avoided, but tech debt avoidance is hardly related to the tech stack or programming style as much as it is to architectural decisions. And, when you’re looking at longer shelf life for your code, then the article becomes justified in making your codebases as boring as possible because thn you’d like to employ only the patterns that have truly stood the test of time, instead of polluting your code with novel approaches.
> I think you’re getting at the point about how tech debt can bog down product development and the progress of a business, and I fully agree that it should be avoided, but tech debt avoidance is hardly related to the tech stack or programming style as much as it is to architectural decisions.
I think all the people who are adopting Rust, who wouldn't have touched C++, would disagree with you.
Design Patterns are from at least 1994, when GoF wrote them down. Ideas like DDD are some 20 years old. As is e.g. Event Sourcing.
Actually, by your reasoning, Event Sourcing would be the preferred architecture for everything since the oldest written human sources were event sourced (bookkeeping grain).
As always, what is best fitting "depends". Battle tested is one, but never the only one, parameter to decide with.
> Maintenance over long time is hard, requires experience, architectural choices, risk analysis, balancing tradeoffs, and obviously a disciplined team.
Exactly. That's the reason Facebook gave for adopting Reason (OCaml).
Not in 2022. Half a century ago, yeah, it was a highly creative field, but these days almost everything has been done. (Even ML is decades old, the hardware caught up.) And this is a good thing!
We have been doing this long enough that it should be "boring" now, in the same way that constructing buildings or bridges is "boring", eh?
> In other words it might very well be the case that a company that takes a chance on something unusual with a higher opportunity cost will outcompete competitors.
Sure, but that's a decision that should be made cautiously, with good reasons to think it will work. In other words, innovation should be "boring" too, at this stage in the game.
Reminds me of Sendgrid. At the beginning, they were faced with using an off-the-shelf MTA (mail transfer agent) or writing their own. As a core competency, writing their own turned out to be a major competitive advantage.
This is a very good point. There are definitely "risky novel" choices that could make your company a success. But I've also seen many teams drowning in a soup of random tech choices.
I'd love to be able to write some more specific advice on this topic but mostly I just want people to be mindful of the impacts of their choices and actively choose risk rather than having it sneak up on them.
My first time as a team lead I saw value in little side experiments on non-core parts. Now I think that's only OK if there is time and budget to roll them back if they prove to be a bad fit. Otherwise they accrete and become a drag on velocity.
