Stephen Wilson in his blog post Programming is like Playwriting (23 Feb 2011) which recently resurfaced via a Twitter conversation makes a few interesting points about how we write software and how the tools and speed of development cause some very interesting quality problems.
Coding is fast and furious. In a single day, a programmer can create a system probably more complex than an airport that takes more than 10,000 person-years to build. And software development is tremendous creative fun. Let's be honest: it's why the majority of programmers chose their craft in the first place.
Actually I found this statement ironic, especially in light of the Denver Airport Baggage System - which itself became far more complex than the rest of the airport's operations.
So, picking out two salient points:
We took our time. I was concerned that the CASE tools we introduced in the mid 90s might make code rather too easy to trot out, so at the same time I set a new rule that developers had toturn their workstations off for a whole day once a week, and work with pen and paper.
I worked a long while back in software-hardware co-design, to best understand the difference consider these situations:
Software - compilation and testing phases
$ vi myProg.c
$ gcc myProc.c
$ ./a.out
repeat multiple times per minute/hour as necessary. The cost of compiling and editing is measured only in man hours.
Hardware - compilation and testing phases
- Send net list to TI,Phillips or whoever for ASIC manufacturer
- Pay $1,000,000
- Wait 3-6 months
- Receive single ASIC in post
- Test
Maybe the solution is that each compilation is charged per compilation? Actually I knew one developer that added sleep statements to his compilation scripts so that the act of compilation would become so 'expensive' that he spend much more time ensuring that the code worked before compilation.
My internal coding standard included a requirement that when starting a new module, developers write their comments before they write their code, and their comments had to describe ‘why’ not ‘what’. Code is all syntax; the meaning and intent of any software can only be found in the natural language comments.
Formal specification? Now whether you use B, Z, VDM or any of the other host of mathematical languages (and by the way, C, Java etc are mathematical languages in that sense) along with their tools and techniques is largely irrelevant, though for actually expressing the WHY and WHAT they are rather good at this!
We have had some excellent results regarding so called 'light-weight' usage of formal methods. The main learning however is not doing formal methods for the sake of doing formal methods but the fact that the communication and clarity of the requirements and subsequent code was much improved.
References:
[1] Ian Oliver Experiences of Formal Methods in 'Conventional' Software and Systems Design. FACS 2007 Christmas Workshop: Formal Methods in Industry. BCS London, UK, 17 December 2007
[2] Ian Oliver Experiences of Formal Methods in 'Conventional' Software and Systems Design
