Friday, June 02, 2006
Pure product and the strain of imagination
Last week I posted a couple of meditations on the C library's strcpy() function: its elegance and its risk. These two ways of examining a small function illustrate an essential tension in software development. On the one hand, system design and implementation is well established as a set of engineering practices. NATO (of all organizations) decided in 1968 that a piece of software is an engineered artifact. On the other hand, actually composing a program is a compositional exercise.
The IEEE Standard Glossary of Engineering Terminology defines software engineering as "The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is the application of engineering to software." One can't argue that large-scale systems development can be anything other than "systematic" and "disciplined" and be successful. Software is just too complex. But quantifiable? Barry Boehm has applied economic principles to software development in order to enable better schedule and budget estimation. His Constructive Cost Model (COCOMO) does a pretty good job. Studies show that COCOMO estimation results in estimates that are within 20% of actual results 70% of the time. On a $500,000 project, users of COCOMO can expect to be no more that $100,000 off in their estimates most of the time. But 30% of the time, they will be off by even more. The best estimator out there is wrong 1/3 of the time, hardly a good argument in support of software engineering's being quantifiable.
But the strcpy() example shows how much software development does embrace practices that approximate, in the abstract, engineering practices. The programmer has to know strcpy()'s limitations as a functioning artifact in a way similar to how an electrical engineer has to know how much current a given size wire can support. There's nothing creative in that; it's the application of empirical observation to real-world problems. And without it, systems break and break hard.
But there's that nagging little insight that strcpy() is an extraordinarily elegance piece of programming, so much so that reading it forces an informed reader into contemplation of the C programming language--reminiscent of Barthes's observation (Critical Essays) that literary texts are always, in some way, reflections on themselves and their use of language.
Nobody ever says I have to develop a program this afternoon or I have to engineering a program. We say "I have to write a program."
Different languages have not only different vocabulary, but different affects. Just compare a Java program to its C# equivalent. Though C# closely models Java, the Java text somehow seems more deliberate, even stolid. C# texts seem lighter and somehow, risky. C is poetic; Python is prose.
Programs are texts, keyed one character at a time. Characters form key words that form statements that form functions that form programs that form systems. Much like word, sentence, paragraph, chapter, book. And doesn't the successful writing of a book require a systematic, disciplined approach?
I am convinced that failure in application development is a systemic problem rooted in misguided allegiance to a set of developmental practices that privilege engineering and failure to understand the process and practices of writing (the non-quantifiable) and how doing so would improve software quality.
What I don't know is what the balance should be: How much of engineering and how much of writing are the right mix? How can we (can we at all) measure the weight of writing on software quality? How can we better train programmers to include writing practices in their programming? Can the practices of literary analysis be applied to software texts as ways of discovering flaws in old programs and better ways of composing new ones?
Would a good start be to begin teaching computer programming in the English Department as well as the Computer Science Department?
# posted by Jim @ 11:01 AM 
