> in 6 months time your application might be gone or requirements change in a way that everything you wrote does not matter anymore

I'd say if you write code with the assumption this might be true, you're almost guaranteeing it will be - business requirements do often change but typically that means having to modify/refactor existing code so that core components continue to work the same way, because those core requirements haven't changed. While you can make occasional assumptions about which requirements are more likely to change than others I'd much rather write all my code on the assumption the requirements won't change too significantly and that the tools/automated testing and other processes are in place to support that. There's far too much "throwaway/POC" code that ends up getting used in production, often for years, then mysteriously stops working down the line because nobody ever assumed it would need to survive that long. Whereas I don't believe I've seen a project fail because too much time was spent ensuring code was well written and well tested.

> Whereas I don't believe I've seen a project fail because too much time was spent ensuring code was well written and well tested.

This does indeed happen. Kent Beck tells a story of being called in to help a European insurance project where, sick of all the legacy code, they spun off a new company to start fresh. Teams of bright people spent years building The Right Thing and doing it The Right Way. But they never delivered anything actually useful, and by the time the sponsors were entirely fed up, they still couldn't promise anything soon. So they fired everybody, hired back one team's worth, and then started fresh on well-written code that actually did something immediately useful.

I think there's a middle path between "write garbage that succeeds" and "write perfect code that never gets used". I think it's narrow but doable, and it requires dogged attention to both "ship early and often" and "build in a way that's sustainable over the long term".

I argue that real dichotomy is:

"write perfect code that gets used a lot, frameworks, libraries"

"write throw away glue code with use of libraries and frameworks"

Because for me "write garbage that succeeds" vs "perfect code that never gets used" is false dichotomy.

Where most devs want to write libraries and frameworks because these are places where "eternal fame" is - even better if you can write your own programming language that is the highest echelon of software engineering.

Ugly truth is most devs are driving beat up honda - where Linus Torvalds, Anders Hejlsberg, Bjarne Stroustrup are F1 drivers - you can rev up your honda on street lights all you want - but that is not the same league.

So most devs write business apps and many of them overshoot quality.

> So most devs write business apps and many of them overshoot quality.

I think this can be true for sufficiently bad definitions of quality, which I agree are very common. To me, though, overengineering something doesn't really increase quality, because actual need puts an upper bound on quality.

I don't doubt there are projects that struggle or even fail due to over-engineering, but I wouldn't consider code written on the assumption it won't be needed in 6 or even 12 months' time (therefore not needing, say, code review, automated testing or even the ability to build on anything other than an individual developer's machine, which I've seen happen more times than I care to remember) to be any sort of sensible "middle ground".

I have tried reading this sentence/paragraph multiple times without great confidence I know what you're saying.

But if your notion is that there's no place for throwaway code, I disagree. The trick with throwaway code is to actually throw it away. Temporary and permanent code, used appropriately, are both vital to projects that are resilient in the face of real-world circumstances like lack of certainty and changing needs. It's the third kind you have to watch out for: https://web.archive.org/web/20190709091156/http://agilefocus...

Absolutely there's a place for throwaway code and I even make a point of always writing it in such a way that there's no possible way it can end up being part of a production solution that ends up in front of customers.

That's one solution. But a more healthy one is building a relationship such that temporary code can ship and then get removed. I've been a part of teams that did this all the time with experiments. We'd hack it together any old way for the experiment and ship it. Then when we had enough data, we'd remove the experimental code and do it right based on what we learned from the trial.

> Whereas I don't believe I've seen a project fail because too much time was spent ensuring code was well written and well tested.

Oh I definitely have. In fact I'd wager that it's the leading cause of failure for programmer lead startups. It's far too easy to spend time worrying about code and ignoring the business when your skillset lies in code and not in business.

Sure, but that's failure due to not getting the business requirements right. If the code had been hastily thrown together with no regard for process it's hard to believe it would've produced a better outcome.

Well it's priorities, no? If you spend the time to get the code right, you're not spending time validating your business or talking to customers. And indeed "getting your code right" is a very common excuse to not ship.

I suppose I'm enough of a traditionalist to believe the two skillsets - one being validating a business/talking to customers and the other being the actual software development side of things are sufficiently different that it's extremely rare that one individual is going to handle them both well.