Every now and again, I'll read an article about how in the 1980's and 1990's, Japan tried to create "software factories" that were supposed to kill american business the way Japan's industrial sector had killed american manufacturing.
Except that it never happened.
Why? In "Agile Software Development With Scrum", Ken Schwaber argues that the manufacturing analogy is inappropriate, even harmful to software development. In his words:
"For a defined control process to work, these methodologies must define each process with enough accuracy that the resultant noise does not interfere with its repeatability, or the predictability of the outcome. I can watch engineers define a class numerious times and write down a definition of what I saw happening. This process definition is only useful if it can be repeated over and over to generate solid class descriptions. If my obersations are general or loose because many variations are employed to derive a class, the process definition is useless. The process definition will be so weakly defined that, when it is employed, it does not generate repeatable results. When an activity is so complex or complicated that a different defition is required each time it is executed, the activity cannot be abstrated into a process definition."
That is my problem with heavy-weight methodologies: They take what is essentially creative work and try to boil it down into a manufacturing process. It doesn't work. Software is different each time, just like writing.
Imagine telling a writer how to write! Oh, you can give them guidlines and heuristics. You can talk about transitions and prose and style. You can even set up a working environment for them or give them requirements for the output of the piece.
The thing is, the implementation of the piece can be completely different between two people, and yet both articles can satisfy the requirements completely. Unless you are doing cut-and-paste script-kiddie work, software development is not Manufacturing -- it is writing.
I once read somewhere (And I was certain it was the intro of Effective Perl Programming about Randal Schwartz, but now I can't find it) that through the process of writing, the author realized that he was not a programmer who knew how to write, but he was actually a writer who knew how to program.
I do believe that is one of the mose congruent statements about programming that I have ever read.
And, as always, a special thanks to Lyle and Jack for teaching me nearly everything I know about writing and convincing me that I was much more than a programmer who might learn to write: I was also a writer who happened to know how to program. Thank you.
I find that writing and programming both tickle the same parts of my brain. Both are artistic expressions into a concrete medium, with practices and standards and tools to use.
I have always been envoius of those who can write as well as program - Randall, Damian and Pierce to mention a few.
I feel that there is (at least) two kinds of programmers:
Reading this over I am not quite sure I understand it, but maybe thats just an indication of which group I belong to.
Re:we're not all writers
heusserm on 2004-01-30T13:13:15
Isn't code just writing intended for a different audience? One that is more precise and less emotional than Spock?...
