23 ms·

Reclaiming Software Engineering (2010)

62 points by akkartik 10y ago

ktRolster 10y ago
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).
lolc 10y ago
Seeing source code as design documents is very helpful. Every design has errors, and these errors may or may not cause failure during construction and use. So the focus must be on controlling the errors, keeping them within safety margins. "Breaking the build" has become a really cheap mistake these days.
twic 10y ago
> Pencils and paperclips break all the time. Even in areas where safety of life is an issue - popularly assumed to be the sole province of engineers - failures still occur absent any negligence on the part of engineers. Reliability of software is not like reliability of a machine, or building. Machines and buildings are made of matter, and so have uncontrollable variation, and wear out over time. Everything made of matter fails eventually; it's part of the engineer's job to trade off reliability and cost. Software is made of bits. The only reason it fails (cosmic rays and other negligible intrusions of matter aside) is defects in design. Do you really get mechanical or civil engineers saying "yeah, we expect there are a few fatal flaws in the design, that's just how it goes, we'll build it anyway and ship a fix if customers complain"? Apart from on Kickstarter, I mean.
- zb 10y ago
  (Author here) > Do you really get mechanical or civil engineers saying "yeah, we expect there are a few fatal flaws in the design, that's just how it goes, we'll build it anyway and ship a fix if customers complain"? Heck yes! (Well, not fatal flaws.) Any product you can think of that has been popular enough to get a second production run probably has had some design flaws corrected. Some of which were probably already known by the time that the first version shipped, and some of which were probably only discovered after real users had it in their hands for a while. > it's part of the engineer's job to trade off reliability and cost. Correct. But the cost includes not only the cost of the artefact but also the cost of the design. The difference with software is that design costs dominate in a way that isn't often the case with physical artefacts.
twic 10y ago
> Yet so long as we are developing software within a social context, where the finished artefact has users other than its designers, we can scarcely escape the conclusion that what we are doing is engineering. This conclusion is far from inexorable. There are kinds of making other than engineering. Carpentry is not engineering. Cooking is not engineering. Gardening is not engineering. Sewing is not engineering. All of these things involve making artefacts for users other than their designers, within a social context no less. All of them require specialist knowledge and tools, involve the application of judgment learned from years of experience, and give rise to communities of practice which codify their agreed knowledge in books. They even have formal certifications. Before you can declare that making software is (or can be) engineering, you have to be able to explain why those things aren't. My tentative theory is that engineering has rigorous ways to check whether a design will work before it is manufactured, and even before it is drawn in detail. A civil engineer can use known formulae to check if a bridge span of given dimensions is even possible before sitting down to design it. A chemical engineer can use known formula to check if a reaction is plausible. A mechanical engineer might need to draw a detailed design, but can then check it rigorously with finite element methods. When we make software, in practice, we have to construct the software and test the artefact, hoping that our tests are adequate. We can't do meaningful checks on the design itself, let alone on any sketch which prefigures the design.
- zb 10y ago
  > There are kinds of making other than engineering. True enough. But the piece argues (I am the author) that software engineering is not making, it's designing. > Carpentry is not engineering. Cooking is not engineering. Carpentry is a craft, but furniture design can be engineering. Cooking dinner is a craft, but designing the menu and production process for a chain restaurant is definitely engineering. > Before you can declare that making software is (or can be) engineering, you have to be able to explain why those things aren't. My position is that they are (or can be), when analysed in an analogous way. You've asserted that they self-evidently are not, even in the absence of a rationale for why. I simply don't agree. > My tentative theory is that engineering has rigorous ways to check whether a design will work before it is manufactured I appreciate you sharing your theory! However, I believe you'll find the history of engineering has largely been one of people doing stuff first and then later finding ways to reduce the cost by doing analysis. I highly recommend watching one of Glenn Vanderburg's "Real Software Engineering" talks for a more in-depth treatment of that subject: http://vanderburg.org/speaking/ http://vanderburg.org/speaking/ > A mechanical engineer might need to draw a detailed design, but can then check it rigorously with finite element methods. That's great, but finite element analysis won't tell you e.g. where water might pool causing a structure to deteriorate, or that a machine can't be properly maintained because a part is too difficult to access. If you worked in any of these fields I think you'd quite quickly be disabused of the notion that they consist of just plugging designs into known formulae until the computer accepts one. Similarly, we have plenty of similar tools in software (e.g. Big-O analysis), but we don't kid ourselves that using them is the be all and end all of developing software. > When we make software, in practice, we have to construct the software and test the artefact, hoping that our tests are adequate. We do that in practice because it's more efficient. I can't accept a definition of engineering that holds that we could claim to be doing engineering only if we did things inefficiently, because it's self-contradictory. That's the opposite of engineering.

62 points by akkartik 10y ago

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).

lolc 10y ago

Seeing source code as design documents is very helpful. Every design has errors, and these errors may or may not cause failure during construction and use. So the focus must be on controlling the errors, keeping them within safety margins. "Breaking the build" has become a really cheap mistake these days.

twic 10y ago

> Pencils and paperclips break all the time. Even in areas where safety of life is an issue - popularly assumed to be the sole province of engineers - failures still occur absent any negligence on the part of engineers. Reliability of software is not like reliability of a machine, or building. Machines and buildings are made of matter, and so have uncontrollable variation, and wear out over time. Everything made of matter fails eventually; it's part of the engineer's job to trade off reliability and cost. Software is made of bits. The only reason it fails (cosmic rays and other negligible intrusions of matter aside) is defects in design. Do you really get mechanical or civil engineers saying "yeah, we expect there are a few fatal flaws in the design, that's just how it goes, we'll build it anyway and ship a fix if customers complain"? Apart from on Kickstarter, I mean.

zb 10y ago
(Author here) > Do you really get mechanical or civil engineers saying "yeah, we expect there are a few fatal flaws in the design, that's just how it goes, we'll build it anyway and ship a fix if customers complain"? Heck yes! (Well, not fatal flaws.) Any product you can think of that has been popular enough to get a second production run probably has had some design flaws corrected. Some of which were probably already known by the time that the first version shipped, and some of which were probably only discovered after real users had it in their hands for a while. > it's part of the engineer's job to trade off reliability and cost. Correct. But the cost includes not only the cost of the artefact but also the cost of the design. The difference with software is that design costs dominate in a way that isn't often the case with physical artefacts.

twic 10y ago

> Yet so long as we are developing software within a social context, where the finished artefact has users other than its designers, we can scarcely escape the conclusion that what we are doing is engineering. This conclusion is far from inexorable. There are kinds of making other than engineering. Carpentry is not engineering. Cooking is not engineering. Gardening is not engineering. Sewing is not engineering. All of these things involve making artefacts for users other than their designers, within a social context no less. All of them require specialist knowledge and tools, involve the application of judgment learned from years of experience, and give rise to communities of practice which codify their agreed knowledge in books. They even have formal certifications. Before you can declare that making software is (or can be) engineering, you have to be able to explain why those things aren't. My tentative theory is that engineering has rigorous ways to check whether a design will work before it is manufactured, and even before it is drawn in detail. A civil engineer can use known formulae to check if a bridge span of given dimensions is even possible before sitting down to design it. A chemical engineer can use known formula to check if a reaction is plausible. A mechanical engineer might need to draw a detailed design, but can then check it rigorously with finite element methods. When we make software, in practice, we have to construct the software and test the artefact, hoping that our tests are adequate. We can't do meaningful checks on the design itself, let alone on any sketch which prefigures the design.

zb 10y ago
> There are kinds of making other than engineering. True enough. But the piece argues (I am the author) that software engineering is not making, it's designing. > Carpentry is not engineering. Cooking is not engineering. Carpentry is a craft, but furniture design can be engineering. Cooking dinner is a craft, but designing the menu and production process for a chain restaurant is definitely engineering. > Before you can declare that making software is (or can be) engineering, you have to be able to explain why those things aren't. My position is that they are (or can be), when analysed in an analogous way. You've asserted that they self-evidently are not, even in the absence of a rationale for why. I simply don't agree. > My tentative theory is that engineering has rigorous ways to check whether a design will work before it is manufactured I appreciate you sharing your theory! However, I believe you'll find the history of engineering has largely been one of people doing stuff first and then later finding ways to reduce the cost by doing analysis. I highly recommend watching one of Glenn Vanderburg's "Real Software Engineering" talks for a more in-depth treatment of that subject: http://vanderburg.org/speaking/ http://vanderburg.org/speaking/ > A mechanical engineer might need to draw a detailed design, but can then check it rigorously with finite element methods. That's great, but finite element analysis won't tell you e.g. where water might pool causing a structure to deteriorate, or that a machine can't be properly maintained because a part is too difficult to access. If you worked in any of these fields I think you'd quite quickly be disabused of the notion that they consist of just plugging designs into known formulae until the computer accepts one. Similarly, we have plenty of similar tools in software (e.g. Big-O analysis), but we don't kid ourselves that using them is the be all and end all of developing software. > When we make software, in practice, we have to construct the software and test the artefact, hoping that our tests are adequate. We do that in practice because it's more efficient. I can't accept a definition of engineering that holds that we could claim to be doing engineering only if we did things inefficiently, because it's self-contradictory. That's the opposite of engineering.