Writing software - diaries or novels?

ITworld.com, Ebusiness in the Enterprise |  Software

I write software. On average, I write at least as many pages of text per day as your average professional writer. The text is written in a variety of formal, pseudo-English languages with names like Python and XML but it is still very definitely text.

I have written some real books too, three of them to be exact. Writing books feels to me very much like writing software. Thinking about it, I have concluded that writing books feels the same as writing software for a good reason.

The reason is that properly done, they are one and the same activity.

One of my all time favorite quotes comes from the classic programming text Structure and Interpretation of Computer Programs[1]:

'Programs should be written for people to read, and only

incidentally for machines to execute.'

Therein lies the root of the relationship between writing software and other forms of writing. It is tempting but fallacious to think that software is stuff that is written primarily to be understood by a computer. To this way of thinking, software is text produced to give a computer something to work with. The text itself is a mere intermediate form. A private language between the mind of the programmer and the non-mind of the computer. In terms of writing genres, you could think of writing software as being analogous to writing a private diary. There is only one human consumer - the author herself.

Software doesn't (or shouldn't) work like this because, at least in commercial IT, software isn't written in a social vacuum. There are other humans involved - perhaps thousands of other humans. Other programmers will need to read what any one programmer writes. Writing text that makes sense to a computer is trivial compared to writing text that makes sense to a group of fellow programmers.

Indeed, the multiplicity of human readers of software is a fact of life even if the only intended reader of software is the writer herself. How so? Because software needs to be read and understood long after it is created. Long after the original author first put keystroke to keyboard. Long after the mental model in which the software itself was created has scattered in the wind. Long after all the ancillary pieces of software required to make it work have been whipped up into the tornado of backward incompatibility we call

Join us:
Facebook

Twitter

Pinterest

Tumblr

LinkedIn

Google+

Answers - Powered by ITworld

Join us:
Facebook

Twitter

Pinterest

Tumblr

LinkedIn

Google+

Ask a Question