Niall's Oracle Pages

There's an interesting discussion over on Tom Kyte's blog about the software development process. It drew the following comment which I thought worth looking at a little more.

RAD and iterative development methods have pretty much killed design skills as far as I can see. Not that there is anything wrong with these as concepts. As always the problem is their implementation. A large number of development projects take the view that iterative development means you don't have to think at all, just start. I hear quotes like, "We'll refactor that later!", all the time. The problem is that later never comes.

I repeatedly think back to my early days in IT working on real-time control systems with Oracle as a back end. We created requirement specs, functional specs and module specs, all of which were signed off by the customer. We then designed our DB to support the requirements. We wrote pseudocode, had it reviewed, then turned it into real code (PL/SQL and Pro*C). More often than not it worked first time due to the details and care taken along the way. when it was over the customers liked what they were given because they were involved in the whole process.

Fast forward a few years and what do we have, a spec in a single email that the customer hasn't approved, but, "It's OK! We can change it later. It's iterative development!"


Now that's a cariacature, but I'm rather afraid not actually that far from the truth.

RAD and iterative development methods have pretty much killed design skills as far as I can see. Not that there is anything wrong with these as concepts. As always the problem is their implementation. A large number of development projects take the view that iterative development means you don't have to think at all, just start. I hear quotes like, "We'll refactor that later!", all the time. The problem is that later never comes.

Consider also the Agile Manifesto
Manifesto for Agile Software Development

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan



This is another formulation of the same idea, that good software is developed not by careful design, appropriate modelling of the business problem you are trying to solve or the task you are trying to automate, but by putting it together as you go. If it doesn't work then undo it and try again, or more probably throw in a case specific fudge. There is something wrong with this as a concept, as well as practical implications, but it is the idea that RAD to some extent, but iterative development in particular is OK as a concept that I wish to remark upon.

The reason I object so heavily to this is partly the last observation from the original comment, later never comes, but mostly because I think this betrays that we as a profession have lost sight of the disciplines of engineering. Consider almost any other engineering discipline that you care to imagine, ship building, tool manufacture, car design, house or office building, computer hardware design even. Can they be characterised by the sort of approaches outlined above, iterative rethinks of core parts of the product (I know lets make the captain's quarters out of marble, marble is very fashionable these days)?

It is unfashionable amongst the /. crowd for example to point out as Fabian Pascal does so effectively that the RDBMS is a (flawed implementation of) a mathematically sound model and that if you wish to effectively use the relational approach you have to understand the model and do the ground work of application of relational design to your specific situation. It seems that it is also becoming fashionable to try and avoid any modelling of what you are trying to achieve at all. Hidden in both the comment and the practical application of the agile manifesto is the fact that the software developer, and probably the client as well, doesn't actually know or understand the problem they are trying to solve or the business process they are trying to automate. Now repeatedly trying something until you find something that works is certainly one approach - it reminds me of my toddler trying all the holes in his posting toy until he finds the hole that the shape goes through - but its surely not as good as knowing what you are trying to build before you start out.