4 ms·

"If there's a chance that the code you're writing will never be touched again, why bother to invest a lot of time in it? In that case, leave some Technical Debt

"If there's a chance that the code you're writing will never be touched again, why bother to invest a lot of time in it? In that case, leave some Technical Debt at the end and allow the next requirement to drive a better design." I found the article excellent and I like the financial debt metaphor a lot. However, the quote above is somewhat confusing. I usually get rid of technical debt (post task) so that a developer can read and understand the code better. They need to do this in order to make some future unknown change. Since a "better design" would at least involve understanding the current design then a strongly disagree with leaving technical debt in code you do not think will be touched again.

toss1 9y ago
While it's excellent to make the code readable for the next guy, I read this as talking about the architecture level, where reading the code will be largely unnecessary because it is all junked for Rev.2 I did this for one SAAS company and it worked out great. Although I had been very much a design-everything, pre-optimize excessively type of coder/designer, for this project at a company I co-founded I went completely the opposite direction. With only a slight nod to the architecture I expected we'd need later, I just coded up the first version in the easiest high-level tools we had, separating only one module. This allowed us to get a much better handle on the actual requirements, especially since the marketing guys of course went out and sold some of the prototype. Fortunately the sales were small enough that we didn't get swamped, but it gave me real data, and strongly reinforced my plan to build a highly modular set of interacting services such that each could run on separate hardware, which could also be scaled in hours. This very scaleable architecture later allowed us to take business from competitors who were (AFAICT) were stuck in a monolithic architecture. But after the first version had served it's purpose, no one has ever read any of the code again in the 15 yrs since. We just started on the main version and never looked back. So as a person who formerly would have recommended the opposite, I can strongly recommend making a really brief Plan A prototype / first version that you plan to throw away. Just make sure that you do actually throw it away, and soon (code that sort-of works does have a way of sticking around too long).
- davidhyde 9y ago
  Good point. I guess it boils down to team size. If the team size is large then the code is more likely to be refactored in stages than rewritten. And more people on a team usually means more code reading than writing. Also, you have a higher turnover of people so onboarding cost is important. Small team size means you don't have a lot of these problems.
  - mirko22 9y ago
    not necessarily, 50-100 person team in random bank for example can’t even do all of the tickets they should in whatever timeframe they have less alone refactor something properly, and not cos they are busy, but for variety of other reasons, one of them being turnover. this has a lot to do with how your code looks to begin with, bad code is generally hard to refactor, and refactoring is not a cure for bad code.
  - toss1 9y ago
    good pint about team size. I'd think it may not apply so much with huge teams, as if you probably need to have a very extensive definition of the problem to justify a large team at the outset, so doing the long-term architecture & design up-front (vs. a throw-away version) would likely be best. I'd hope for a situation where the initial small team built the throw-away, ran it hard, then use that knowledge to build the big version and the big team.

toss1 9y ago

While it's excellent to make the code readable for the next guy, I read this as talking about the architecture level, where reading the code will be largely unnecessary because it is all junked for Rev.2 I did this for one SAAS company and it worked out great. Although I had been very much a design-everything, pre-optimize excessively type of coder/designer, for this project at a company I co-founded I went completely the opposite direction. With only a slight nod to the architecture I expected we'd need later, I just coded up the first version in the easiest high-level tools we had, separating only one module. This allowed us to get a much better handle on the actual requirements, especially since the marketing guys of course went out and sold some of the prototype. Fortunately the sales were small enough that we didn't get swamped, but it gave me real data, and strongly reinforced my plan to build a highly modular set of interacting services such that each could run on separate hardware, which could also be scaled in hours. This very scaleable architecture later allowed us to take business from competitors who were (AFAICT) were stuck in a monolithic architecture. But after the first version had served it's purpose, no one has ever read any of the code again in the 15 yrs since. We just started on the main version and never looked back. So as a person who formerly would have recommended the opposite, I can strongly recommend making a really brief Plan A prototype / first version that you plan to throw away. Just make sure that you do actually throw it away, and soon (code that sort-of works does have a way of sticking around too long).

davidhyde 9y ago
Good point. I guess it boils down to team size. If the team size is large then the code is more likely to be refactored in stages than rewritten. And more people on a team usually means more code reading than writing. Also, you have a higher turnover of people so onboarding cost is important. Small team size means you don't have a lot of these problems.
- mirko22 9y ago
  not necessarily, 50-100 person team in random bank for example can’t even do all of the tickets they should in whatever timeframe they have less alone refactor something properly, and not cos they are busy, but for variety of other reasons, one of them being turnover. this has a lot to do with how your code looks to begin with, bad code is generally hard to refactor, and refactoring is not a cure for bad code.
- toss1 9y ago
  good pint about team size. I'd think it may not apply so much with huge teams, as if you probably need to have a very extensive definition of the problem to justify a large team at the outset, so doing the long-term architecture & design up-front (vs. a throw-away version) would likely be best. I'd hope for a situation where the initial small team built the throw-away, ran it hard, then use that knowledge to build the big version and the big team.