4 ms·

I have a friend who suggests the opposite of the grandparent's assertion. Since every new line of code represents technical debt that must be serviced, each new

I have a friend who suggests the opposite of the grandparent's assertion. Since every new line of code represents technical debt that must be serviced, each new programmer generates a maintenance burden sufficient to occupy the time of 2 more programmers.

sidlls 9y ago
This assumes companies value servicing tech debt.
- cookiecaper 9y ago
  Like financial debt, technical debt can only be ignored for so long. Eventually, badly-serviced code gets mucked up to the point where changes are prohibitively difficult. The normal response I see to this is for companies to hire new talent to come in and write a parallel v2.0 while the old talent nurses v1.0. v2.0 takes 6-12 months to develop, and then it works OK for a while, but since management's refusal to prioritize technical quality is really the crux of the issue, v2.0 eventually grinds to a halt as well, and the cycle repeats for a v3.0. So they're still forced to hire to someone to help them resolve the friction caused by technical debt, and this method comes at a much greater cost than hiring someone competent and giving them the necessary resources/allowances (which, yes, includes an adequate number of programmers) in the first place. That allows the same codebase to remain maintainable (or even just salvageable) and be used long-term, without really having to rewrite the thing and throw all of the knowledge surrounding corner cases, etc., out the window for v+1.
taneq 9y ago
Assuming programmers generate a net increase in lines of code. (When working on a mature codebase, I'd expect that the better the programmer, the more likely this number actually is to be negative.)
- cookiecaper 9y ago
  I agree that it is possible for programmers to have a net-negative impact on LOC, but I didn't really address that because I can't think of many realistic long-term employment solutions where that would be the normal expectation (driveby consulting gigs don't count). Even if you walk in and are able to eliminate large quantities of cruft in your first, say, 3 months on the job, once you pare the core down and simplify, the company will continue to want new features and changes, which will typically necessitate some growth. I think the best realistic option would be a relatively-modest gain in net lines over the course of a year, commensurate with the number of new features.
komali2 9y ago
Hah I mean by that logic a code base for a company is an infinitely expensive debt.

sidlls 9y ago

This assumes companies value servicing tech debt.

cookiecaper 9y ago
Like financial debt, technical debt can only be ignored for so long. Eventually, badly-serviced code gets mucked up to the point where changes are prohibitively difficult. The normal response I see to this is for companies to hire new talent to come in and write a parallel v2.0 while the old talent nurses v1.0. v2.0 takes 6-12 months to develop, and then it works OK for a while, but since management's refusal to prioritize technical quality is really the crux of the issue, v2.0 eventually grinds to a halt as well, and the cycle repeats for a v3.0. So they're still forced to hire to someone to help them resolve the friction caused by technical debt, and this method comes at a much greater cost than hiring someone competent and giving them the necessary resources/allowances (which, yes, includes an adequate number of programmers) in the first place. That allows the same codebase to remain maintainable (or even just salvageable) and be used long-term, without really having to rewrite the thing and throw all of the knowledge surrounding corner cases, etc., out the window for v+1.

taneq 9y ago

Assuming programmers generate a net increase in lines of code. (When working on a mature codebase, I'd expect that the better the programmer, the more likely this number actually is to be negative.)

cookiecaper 9y ago
I agree that it is possible for programmers to have a net-negative impact on LOC, but I didn't really address that because I can't think of many realistic long-term employment solutions where that would be the normal expectation (driveby consulting gigs don't count). Even if you walk in and are able to eliminate large quantities of cruft in your first, say, 3 months on the job, once you pare the core down and simplify, the company will continue to want new features and changes, which will typically necessitate some growth. I think the best realistic option would be a relatively-modest gain in net lines over the course of a year, commensurate with the number of new features.

komali2 9y ago

Hah I mean by that logic a code base for a company is an infinitely expensive debt.