Everyone should attend at least one truly memorable lecture in their university career: the one so well-presented or eye-opening in its content that it stayed with you for the remainder of your career. Mine was the last lecture of our Computer Science C235h module at UWA, in which the lecturer immediately grabbed our attention by announcing that there would be no notes as what he was about to say would ‘upset’ certain members of the rest of the department wedded to the accepted wisdom of software engineering practice. In fact, he said, this lecture might be subtitled ‘What they don’t tell you in Software Engineering’.

Today, I came across my own personal notes for that lecture. Naming no names, here they are for my own posterity at least. Incidentally, the notes are headed ‘Our Vienna piss-up’ but sadly I can’t now recall the context of this remark. I’m guessing it must have been an occasion for certain disgruntled academics to grumble about their department heads over a few beers.

Software Engineering

• As an ideal, to avoid problems in undisciplined system development.
• A set of methods and tools.
• Rules for the life cycle of development (how rigid? budgets and timescales)
• Increases quality of the product.

Temptation to seek shortcuts:

• leads to maintenance problems
• timescale
• write the code in time to write the spec?

Quality costs money

We’re seeking the appropriate level of quality, not the maximum!

‘Adequate’ specs are always needed! There is a skill in defining ‘adequate’ and bending the rules to meet:

• appropriate quality
• (tight) budget
• delivery within a (tight) timescale

This is a matter of Engineering Judgement (EJ). It needs experience.

Functional Specs

Essential!

• Level of detail depends on circumstances, maybe (use EJ)
• Never let the client write them. Either they assume too much knowledge or don’t have a clue.
• Avoid incompleteness and overambition
• Use phased development, etc. [I think these ideas became Agile]

Design Specs

Essential. Level of detail again determined by circumstances (EJ).

Design top-down and bottom-up. Both are restricted:

• Top-down: functionality; operational requirements lost.
• Bottom-up: runtime; development environment; language.

Top-down must match [complement?] bottom-up restrictions.

If in any doubt, develop ‘quick & dirty’ prototypes of part of the application (i.e. hack!).

True but sad; you are more likely to get paid for poorly designed and documented code that works, rather than good specs and non-functional code - future maintenance problem! (NB. Does not apply to software engineering industry.)

Languages

Can never choose language for the job in practice.

Two more important: C; Ada [look, it was 1991, OK?]

Beware the shortcomings of strange languages (like Occam). Assembler can be smaller and faster than compiled code? (But we now have decent processors, optimised compilers, etc.)

Environments

“UNIX, X11 taking over” … so are DOS & Windows 3, which run on cheap PCs. (Windows 3 on UNIX?)

HCI

Designing good HCI is very difficult.

In critical applications, a poor (but correct!) HCI can be catastrophic (e.g. Possible factor in Airbus crash in France).

Never underestimate the time needed to design good HCI.

Project Management

[This bit stuck with me most of all]

Never rely on a management team. They make more mistakes than you. They can get away with this!! They can blame you! Never take them at face value.

Finally: Engineering Judgement = appropriate quality.