4 ms·

I would suggest that a reasonable proxy-measure for how good a code base is would be to look at how long the bug list is (of course, this assumes the bug list h

I would suggest that a reasonable proxy-measure for how good a code base is would be to look at how long the bug list is (of course, this assumes the bug list hasn't been gamed). Is the bug list ever-growing, with no hope of being fixed and cleared? The code quality is awful. Is the bug list empty, with bugs fixed rather quickly once they are reported? Then the code quality is probably good, because that is hard to reasonably achieve with a moderately-sized (or larger) lousy codebase.

k__ 10y ago
I worked with a few code bases in my time. Most of them awful. They got many bugs, but nothing one or two bugfix-only sprints couldn't get under control.
- iagooar 10y ago
  You haven't seen awful codebases then, if two bugfix sprints would get them under control...
gravypod 10y ago
If there is an ever growing bug list and the list is being worked through is the software still bad? Could there just not be many issues compounded with the design that must be worked out?
- digi_owl 10y ago
  Or it could be that large projects inherently gather bugs, no matter how well, or poorly, it was designed from the outset. JWZ seems to be of the notion that it is better to hammer away at a known codebase than keep trying to reset the clock, while certain big name FOSS projects seems to reset the clock at every generational changing of the guard.
- ktRolster 10y ago
  Could there just not be many issues compounded with the design that must be worked out? I'm not entirely sure what you are trying to say here.
jt2190 10y ago
I would suggest a slightly different measure: How long can the code be left to run on it's own without the intervention of a programmer, sys admin, or other technical person? I've noticed that poor codebases tend to suck up more and more developer time, and may even trigger the formation of "maintenance teams".
- lotyrin 10y ago
  Software is a piece of capital. Take the benefits to business of a piece of software per unit time minus the costs of maintenance, operations and development effort then compare that to other opportunities to find a net present value. Lots of software I have worked on has probably been in "technical bankruptcy", but nobody sat down and figured that out (or it didn't matter because there was some persistent political reason for the system to exist and for it not to be able to be effectively designed and delivered).

k__ 10y ago

I worked with a few code bases in my time. Most of them awful. They got many bugs, but nothing one or two bugfix-only sprints couldn't get under control.

iagooar 10y ago
You haven't seen awful codebases then, if two bugfix sprints would get them under control...

gravypod 10y ago

If there is an ever growing bug list and the list is being worked through is the software still bad? Could there just not be many issues compounded with the design that must be worked out?

digi_owl 10y ago
Or it could be that large projects inherently gather bugs, no matter how well, or poorly, it was designed from the outset. JWZ seems to be of the notion that it is better to hammer away at a known codebase than keep trying to reset the clock, while certain big name FOSS projects seems to reset the clock at every generational changing of the guard.
ktRolster 10y ago
Could there just not be many issues compounded with the design that must be worked out? I'm not entirely sure what you are trying to say here.

jt2190 10y ago

I would suggest a slightly different measure: How long can the code be left to run on it's own without the intervention of a programmer, sys admin, or other technical person? I've noticed that poor codebases tend to suck up more and more developer time, and may even trigger the formation of "maintenance teams".

lotyrin 10y ago
Software is a piece of capital. Take the benefits to business of a piece of software per unit time minus the costs of maintenance, operations and development effort then compare that to other opportunities to find a net present value. Lots of software I have worked on has probably been in "technical bankruptcy", but nobody sat down and figured that out (or it didn't matter because there was some persistent political reason for the system to exist and for it not to be able to be effectively designed and delivered).