4 ms·

There's a tricky problem that comes up in teams. A "bad" developer can hack and slash and appear to implement new features in a certain amount of time, and a "

There's a tricky problem that comes up in teams. A "bad" developer can hack and slash and appear to implement new features in a certain amount of time, and a "good" developer who takes the time to do everything right may actually produce less of obvious value in the short term. When approaching software restructuring, you have to make damn sure that your management chain understands the importance of the refactoring and can evaluate the time you spent for its actual worth. If your organization uses "metrics" or other weasel words to examine productivity, tread carefully. It's also worth noting that even if you believe you know how to improve/simplify/whatever, it may be worse than you think and sometimes you don't figure out the extent of the complexity until days have gone by. This, like many things, is a trade-off and not a set rule. In brand new code, by all means make it small and pretty and documented and whatever else would win it an award; but in established code bases be smart about what you "fix".

gbog 14y ago
In three paragraphs of readable language without any rhetorical tricks you dug much deeper than the OP, thanks.
- martininmelb 14y ago
  I'll try to summarise in two words: "Technical Debt".
drumdance 14y ago
At my last company we had a co-founder like this. He would implement stuff extremely quickly, often at odd hours to fix a pressing bug. However, the code was just garbage from a maintenance standpoint. It was hard to criticize, though, because he pretty much single-handedly got the company off the ground by quickly implementing features people were willing to pay for. This code was good enough to get the company up to $2 million annually. The downside is we spent about a year re-writing the software to get it to a state where the company could scale to higher levels. During that year we had to stop adding new features. I remember getting very frustrated with the code quality, but I often wondered whether that was just a price we had to pay to get cash flow positive.
- dennisgorelik 14y ago
  Yeap, that was the price. It's called technical debt and sometimes it makes sense to have it. Dirty code not always has to be refactored. Most of dirty code just dies together with useless functionality (wrong guess on business side).

gbog 14y ago

In three paragraphs of readable language without any rhetorical tricks you dug much deeper than the OP, thanks.

martininmelb 14y ago
I'll try to summarise in two words: "Technical Debt".

drumdance 14y ago

At my last company we had a co-founder like this. He would implement stuff extremely quickly, often at odd hours to fix a pressing bug. However, the code was just garbage from a maintenance standpoint. It was hard to criticize, though, because he pretty much single-handedly got the company off the ground by quickly implementing features people were willing to pay for. This code was good enough to get the company up to $2 million annually. The downside is we spent about a year re-writing the software to get it to a state where the company could scale to higher levels. During that year we had to stop adding new features. I remember getting very frustrated with the code quality, but I often wondered whether that was just a price we had to pay to get cash flow positive.

dennisgorelik 14y ago
Yeap, that was the price. It's called technical debt and sometimes it makes sense to have it. Dirty code not always has to be refactored. Most of dirty code just dies together with useless functionality (wrong guess on business side).