There was an interesting article on Coding Horror yesterday, the gist of which was simply that it really doesn’t matter what your code looks like. Later in the day, I saw another post saying, “Everyone cares what your code looks like”. Obviously, both statements are false. Ah, Beautiful Code… the Holy Grail. It’s been assumed since the Fortran days that pretty code is the goal, but GOTO, etc. meant that it wasn’t going to happen. The authors at Coding Horror give examples from an employee of a well known and popular open source database company. I also know someone who works for a very popular open-source database company (I wonder if it’s the same guy…) who has mentioned that there are comments in the source code along the lines of, “I don’t know exactly why this works, but it does, so please, for the love of all that is holy, don’t change this section!!!” and “written in a drunken stupor, but it seems to work”.

It does work. Fantastically well. Everyone seems to like the thing (except for people who really want or need enterprise-level management and administration tools.) The code is horrible, but the client is happy. And that’s the point. Some of us are in it for more, for the pleasure of writing code and solving horrifically complex problems, but at the end of the day, if the client isn’t happy, they don’t pay, and the electric company will eventually cut off the lights. And it’s hard to program on paper in the dark.

There are the people do care about what your code looks like. And guess what, it isn’t the client… at least at first. “Max” is right — everyone who has to deal with the code from a maintenance and extensibility standpoint cares a great deal what your code looks like, and that is going to make the client care. This usually takes the form of a call from the client, asking where the new features are, or why the new features seem to break other things that worked fine last week. We’ve all had the pleasure of such calls, I’m sure.

It’s a balancing act — you do have to care about the beauty of your code, for the sake of your own sanity and that of those you work with, but the “Beauty of the Code” issue can quickly become a much larger issue that will directly affect the client. As soon as it becomes a “Oh, we can’t ship code that looks like that”, there is a problem. The client really doesn’t care in this sense, so long as the product works and ships on time.

And of course, there is a vanity issue at work. Pretty code has come to be a method of establishing a pecking order in organizations. “I am a superior developer because I produce superior code, which is by definition pretty.” There is some truth to that, obviously, but superior developers (and superior development teams) are concerned with elegant and timely solutions to their client needs. In my opinion, “timely” is the item there that might need to be stressed more strongly.

It’s a matter of pride that the product is pretty on the inside, obviously, but in the end, the only one who really cares what your code looks like is you (plural — the corporate you). You are going to either benefit or be penalized for “ugly” code. So perhaps the title of the article should have been “Nobody Else Cares What Your Code Looks Like”?