Two Irreparable Mistakes Of The Software Field

The belief that the source code is a development product, not the design for a product. See TheSourceCodeIsTheDesign.
The origination of computer science departments many years ago, in lieu of software engineering departments. See SoftwareEngineeringVsComputerScience.

Arguments follow. (Note: much refactoring needed to convert this thread to DocumentMode.)

The Premise Is Flawed

The error is thinking there are two mistakes of the software field and that these are them.

If one were to look up the word "irreparable" in the dictionary, I'm fairly sure one would find that it is not a synonym for "serious" or "fairly large". It means something closer to "cannot be fixed". Even if the above 2 claims were true, they are obviously not unfixable.

This page is a badly named rant, and I see no redeeming value in it. I.e. it is an irreparable mistake. It could be deleted...though I suspect there might be value in the discussion. I also suspect that value is already here on Wiki, scattered among numerous other pages.

The Source Code is the Design

One of the silliest fallacies promulgated on this board. Code is the result of design, not its source. Design comes from architecture, and that from specification, and that from requirements. Extreme Programming notwithstanding, that is the way any professional product development goes. Claiming that the source code represents the design is similar to claiming the painting represents the totality of the painter.

Whoa down there, Sparky. Methinks you've misunderstood what's meant by "the source code is the design". It simply says that there is no more complete, unambiguous, and irreducible expression of a design -- and the designer's intent -- than the source code that accurately implements it. No other form of document is as comprehensive.

Furthermore, Extreme Programming certainly doesn't deprecate architecture, specification, or requirements, so your "Extreme Programming notwithstanding" is a straw man. Extreme Programming simply takes these down from their traditional "Big Thud" pedestal, and elevates production of working code to an appropriately high level. Extreme Programming emphasises the the goal of software development -- to develop software, not documents. Obviously, it's not applicable to everything, but what is?

Still towing that XP line, are we? Please don't try to equate the professional approach of software development as a regimented process with creating straw men. Code does express an implementation, but only one. Reading the code should equate to, "Here's how this code implements the design" rather than "Here's how the design must be implemented."

Do you mean "toeing that XP line?"

Software Engineering vs Computer Science in Schools

Science Before Engineering

It's not an either/or, you need both. And before the engineering discipline can exist, the underlying science must be well-founded. Some argue that speaking of "software engineering" is premature, as ComputerScience is still in its infancy. I generally disagree with that point of view too.

Computer Science is Not Mature

Big-name universities wish to avoid SoftwareEngineering because it's a "soft" field suffering DisciplineEnvy, currently lacking in rigor. That does not mean it's not important, only that it's hard to subject to traditional science. I'd suggest universities teach the HolyWars. At least students would then be aware of design choice options and potential trade-offs even if they don't have a hard answer. -t

Thinking I might be falling out of date, I recently searched for material on the science and engineering of UIs. There has been very little advance over the last 20 years; there are interesting studies about human perception, but that's about it. UI design is purely an art; for every pundit who claims to have anything approaching a set of universal principles that should be followed, there are four others who will point out how he is a liar and a fraud. And his principles were all vague hand waving to start with. There is no rigorous engineering to UI design beyond the minimal: that practitioners should be grounded in perceptual cognitive science. And yet UIs have been argued to be one of the most important areas of software. So I fail to see how there can be argument about "software engineering" being in its infancy.

Bit of a non sequitur. Doors are routinely mis-designed as well (see e.g. Norman's TheDesignOfEverydayThings), but we can hardly claim that "door engineering" is in its infancy.

It's not a non sequitur, your argument is. We thoroughly understand doors and how to make them, so mis-designed doors can be 100% avoided by anyone who studies the subject (reading Norman's book alone would take care of all of the mis-designs). UIs, on the other hand, are not understood at all, and mis-design is what always happens; it is not some rare situation.

Some of the problems with doors can probably be attributed to naive consumers. They often chose esthetic and superficial features over more practical concerns, in part because they are not aware of them. This can happen in SoftwareEngineering also as PHB's get excited by some dazzling screenshot, ignoring under-the-hood factors.

[The problem is that GUI design is highly subjective. There is no one-design-makes-all-happy. Generally one is encouraged to let the user and/or your boss decide the style and approaches since they control your paycheck. In other-words design-by-pursestring. For example, somebody who uses spreadsheets a lot may be comfortable with filling in a data grid with codes and numbers. But somebody not familiar with spreadsheets may prefer a one-instance-at-a-time wizard-like interface. And then you have the constraints/difficulties of browser-based UI's to consider. There are many things that were easy in the client/server days that turn your hair grey if tried on a web-browser.]

The irreparable mistake was calling SoftwareScience? ComputerScience. ComputerScience would seem to be named as the precursor for ComputerEngineering, but it is not. Is there really a need for SoftwareScience? as a named field of study? We do not, for example, have ElectricalScience? as a named area of study. We just have ElectricalEngineering?. Just my $.02. Cheers, -- JasonNocks

Hmmm. We have PhysicsScience? (yeah, I know, the "Science" is implied, not stated). ElectricalEngineering? is an applied branch of the PhysicalSciences?. I suppose a parallel for computers and related disciplines would be ... Computics(tm)? ComputationalSciences?? I agree, the terminology is somewhat fluffy, having stumbled, squinting, into the light as its harder layers were being abstracted into softer layers. Abstractics(tm)? I'm sure there's an academic-sounding buzzword in there struggling to get out. -- GarryHamilton

[We could divvy up "computer science" into two separate fields, I suppose: "Computational science" would be the study of computation; whether it's done in software, in hardware, or on a blackboard makes little difference. Such a discipline would be even closer to pure math than compsci is today. "Software science" would be the study of such things as operating systems, programming language design, relational database design, etc. And "software engineering" would be what it is today.

Or, we could leave well enough alone.

The argument suggested by the title is, I thought, the claim that academic curriculi focus too much on the science and not enough on practical application, as well as the economic questions that separate "science" from "engineering"; I generally think the opposite. I will note that quite a few other engineering disciplines, EE in particular, are nearly as "soft" as SW engineering. Certainly, most EEs I know have far more in common with software engineers in how they carry out their profession, than they do with civil engineers or chemical engineers. -- ScottJohnson]

If you mean the part of digital EE where folks design combinatorial logic etc, yeah, maybe. Other parts, definitely not. E.g. analog and DSP filter design is "hard", not "soft".

I will concur that analog design is hard, but if you are looking for a set of precisely defined rules, faggidaboutit. The one thing one has to plan for in an analog design is multiple passes to get the noise out of a circuit. Cross talk is rampant and that hand wired prototype may work fine, but the first production PC board will wander off and latch on to frequencies coming from who knows where.

Analog design - at RF frequencies, especially - frequently resembles witchcraft more than engineering. :) But you are are correct - I was speaking of general digital circuit design, especially when done inside an FPGA (where changing the design is cheap and easy). In areas where making changes involves adding GreenWire?s, printing ECBs, or (worse yet) redesigning an ASIC; traditional "waterfall" engineering principles are much more frequently used. Even DigitalSignalProcessing can involve a bit of art; as FIR design techniques are far less mature than design techniques for analog filters (or their digital cousins, IIR filters), and quantization errors in any IIR design are notoriously difficult to model. A common technique there is to add extra bits to the accumulator(s) and hope it's enough; this is sorta analogous to the civil engineer using steel twice as strong as the model suggests.
Good comparison, and that's sort of the point, isn't it? Civil engineering is very hard, not soft, but all disciplines have their difficulties where art comes into play; the question is the degree to which that is true of a given discipline.

CategoryRant