> 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".
"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.
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".