Had time and autonomy from a client, so took sweet time examining the domain, the existing systems et al. Spent a few months writing the basis and the framework around what will be done, based on years and years of experience I had with bad frameworks and codebases, combined with working on the same domain for their parent company years ago.
And it worked. We delivered features insanely fast, hundreds of forms were migrated, feature generators would create 90% of the boilerplate code and the code was small, readable and neatly clustered. Maintaining it was a piece of cake, leading to us not having enough work after a while so I negotiated our time to half a week for the same money.
After a while, client deemed us too expensive to pay for only 2.5 days of work - after all, how does it make sense - if we are paying them that much, they should work 5 days!
So they cut us out. Two things happened:
1. Devs that got moved to other projects in the company told me they didn't know development could be so smooth and tried to replicate it in future projects, even tho they say it failed a lot of lessons they picked up from the framework were highly relevant in their future careers.
2. The company found a cheaper developer, he said "this is unusable and has to be rewritten" and rewrote it into "clean code", taking longer than the original project took. At least he works 5 days a week now.
There’s a limited amount of people that can work on a system at the start of a project if you want it to be a coherent whole, so that you can have everyone iterate on it in the same style later. If you start out with 20 (junior) engineers, you get a kind of frankenstein where all issues are waved away because ‘we need to deliver in a week’
I actually was the one telling them not to rewrite, lol.
But the original code was a mess of matlab spaghetti, they couldn't find a way to hire for that. Not to mention turning it into a web service was already a big hack of java parsing a raw dump of matlab datastructures that nobody dared to touch.
I had to read the matlab code, and it tooks hours to decypher a few lines. Plus the language doesn't have great debugging and error handling capabilities and the tooling is quite terrible.
So rewriting to python won, and for once, I must say it was a good call.
Joel has since said that that he doesn't really agree with that advice anymore, at least not in the same way. Super annoying that it gets parroted over and over again as though it's the word of the lord.
I agree it shouldn't be parroted as though it's the word of the lord, like any advice it will be more or less applicable on specific situations. I've been on both sides of the let's redesign a thing plenty of times.
The balance is somewhere in the middle, it's valuable advice for what can go wrong when you don't think through the implications of the decision making process, understand how and why the system works the way it does, and what risks exist for what can go wrong with a big redesign. But like anything, if the risks are understood, then those risks can be accepted, mitigated, or rejected if appropriate, or provide guidance on why the redesign investment isn't worth the associated risks.
We got a small team of competent people, with domain experts to peer code with the devs.
It was wonderful. We could test, document and clean up. Having people who knew the trade and users at hand removed second guessing.
The result was so good we found bugs even in competitors' implementations.
We also got x5 in perfs compared to the system it was replacing and more features.