November 2007

The difference between software development and software engineering

Software development:

The system performs function A.

Software engineering:

The system performs function A under operating conditions B with operational performance parameters C with tolerances within the probability distribution D and reliability within the probability distribution E and we are legally responsible if it doesn’t.

As you can probably imagine, one of these problems is harder than the other. My interest is in explaining why it is still possible and even desirable to address the second problem with evolutionary design.

Agile methods can explain how to manage evolutionary design for the first problem. They have so little to say about the second problem that they almost appear to deny its existence. Software engineering methods are largely concerned with the second problem, but they usually apply a simple-minded mass production mentality to management. I guess “serious” software engineering researchers haven’t considered management to be a sufficiently interesting problem.

Maybe I’m a dreamer. I want both. In fact, I don’t think Software Engineering can be made to work without evolution. The best that a phase-gate system can hope to offer is to solve yesterday’s problem (i.e. the wrong problem) with great precision. I want the optimum solution to today’s problem, today.

Comments (4)

Print This Post Print This Post

Email This Post Email This Post

Permalink

A good example of autonomation in software engineering

…is the class invariant.

Class invariants and contracts are not about testing. They are about reliability. The purpose of a class invariant is to minimize the state space of the system, both at design time and at run time. A class invariant is an extension to your type system. You will get the most power from them if you think about them and use them in that way. I love dynamic languages, but the people who bitch the most about type systems probably don’t understand how to use them correctly. The compiler is your friend. Static analysis is your friend. Class invariants make types smarter.

Reliable systems fail at the earliest opportunity. Sounds counterintuitive?

The loom stopped instantly if any one of the warp or weft threads broke. Because a device that could distinguish between normal and abnormal conditions was built into the machine, defective products were not produced.

- Taiichi Ohno

Comments (4)

Print This Post Print This Post

Email This Post Email This Post

Permalink

Close
E-mail It
Socialized through Gregarious 42