The Myth of Code Construction

Ever work with a developer who avoided letting anyone see their code, refused to program in pairs or participate in a code review? They say "This is my code" as if they have sole right of refusal on the final product regardless of who else may be paying the bill.

Great writers still have editors. No matter how great a writer you are, you still have to submit your work to an editor before it will be published. Let's examine the idea of putting code into production as a form of publication.

Before we jump into a new analogy, we should look at the current state of affairs. If engineering were a family construction would be the successful older brother leaving software as the immature younger brother, never quite living up to the accolades of the elder sibling yet endlessly compared nonetheless.

In general, the phases in software are: analysis, design, construction, test, deployment, and training. When you want to build a building of any size, let's use a downtown skyscraper as an example. If we continue the comparison we'd start with analysis which includes many factors like the target location or how many square feet are required. The location can impose limitations to the footprint which then dictates how many floors would be needed to achieve the required square footage. Such trade-offs are examined and decided upon during the design phase. Construction is all about execution with limited opportunity for design changes. How do you test a building, what does that even mean? You might might test the subsystems, like elevators, fire alarms, etc. but how do you test the entire building? The closest we can come in scale might be the opening and closing the retractable roof of an almost complete stadium like the new Cowboy's stadium (this being written in May of 2009). How do you deploy a building? You don't, you open it for business. There is no pull of the lever where what did not exist suddenly does. As for iterations, the closest construction can come is building a new wing on an existing building, adding a room to the house at hand. The cost and effort of remodeling can end up being a significant ratio to the original price of the house.

Now let's discuss a comparison of software development with writing a book. A publisher decides the market is ready for a new book on ant farming. They either have recent submissions by authors interested in writing such a book or they solicit existing authors who have experience in the subject matter. In any event, they request an outline of the book with maybe a sample of one chapter to gauge the material matches what the publish wants. The author or authors work at creating the manuscript all the while knowing that editors will read the book and suggest changes. Editors who are not experts in the content but are experts in the publishing of books. Even the highest-paid authors - Mary Higgins-Clark, Stephen King, or J. K. Rowlings to name a few - will all submit their work to the editors pen.

When the manuscript is complete and the editors happy, there are still other contributors to the final product, researchers, artists, designers, and the like who do things like create illustrations, populate an index, check facts, or plan the visual layout of the chapters. All these activities are coordinated by the publisher who has a target date for when the book will be printed, planning a marketing blitz to coincide with the publish date. Getting the manuscript done is important but still is a small part of the whole effort and if an author cannot produce on time, a lot of investment by the publisher goes to waste; a good way to dissuade the publishing company to find an author who can deliver. The key is that it doesn't have to be perfect but does have to be complete. If there is enough demand, it is easier to publish a new edition rather than hold off on the initial printing. Testing is as easy as a small test run where the final product can be validated by all contributors before scaling up into production-sized runs; images replaced, a new cover chosen, typos fixed. Printing becomes like running the build with a target of production. This means that "build" isn't a phase, it's an activity; unlike any in construction. Deployment becomes a straightforward, if not simple matter, of distributing copies of the book to various retail book-sellers or their distributors.

My suggestion is for the software developers of the world realize that allowing our craft to be constantly compared to the construction industry is to remain the little boy, wanting to live up to the expectations of those who came before, never earning the respect or acceptance they so long for. Look instead to the world of publishing, where writing is still an art and yet the businesspeople have found a way to make money without rejecting the fundamental nature of writing, be that a novel, the latest tech book, why not the latest edition of your favorite word processor?

p.s. Kudos to the wife for the idea.