Programming As Engineering

Those who subscribe to the view of programming as engineering (DisciplineEnvy) do not have much patience for the ProgrammingAsArt camp. They recognize that a delivery date of "when the muse strikes me" is not likely to go over very well with a client.

Recognizing the benefits of organizational behaviour, they try to develop metrics to measure software productivity. Projects are given measurable goals against which the success or failure of the effort can be judged. They also try to develop ProcessPatterns that will likewise help.

Although aware of the story BuildingTheWorldsHeaviestAirplane, they discount it as not being representative since it only discusses one metric being applied.

Some say: engineering = science + art.

The eternal debate: Art vs Engineering. I think a lot of folks, especially those involved with patterns, see it more as a combination of both. How about ProgrammingAsArchitecture?. This is a very over exposed metaphor I don't want to fan those fires again, but architecture is the combination of science and art.

I want to live in an inspired, beautiful, cleverly designed, comfortable, safe, maintainable, extendable house. I would like to use software with the same qualities. -- ToddCoram

I'm looking to encourage ProgrammingAsCraft?, for those programs for which craft is sufficient. --KentBeck

Just noticed that there is a SoftwareDevelopmentAsCraft page. -- MichaelFeathers

Programming is definitely not engineering. Why? Engineering is a scientific discipline, based on scientific principles drawn from physics. Why do bridges not fall down? Because civil engineers understand the physics of steel beams and can therefore accurately design a safe bridge. We cannot.

See ToEngineerIsHuman. I think that engineer would disagree with you about why bridges do not fall down.

I'd just like to comment that this was not always the case. Civil engineering used to be a case of over-design on the side of safety and then keep removing stuff on successive versions until the design fails. -- JasonYip

Practices like incremental development and refactoring are responses to the fact that we do not have scientific principles upon which to base our work. Instead, we plan to proceed by trial and error and guesswork, getting it wrong the first time (or the first few times) but eventually getting it right, after enough iterations or increments. Civil engineers do not do this. Automotive and aeronautical engineers do it a little bit (they built a prototype that is very close to the final solution, then make a few tweaks to get it just right).

Ultimately, if computers are to be as useful as bridges, we will have to discover the scientific principles that underlie our work -- if, in fact, they exist. -- RobertEikel

And suppose they don't exist?

Then we're stuck doing what we do now, which is making the best of it, using techniques like the ones I mentioned above. -- RobertEikel

Why would that stop us being engineers?

A friend of mine who is the son of a professional mechanical engineer and lecturer,and is himself a mech. eng. graduate and teacher of craft, design and technology, told me a story once. It seemed that, a few decades ago, there was a crisis in mech. eng. education: under graduates were steeped in theory, they could calculate things to death, produce reams and reams of drawings, but not remember that an internal screw needs to be accessible from outside the component if it is to be tightened up. Now, every mech. eng. course has compulsory workshop sessions.

Further, when I was studying physics (perhaps the purest of pure science) the only course required in all four years (and the toughest) was "General Physics", the gentle art of educated guesswork and back-of-an-envelope calculations

As someone who has designed various systems (OpticalCommunications?, MicrowaveElectronics?, DigitalElectronics?) including software, I have found that many of the principles of design are the same. These tend to boil down to

I have often thought that SoftwareEngineering could learn a lot more from more mature engineering disciplines ... --ChanningWalton

Absolutely. Unfortunately, those who claim to be trying to do so seem to have an unrealistic view of how mature engineering disciplines actually work. --GlennVanderburg

Programming is definitely not engineering. Why? Engineering is a scientific discipline, based on scientific principles drawn from physics.

Really? Was James Watt not an engineer because he built steam engines without the benefit of Sadie Carnot's quantitative thermodynamics? Of course not. What the engineering subjects have in common is that they apply technology (and science) to economic problems.

Watt was, as software developers are today, a craftsman (and an inventor). He relied on skill, judgement, and experience to make his inventions work. And he probably blew up a lot of boilers in the process. -- RobertEikel

Programming is not engineering. Not any more that pouring concrete is engineering, or welding steel is engineering. Building software systems is engineering, as building bridges is engineering.

I was about to argue with you, until I realized you said "building bridges is engineering" rather than "designing bridges is engineering". So, to rephrase: you're saying that programming is part of engineering. I agree with that completely. --GlennVanderburg

Is software engineering or art?

I asked this question to SunirShah over a beer last week. He said, "Software is putty. Raw material. If you're an artist, it's art. If you're an engineer, it's engineering. If you're a craftsman, it's a craft." I think that basically sums it up. --AnthonyLander

While watching a PBS program called "Wings" (in 1990) about the history of airplane design I was struck with one example of why programming is not engineering. Six people working for Lockhead had built a new prototype jet in six months containing six million individual parts.

how prototypical was this plane? It flew and demonstrated new flight surfaces and controls. I also seem to remember that the engine was a new design as far as air flow went.

There is no way that software programmers could produce something of the same complexity. We don't have any way to specify interfaces and functional descriptions so that we can out source the work successfully. We don't have catalogs of parts that we can order, modify slightly and plug into our new design.

Until we do we are just playing in the mud, building castles and bridges and dreaming of being real engineers, or else we are artists building sculptures out of the mud. -- AndrewNicholson

But I have seen a single person build a program with over six million instructions in just a few months. Of course, most of them came from the DBMS, GUI builders, and so on. But how is this different from what the guys at Lockheed did? They didn't build all those parts themselves. -- RalphJohnson

Exactly, Ralph. How many of those parts were distinct? How many of those six million parts were (literally) nuts and bolts? Do I get to count collections, strings, integers that I use in my software, even though I didn't create them? --AnthonyLander

A 24Mb program isn't the same complexity as a jet plane. An instruction isn't the same as a nut or bolt. I'd be willing to equate separate actions, branch decisions, and methods to the smallest part in a jet. I would still say you are off by a factor of at least 20 in complexity. There is also a large difference between one person and a team producing the same thing. In a team you have to externalize your ideas and designs for other people to build. -- AndrewNicholson

SoftwareIsArt, SoftwareEngineering

EditText of this page (last edited March 27, 2003) or FindPage with title or text search