Programmers Don't Like to Code: Followup

My little rant was unexpectedly popular. Here’s some notes based on email I’ve received about the posting:

• Scott Rosenberg responds on the reddit page originally posted by Peter Hosey. He brings Constantine’s actual quote to the table, to which I also concur Scott didn’t “butcher”.

  Scott’s also right that he didn’t suggest programmers capriciously rewrite code. Please excuse my poor composition if that was the impression I left. No, for that my caffeine-addled finger of accusation sweeps in the direction of Spolsky. (Who, to be clear, I’m a fan of. I’ve bought all his books and have learned a great deal from him. I simply disagree with his explanation on this topic.)

• Constantine’s quote. Jerry W. Walker sent me an extensive email providing rationale behind Constantine’s assertion. I’m reprinting it at the end of this posting since it would be shame to excerpt it.

  I was ready to soften my stance towards Constantine’s quote based on Walker’s framing of it as an “that was then, this is now” misunderstanding. However Joel Norvell pointed me towards the origin of the quote, Constantine’s The Peopleware Papers: Notes on the Human Side of Software (preview here). While Constantine addresses the topic of libraries, it’s clear he falls on the side that coders love to code. That book is circa 2001, so this is not a 1970’s throwback quote — I bet he believes it to this day. As you know, I disagree.

• The tone. Rosenberg mentions “ire” in his comment, and Joel Norvell thinks I was mean-spirited. Gah, sorry if it came out that way — I can be tone-deaf to how I’m presenting my mindset. Part of it is that I didn’t use “butcher” like normals do: here I used it as a way to describe what I would do in an interview when trying to recite any nontrivial quotation (which Constantine’s quote qualifies as). I think Rosenberg did a fine job quoting it from memory on-demand.

• Bubble-land. While the majority of the email I’ve received on the posting was along the lines of “I agree, thanks for writing it up!” there was a telling vocal minority that shared a common critical refrain: “you don’t work with the idiots I work with.”

  That’s true. I’m very up-front about this: I live in super-happy-fun bubble-land. Through some mashed-up application of accident and intent, I’ve surrounded myself with passionate, gifted people who care desperately about building great software.

  I’ve been in this bubble for many years, and my only dealings with cold hard soul-sucking reality is when I’m dropped into broken projects and my readings of The Daily WTF. So yes, it’s quite possible (likely, even) that your physics are different from mine.

Jerry W. Walker’s email:

Hi, Jon,

I was directed to your weblog page, “Programmers Don’t Like to Code” by a reference on CodeFab’s Random mailing list. This wasn’t my first visit to your weblog and, consistent with the overall quality of your writing, it was a fine piece of work. As a contemporary of Larry Constantine’s, however, I would like to offer some support for him and his comments in light of the comments you made in the opening paragraphs of your article. I’m not certain that Larry made the comment which was attributed to him, but if he did, please understand that it was made in a programming context far different from that which we enjoy today.

As a programmer today (yes, I still am), I tend to agree with you that today our larger joys come from:

• problem solving
• understanding
• learning
• the achievement of elegance

However, the first of these joys, “problem solving” is only a motivator today because, like Pavlov’s dogs, we’re rewarded when motivated by it. Using it as a motivator 30 years ago would not have gotten you very far. If it were your sole motivator during the days that Larry Constantine wrote his book, you would have left the field. The pure joy of programming was what kept us going because we were so bad at solving the problems. The success rate of software in those days was incredibly low. If you would like to know how low, check the work of Capers Jones, who was one of the first in our field to do a reasonable job of measuring our efforts (or at least was one of the first who succeeded at publishing those measurements).

Larry first became well known for a 1974 technical article in the IBM Systems Journal, and later from his book by the same name, “Structured Design”. The book was co-authored with Ed Yourdon, who started a very successful company (Yourdon, Inc.), largely based on the success of that book. The company’s primary business was to teach the concepts of Structured Design and Structured Programming at a time when almost no one in the software development field had heard of Object Oriented Programming. (OOP had been around since about the mid 60’s in simulation languages, but it never became particularly popular for anything outside of simulation until around the mid 80’s.) During the writing and following the publication of their book, the bulk of Larry’s work in the field was from subcontracting to Yourdon, Inc. I was a staff consultant there, which was how I first came to know Larry.

At that time, a huge proportion of programmers were not well trained in programming languages, software architecture, systems theory or any of a number of other technologies that we take for granted today among professional programmers. They were typically not even well trained in their own primary programming language which was, more often than not, COBOL. As a result, there was an enormous amount of bad code around. The majority of commercial software projects failed! They didn’t solve problems, they created them. :-)

Though code re-usability was something of the holy grail among software managers of the day, about the only software any professional would re-use, was that which they had written themselves.

It was incredibly difficult at the time to mix languages. It was even above most programmers’ expertise of the day to mix their own assembler routines with, say, Fortran or COBOL (if they could write assembler in the first place). So the availability of software to do what you wanted to do was typically insufficient to make that software available for your reuse in your chosen language. Worse, most software was written with large numbers of side effects (high coupling and low cohesion in the language of Structured Design) which made it unavailable as utility software even if it was written in the language you had chosen and directly solved the problem that you were addressing.

For a number of the reasons you mentioned, I liked to program. However, I also liked to program purely for the sake of programming, that is, for the purpose of successfully directing a computer to do something and see it do it. Problem solving was a delightful dessert to the main course of slogging code together and getting it to work. Given the low quality level of most of the commercial software we were asked to maintain, we would almost always rather code than even try to read through it.

There were, of course, libraries. These basically consisted of the math libraries and low level I/O libraries used to support the languages and operating systems of the day. If you were programming in Fortran, you would expect to use the Fortran Math library rather than code a trig function in assembler yourself. That, however, was about the extent of code re-use beyond using subroutines that you, yourself, had compiled and collected. As a professional programmer continued in the field, they would begin to realize the benefits of low-coupled, highly cohesive, utility subroutines, and would write and save enough of them to give them a professional advantage. But almost no one would have spent much time searching through the available code of the day to collect others’ work. That just tended to be a losing proposition.

People who are programmers today are a breed apart from those who called themselves programmers in Larry Constantine’s day. Today, I too am frustrated when I have to write code to do something as low level as parse XML. The last few years of high quality, easy to integrate, software libraries has made me so.

I would suggest that the most successful programmers of that age were those who were good at algorithmic reasoning. The languages (any number of assembler languages, Fortran, COBOL, PL/I, C and such) were generally easy enough to learn within a few days and you could get good with them within a month or two. I believe that the most successful of our programmers today, on the other hand, are those who are good at learning natural languages. I would suggest that the ability to learn, not only the Java language, but the Java packages and method calls therein, is a great deal more like learning French than it is like learning algebra or calculus. The active vocabulary has become huge.

As far as Larry Constantine and I go, we both left the field, so I guess we’re both good examples of what I’ve been trying to say here. Larry left to become an acknowledged expert on group marriages (sic). I stopped programming to go out into the world to teach better concepts of systems architecture and software design. Instead of a programmer, I became a teacher, lecturer and a consultant to those teams I taught. It was so much easier teaching good architectural methods and concepts than trying to make them happen in the real commercial world of the day.

Larry later returned as something of an impresario, organizing and running software conferences and such. I had always kept my hand in and dabbled with such as C programs until Object Oriented Programming had clearly won the architecture war. It made the concepts we were teaching in Structured Programming, Structured Design and, eventually, Structured Analysis, not only eminently reasonable, but ultimately, about the only appropriate approach for solving most commercial software problems.

I got back into commercial programming by extending my knowledge of Unix and C into Objective C, WebObjects and, ultimately, Java. Today I’m constantly rewarded by problem solving. I don’t wish to program that which someone else has already programmed and made, not only available to me, but available with a pedigree so that I know I can trust it. But I also recognize that if I didn’t just love to program, I would never have come back to it.

Today, I can start a fairly large programming project with a 90+% expectation of succeeding. Back in the 60’s and 70’s, I would enter any reasonably large software project with the additive inverse, or about a 10% expectation of anything good coming of it.

If this causes you to ask why any company with even minimally competent managers would ever start a software project in those days, it was mostly because when a project succeeded, it brought several orders of magnitude improvements in productivity over the mostly manual operations that it replaced. It was a bit like the slot machines in Las Vegas. It only takes one to dramatically “hit” now and then to keep all those other suckers pumping their coins into a losing proposition.

Thanks for listening and, by the terms of your blog “Contact Me” page: yes, you’re welcome to share any of this that you so desire.

Regards, Jerry

Monday, February 05, 2007
12:00 AM