Friday, May 22, 2009

The Education of a Codewright

I know one of the first questions is, 'What is a Codewright?' Outside of a programmers editor by the same name, which I've never used, I think of a codewright in the same vein as you might a Shipwright. He is the guy who is in charge of designing a ship and making sure that its construction will be of such a standard that the finished product, a ship, will fulfill the purposes for which it was designed.

The next question is "How does one become a Codewright?" Is it an innate talent improved through practice, or a skill that can be taught? Considering the anecdotes of the genius programmer who never studied as a programmer, let's examine the subject of education; Joel On Software covered the ivory tower with this post about
The Perils of Java Schools.

Even though I'm a Java advocate, it might surprise some of you that I actually agree with the premise of Joel's article. I disagree somewhat about Java's role in the problem. The way I see it, Java is a symptom of the disease that the 'JavaSchools' have contracted. I saw the same dichotomy when I was in college which was well before Java was released. Some instructors saw their role as people who prepared you for a job working in the corporate IT shop doing COBOL.

Lucky for us we had a few professors who wanted to make sure we had a grounding in theory and knew how to think through a problem. One in particular would do things like give you a quick hour on the syntax of Ada and the compiler with which he was currently toying and then give you a program and the assignment was to find and fix a bug he would describe. In another class, operating systems, we wrote a program to simulate different task schedulers complete with keeping track of a simulated memory heap and managing the task list like an old time-share system (waiting on i/o, actively running, ready to run, etc.) so we could see the effect of different scheduling policies and their implementation challenges. He wanted us to think, not just regurgitate a pre-digested answer.

This description of a 'JavaSchool' just indicates a school that thinks of itself as a trade-school. While his separation of M.I.T and Duke is appropriate, the Java tag is just unfortunate. There are several other candidate languages that could have had the same fate befall them. This trade-school behavior is evidence that industry doesn't want good programmers, it wants lots and lots of o.k. ones. It isn't much different from the Industrial Revolution changing our high schools during the previous turn of the century from places of learning (anyone learn Latin in H.S. anymore?) to an 'education' factory churning out workers with a mass-produced education that was just enough to get them one of the mass-produced jobs at the burgeoning new mass-production factories.

A Codewright is someone who drives his or her own education and does not rely on someone else to make such decisions. A Codewright is someone who enjoys learning because it means they can do what they love that much better. A Codewright transcends education and explores the world of truth for no other reason than, "because it's there"; anticipating that tidbit of knowledge that will provide the spark of inspiration for the next masterwork, knowing it to be just around the next corner or over the next hill. A Codewright keeps their feet on the ground, always the pragmatist; and their eyes on the stars, always the dreamer.

Delicious Bookmark this on Delicious

Monday, May 11, 2009

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.
Delicious Bookmark this on Delicious