Software development is notoriously behind schedule and above budget. Why are we so unable to estimate the time it takes to produce an application? Development of hardware is always underestimated and the development of software overestimated; reality is different. For example compare the current multi-core CPU in your laptop with the CPUs built from discrete components 40 years ago and then contrast this stunning advancement with the similarity of FORTRAN and ALGOL used on these CPU's and Java used today!
“It is only a small matter of programming” was originally a 'game people play' (see the book by Eric Berne) and is now the title of a book by Nardi – the game is played as IT projects in most organization in the western world and we all suffer from late, inadequate and error-producing software we are forced to use in our work environment.
I had recently a student proposing to write software to allow end-users to create and adapt graphical user interfaces. He started with a good idea, observing the connection between database schema and GUI, and had quickly wiped together rudimentary graphical editors for GUI and database schema. This must have been emotionally rewarding, i.e. fun, and it seemed a minor step to complete the rest.
Having often started simple looking projects myself, to observe later the hidden complexity that made it hard to produce at the end, something coping with the complexity of a real world application, I start identifying some common sources for the optimism. We do not address the hard questions first and start to program early. The hard questions can be found by:
- Identify a compact but not trivial use case and describe it from the user's perspective in detail.
- Select a formal (or pseudo-formal) language to describe the representation for the information used in the program.
- Describe the functions (transformations) used to achieve the goal in a (pseudo-)formal language.
In my effort to exploit the data structure information to produce a GUI I failed eventually when I started considering exceptions: special situations in the underlying application operations and problems with user input has to be dealt with in parallel with the ordinary application logic. I found the current exception handling violating the principle of locality in my code and confuse me to the point I gave up; I will return to the question when I have a good idea what I could do differently.
Some advice at the end:
Use existing tools and do not duplicate them unless you have a compelling reason; try first to patch together a prototype using existing tools.
