02 July 2008


Especially with a code base that is mature, assumptions correctly made years ago can be terribly difficult to deal with later when the current and new assumptions reign. Writing code that lasts even 5 years and "is robust" is what everyone wants to do for sure, but the recipe for doing just that is not easy to learn and even harder to actually do. For example, you might know what changes need to be made to conform to even the most obvious object oriented design principles, but the business requirements and time to market needs dictate leaving once again old crusty code alone and racking up yet another round of technical debt. Over time, this technical debt will demand payment and the effects on your ability to hire, employee morale, design changes possible, speed of delivery, testing burden, marketing message etc. become very real and very painful. I wonder, can these concepts can be fully learned without actually experiencing pain? Could you even attempt to learn these concepts experientially in college? My experience so far makes me think that one may know something intellectually, without really knowing it. It seems like for so many, one may talk about design patterns or abstraction or low coupling, but until you actually try to build something the other way, the painful way, you just don't appreciate what you are avoiding. What's worse, junior developers who, for no fault of their own lack experience with "the hard way" have a difficult time understanding why one must "go the long way around" to do what seems like such a direct solution. Passing on the stories of the past and their consequences and lessons seems to be an unending challenge.

From my economics book comes this fictional story which I think illustrates the point:

"One Pepsi plant is managed by an economics major with an MBA and has a labor force with an average of 10 years of experience. This plant produces a larger output than does an otherwise identical plant that is managed by someone with no business training or experience and that has a young labor force that is new to bottling."

I definitely fall into the "young labor force that is new to bottling" camp. In the technology industry there is a tendency to glorify the young and bright rather than those who have the experience and have paid the price to learn the lessons that matter in the long run. Whenever I talk to some developer and we talk about where they learned some valuable lesson about software development, rarely do they refer to a book. Almost invariably, they say, "I worked with Joe on this project and he showed me x, y and z. I learned so much working with him." Smart developers, experienced developers who know how to teach and share important lessons to junior programmers seem like a key to the experience problem. Sadly, junior developers who have the presence of mind to ask, listen and apply what they hear are hard to find, and senior developers who are both willing and able to teach effectively are even more rare.

Perhaps the answer to all this is simple. Perhaps it's just he or she who writes the most code, wins. What I mean by this is simply when one writes a lot of code that increases the probability that he or she will make more of the key mistakes needed to learn how to write software with longevity. Just getting more exposure to "how bad things can get" helps bring a sober reality to each line of code written thereafter.

What's remarkable about all this, is that failures in teaching and learning are what keep us "discovering" new ideas that are 40 years old. Truly, "there is no new thing under the sun."


Steve Coan said...

I like reading your stuff. It's true that experience is precious when it comes to coding. And what you suggest about writing more code to make more mistakes is true. I think that's one major factor. But there is another, and this one is probably even more important.

As a consultant and coder of close to 20 years now (oy!) I can tell you that experience has as much to do with the psychology of development as anything else. Maybe more.

I explain.

I remember a very stressful time in my professional life. I was in the corporate world at the time, and I reported to one of the best project managers ever, which you don't ever want to do. We had several initiatives that were literally changing all of the business software systems of the company. And the daily meetings were excruciating. I learned a whole lot during that period. But what I remember most of all came when we were having a high volume discussion about a particular problem, and what the right solution was. I was exasperated arguing against a course of action we were all headed towards. I remember yelling, THIS MAKES ABSOLUTELY NO SENSE! At which point my boss the project manager called everyone down, and let the moment settle for a while. He scanned the table and (possibly) cocked a slight smile. And then he said quite confidently, "Business is not logical. It is a psychological phenomenon."

I had no idea what to do with that statement. I just sat there.

Over the next 10 years I have come to rely and appreciate that statement, and never forget that the reason we do this is for people. At least it's for people today (I have seen the Matrix trilogy).

I later found out that my old boss previously studied philosophy and theology. He was a real sonofabitch, and I am forever grateful that I worked for him. And that I am not ever going to again.

The thing is, it's not hard to write excellent code. That is useless. Code that matters is code that solves business problems, solves human problems, helps bridge the gap between the power locked inside a computer and the power locked inside the human mind. It's a big gap, because the way information gets processed by the two are completely different.

And this really makes experience in coding very, very valuable.

I frequently take heat from younger, better educated, more current coders that work for my clients. And I have to defend my design choices. Why didn't I use this technology, or code it that way? Etc. In the end, I design things the way I think make the most sense to the people who will use them and maintain them. This comes from experience, not only with the strengths and weaknesses of code platforms but also with the strengths and weaknesses of people.

David Weiss said...

Great comment Steve! I've often heard the statement "building software is a social experience" and it really is. Software reflects the varied skill levels of people just as much as it reflects their personalities. Many times software also mirrors the actual company layout and hierarchy as well. Having to defend old software is never fun. Having to even look at your own old software is often painful. I've known a few great Junior developers who understood this and they would come with the attitude, "How does it work and what can I do to help." Thanks again for your comments.