Les asks: "whether or not the wide adoption of TDD has signaled the end (or at least the failure) of the software engineering discipline as we know it."
I'd argue that Test Driven Design/Development is well enough defined to qualify as a formal method. Like most formal methods, it is based partly on what the method designer thought was a good idea at the time, partly on the experience of its practitioners and partly on the results of concrete, statistical studies. The mix changes over time as the method matures.
If TDD gives you the quality and functionality you need at the right price, then it's the right engineering tool. If, on the other hand, it's used simply as a management hack, the resulting product will reflect that.
For anything where a life depends on it, I'd like to think that there are multiple verfication paths - source code inspections right through to in-situ acceptance testing with very brave test pilots, and everything in between. (I heard somewhere that) Airbus, for instance used to have two teams each implement the specification independently, and then run both during the flight.
I have had some second-hand contact with government systems. Without pointing the finger too precisely, these were systems that wouldn't kill someone immediately, but potentially make life very difficult for individuals and the public when they screwed up. They used waterfall based structured design techniques, whose main purpose was to ensure that the blame was spread evenly and thinly. In the end, it often comes down to the efforts of a lone contractor to get it right.
To be fair to government agencies, you need to read that anecdote in the context of what is typical of IT generally. And software engineering is not, and never has been typical of IT shops.
Comments