Krzysztof Kowalczyk points to the presentation (Pingwales):
Even though there has been a movement for some time to introduce traditional engineering concepts such as quality assurance to software development, Cox sees today’s software engineering as “the art of writing large bad programs rather than small bad programs”.
Of the much-vaunted ‘holy grail’ of reusable objects, Cox said, “As far as I’m concerned these all generally suck too. Part of the problem is that they’re sold as products and the original ideas behind a lot of reusable products is that you wrote it once. If you write it once, it has to do everything. If it does everything it’s complicated, and if it’s complicated, it’s broken. That’s not always the case but it is quite frequently the case.”
As for QA, “Everybody in the real world will agree – the moment a project is behind deadline, quality assurance tends to go out the window. People go through the specification and everything marked ‘optional’ becomes ‘version 2’, and everything marked ‘QA needed’ becomes, ‘we’ll find out from the users if it works,'” Cox said.
Another factor that’s led to the current state of affairs is that of canny software companies which shift bad software as quickly as possible, on the basis that once the end user has one piece of software for the job it becomes harder to switch to another one – in that context, Cox considers Microsoft’s release of early versions of MS Windows as a very sound economic and business decision.
Compounding the situation even further is the incentive for businesses to deny all knowledge and point fingers when software errors are uncovered. If there are several parties responsible for the maintenance of a piece of software, he said, it’s in everybody’s interests that the other person fixes the bug because the customer will assume that whoever fixes the bug was responsible for it. Most businesses, particularly SMEs, don’t have that luxury.
How does one make the world a better place by writing better software? For starters, Cox says, we need to accept that humans are fallible and that software engineers, no matter how well trained, will make large numbers of mistakes in their software – so we should start using the right tools to keep the error count as low as possible.
