Title: Developing programs

Author: Martin Moene

Date: 13 September 2015 06:52:25 +01:00 or Sun, 13 September 2015 06:52:25 +01:00

Summary: 

Body: 

I started thinking about how the act of writing software became known as ‘development’. It turns out that the etymology of the word develop comes from the old French desveloper, meaning to unwrap or reveal (etymonline.com is a good resource for this sort of thing). I like the connotations associated with ‘reveal’. I’ve also heard people compare software development with the art of sculpture, with particular reference to the idea attributed to Michelangelo: “Every block of stone has a statue inside it and it is the task of the sculptor to discover it.”

I’m fond of (sarcastically) remarking that writing code is the art of adding defects to an empty text file, but even that captures a similar concept of revelation. Of course an empty text file has no bugs in it – and it may even compile successfully! – but it’s unlikely to satisfy a requirement, or pass a test.

It’s this latter sentiment that really captures my imagination: that writing tests can reveal requirements, and these are then ‘carved out’ by the implementing code. This holds only if the code is being written test-first of course, and so if the real code is being written up front, then it too is being used as the tool to reveal the real requirements. The arguments used by the TDD community strikes a real chord here: driving the design with tests is more than just a way of having the tests in place; it also allows us to explore the design, and ‘reveal’ the underlying statue in the stone.

Perhaps in the end the TDD approach is more like the old-school development of photographs, which again is a process concerned with revealing the picture on the paper. The skill of the photographer in properly framing and exposing a picture might be likened to analysis of a given problem. The skill of the developer then is like that of the, er, developer in applying the right chemicals under very specific conditions to correctly reveal the photographer’s original vision. Like the modern analyst and programmer, photographer and developer might very well be the same person. But I mustn’t stretch this one too far, since these techniques are becoming out-dated by modern digital photography. Which leads finally to the question: will our skills as programmers be one day superseded in a similar way?

Notes: 

More fields may be available via dynamicdata ..