What sucks, who sucks and you suck

Computational Pragmatics

2014-12-03

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.