Programming as an Art

The title of this post could be misunderstood. I will not write about how programming work can produce pieces of art (demo scene being the most evident sample), but how some practices makes the way of creating software much closer to art process creation than to a scientific work. Everybody knows the famous swing drawing; I will just copy here, as a record, and will save you the multiple and funny intermediary steps. (Have a look here for some good laughs if you are interested). The initial situation: Final result being: But the result of a software process development, even if not so drastic, is very often rather different of what was initially planned. Requirements interpretation is very often a cause of variation upon real needs; there is no doubt about this, but my experience is also that, once the programming team starts having a good business knowledge of the software being developed, the quality of the requirements starts to degrade and they eventually tends to disappear. Regarding technical documentation, starting by technical design, its quality also often decline along with project maturity. An informal study on multiple projects shows us that the most advanced are the projects in their lifecycle; the higher are the risks that the documentation we are facing is not actualized and/or missing. And that is where computing starts meeting art: when decisions are taken based on experience and/or feelings, and not so much on documentation or rational processes.  And, you can believe my 15 years experience in software testing and quality assurance; this is something that is unfortunately very common. The corollary is that a too important part of the time we are spending on testing projects is to try to figure out how the software we are working on is supposed to work, and unfortunately, we often have to talk to final users to understand what is the exact idea behind the screen we are facing. The result of this process is that in several testing projects the final output of our work has been, apart of the Test Cases, the Functional Requirements for the System Under Test (SUT). And customers are usually more than happy with that. Taking in account this situation (poorly document software), we, at Sogeti Spain, have decided to work on an initiative that will allow the creation of formal models of the SUT to be generated using the Test Cases that are the normal output of our work. These Test cases, when exhaustive are themselves a description of the SUT, and thus can be used to generate the models. We expect to have good news for you soon. Stay tuned.