Myths we tell ourselves about software engineering
5 points by typesanitizer
5 points by typesanitizer
Figure 51, where the authors draw a straight line through the graphical representation of a codebase and says it "crosses only a few dependencies" and then draws the same line at the same slope through a representation of a different implementation as if it was meaningful, does not make me think this is any kind of serious analysis. There's no attempt to look at the substance of those dependencies, just what they look like under one particular visualization.
Also:
Lifeware had the largest test suite in the world at the time (4K tests in 2002).
I am... skeptical that no other piece of software had more than 4000 tests in 2002.
I dunno, this is a weird mix of “myths”. I don’t disagree with any of them, but it’s a very, very, very long article and the one example that stood out to me, maybe didn’t have the intended impact:
To do this, they use a streamlined process that has provided a 100% success rate for the migration of over 20 insurance companies over the last two decades
About one migration completed per year over 20 years (and what’s more, without knowing the duration of each) is not particularly impressive, and in any case, migrations like these are as much social as technical problems.
I have however come to disagree with the assertion that software engineering isn’t “real” engineering, and the older I get the more confident I am that I’m correct. There is plenty we need to do to catch up to civil engineering, for example, but being an immature industry doesn’t make it invalid.
For me, Hillel Wayne's "crossover project" is what really put to rest the idea that what we do isn't "real engineering". In particular: most of the people (on both sides of the argument) actually don't know much about engineering, and when Wayne asked people who really have done both, 15 out of 17 said that software engineering is "actually" engineering.
Wayne's work here is a substantially better read than the article we're commenting on now. This submission is, amazingly, even longer than it is smug. It makes a lot of dubious claims backed up with flimsy diagrams, the production value of which vastly outstrips the depth of analysis.
I would strongly encourage folks to read the crossover articles instead of this!
I think I read that at the time. Totally agree with it. The idea that nothing changes during “real engineering” is laughable. Funnily enough I started my degree in engineering and switched to comp sci after a year or so. So I haven’t been a “real engineer” but I went to a real engineering school.
What settled my position was when I read that Margaret Hamilton’s hardware peers argued that she too was an engineer. Everyone in the Apollo program was doing hardcore engineering and they would know!
I actually think of engineering as “using scientific principals to build things” which doesn’t strictly fit any of Wayne’s definitions, but I think it’s a bit neater. There is definitely a science to computing, but not all software engineers are computer scientists. Similarly you need to know physics in (say) civil or electronic engineering, but not all such engineers are physicists.
Myth 1: Software engineering is about building functionality.
It is; you just need to at time dimension. It is therefore about allowing to maintain, add useful functionality over time and to get rid of the fluff; not just today, here and now - we must include future cost as a factor constantly, when making specific implementation choices and designs
Myth 8: Technical debt exists. … Ward later clarified that he never intended it to mean anything else than the difference between the current structure of the system, and the structure that we now wish the system to be. He never intended it to mean a reckless pile up of technology, for example. A metaphor can be useful but this one has run its course. It’s time to outgrow it.
Okay, let's forget about the phrase for a moment. To be technical is to only care about details. The computer is a detail machine. Suppose that we need N necessary details to describe a solution to our problem, but our implementation actually has N + k details, including k excess details. To change the system, we'll imagine that each detail interacts with every other detail, creating a quadratic number of interactions which the programmer must consider. (Details can interact with themselves, if you like.) An excess interaction is one which involves one of the k excess details. The reader is invited to verify that the excess interactions caused by non-zero k scale quadratically in k, like O(k²), and linearly in N, like O(N); that is, the excess technical cost of changing a system scales linearly with its size and also scales quadratically with its unnecessary details.
Excess technical cost exists, can be quantified, and slows down the rate at which systems can be changed by increasing the overall cost. If you don't want to call it "technical debt" then we can call it something else.