OU-M880 (Soft Eng)
4 October 2005
This Software Engineering course is essentially a recap of all the courses to date (1 2 3 4 5 6). It ties all these strands together and presents a unified picture of how to undertake a software development project.
Every process involved with the production of software is formalised. Everything is planned in advance, even the planning is planed for. Their main justification for this is to produce a high-quality, validated product upon delivery. Nothing wrong with that. The model is based on the premise that a bug discovered after delivery costs 18 times more to fix than one discovered during development. Thus they have tremendous latitude to do all manner of bureaucratic procedures in order to prevent these bugs from escaping.
I think their premise is false. These days most new applications are either online or else have automatic online updates. Online software can receive bug-fixes instantly, the developer just logs into the server and edits the program. Software using automatic online updates can receive bug-fixes within a few days of the problem being noticed. Long gone are the days when software corrections needed to be bundled into a service pack, tested like crazy, printed by the thousand, mailed to clients, and supported through the install.
The term "paradigm shift"[?] has been abused in recent years, but online software and online updates are a paradigm shift in software development. They remove the horrible risk which has previously been associated with software releases. This removal of risk means that the cumbersome and bureaucratic software development process is no longer needed. Customers will still encounter bugs, but if the developers respond promptly, each bug will only be seen by one person. Ideally the software would automatically report errors, so that the user doesn't have to. Under this system there is no such thing as a "known bug".
The only prerequisite for software release is a solidly designed, beta-level product with a firm commitment to release updates quickly.
[Note, this does not apply to a) off-line or embedded devices (e.g. car fuel injectors), b) safety-critical devices (e.g. Therac-25), or c) one-shot software (e.g. Ariane 5). These are abnormal applications with abnormal requirements. This approach also assumes that the overall software architecture is correct, since a major flaw in the architecture (e.g. Netscape 4) is unfixable without a rewrite.]
Fortunately this is my last course with the OU. Upon successful completion (final exam is next week), I'll be clear to do the dissertation next year and get my MSc.