4 ms·
Accumulating bad code is like pushing your company from a plane without a parachute and hoping that the next guy creates enough cushion in time before the landi
by d0mine 10y ago
Accumulating bad code is like pushing your company from a plane without a parachute and hoping that the next guy creates enough cushion in time before the landing destroys the company (not the fall that kills you)--you survive because you are likely moved on and are busy pushing some other company to its doom.
It is probably ok if you work for a startup that does not survive long enough for the quality of your code to matter anyway. But in a regular company, your attitude creates a time bomb when eventually any apparently simple change may destroy the codebase (and at best, it just takes too long to make any change).
Bad code isn't Technical Debt, it's an unhedged Call Option http://higherorderlogic.com/2010/07/bad-code-isnt-technical-debt-its-an-unhedged-call-option/ http://higherorderlogic.com/2010/07/bad-code-isnt-technical-...
- toast0 10y agoWhen someone (maybe me) comes and rips out my bad code later, they're going to have the benefit of future knowledge. I don't know how my code will be used in 2 years and what the requirements are, but they will, because they'll be there. I do my part today by acknowledging all of my code is bad, therefore I don't invest a lot of time or ego in it. I try to make it in reasonably sized pieces so it's easier to rip out later (this may make it slightly less bad). If someone comes and tells me my code is terrible, I say yes it is, you might want to consider these things when you replace it. EDIT: my opinions on this would change if I were shipping code to run on other people's machines: it's generally easy and quick to fix my code on machines I run, but updating code on other people may never update, you need to try harder to get it right the first time.