4 ms·
> We can go on and on, but it would be too expensive and risky to rewrite everything from scratches. I worked on a project that we developers thought it was unb
by Test0129 4y ago
> We can go on and on, but it would be too expensive and risky to rewrite everything from scratches. I worked on a project that we developers thought it was unbearable with shit storm of the codebase. We cried and complained and refused to take a responsibility, but asking for complete system rewrite. For every bug we blamed the codebase, tight schedule, but never us. We were loud enough and got the opportunity to rewrote everything. Did I forget to tell you that was a startup in desperate need for the investments? Of course, halfway through, the startup lost its momentum to gain investments, and the project has run out of funding. But we’ve done it by the book that time and by the book we’ve failed.
This paragraph perfectly illustrates why doing things correctly is often better in the long run than doing them fast. Spikes quickly become fixtures in the code base that cause inordinate pain.
It sounds like the bug ridden code was costing the company so much money and time to fix adding new features become exponentially burdensome with each new iteration. The result? The startup dies. There is an art to isolating spiked "expendible" code and almost no one does it right. The results that follow are often predictable. The author attempts to divert blame from the developer who was rushed but in my experience it is rarely the developer who in the end made decisions to write terrible code. Needing to put food on the table, keep your health insurance (in America), and have a stable life necessitate sacrificing what you truly believe in knowing full well suffering is in your future. The PMs should be blamed for the shitty code.