Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Similar thing.

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.



We were going to do this. Get several months to set up a clean base for our new system with only the four most competent people working on it.

Then I went on vacation for a week.

Come back to a system that needs to be delivered to prod next month with 20 randos submitting PR’s…

WTF happened. Did you learn nothing from previous failures?


What was the lesson they where supposed to have learned?


9 women cannot have a baby in a month.

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’


Aka "Brooks's Law" or more broadly, the idea that "adding manpower to a late software project makes it later" from Brook's "Mythical Man-Month"




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: