Frank Sommers
Posts: 2642
Nickname: fsommers
Registered: Jan, 2002
|
|
Re: Where Did All the Beautiful Code Go?
|
Posted: Mar 29, 2006 2:04 PM
|
|
I think the original post's key point was not so much code quality, but that writing code that's hard for another programmer to understand can lead to a slide in the overall quality of the project.
This's actually easy to imagine. Considering language, few men have ever mastered the English language more than Shakespeare did. No one can deny that Shakespeare's writings exude quality, which is close to the highest quality experience one can have with any language. (We could substitute any other great writer or poet here, such as Hemingway or Verlaine.)
But imagine what would happen if Shakespare were your co-worker and he would send you his email messages in his own Shakespearian style, expecting a reply. Clearly, you could sit before responding to each message, chiseling the style of your response for a couple of hours. Even then, it's likely that someone reading the email thread as a whole could claim that your responses degraded the quality of the correspondance.
The point of the post, I think, is that writing code that's idiosynchratic, or even one that's too abstract, will cause someone else to not spend too much time trying to understand it, let alone write in the idioms of that 'beautiful' code. Instead, that person will just think, "Hmmm, this works, so I'd better not touch it. But I just insert my code here..."
What does that imply? For one, each project will have to decide the level of abstractions used. If such abstractions are too high, and require too much context to understand, then people will likely bypass them, lowering the overall code quality.
As others have pointed this out, quality is in the eye of the beholder. Would you consider a Shakespearian co-worker's email style high quality or just pompous and, possibly, counterprodutive?
One more point: Some devices that are supposed to improve code quality on occasion might, in fact, lower quality. For instance, I worked years ago an a Web site/enterprise app using Perl. I was rather experienced, and tended to repeat code all over the place. While I now frown upon that practice, I also recall that that code base actually worked really well, and was also easy to maintain: Since almost everything happening at a given place could be understood just by looking at a screenful of code, bugs were easy to fix and find. The low level of abstraction in the code made it easy to work with that code. I could get right to what I wanted to do or where I wanted to fix a bug, and be done with it.
By not having to hold a large context in the mind, working on that code was not mentally exhausting, and thus I could do productive work on that code base for many hours at a time. By contrast, when one has to keep in mind several layers of abstraction, configuration files, and such, much more is required of the mind, which leads to people becoming fatigued sooner, possibly leading to lower overall productivity. I think the saying "too clever by half" sort of describes this well.
> The sequence of events Hohpe outlined begins with the
> developer writing code that is serviceable for the
> application – it runs okay – but the code itself is
> idiosyncratic and hard for another programmer to
> understand. The along comes a programmer doing maintenance
> a year after the application goes live. The code appears
> to be a convoluted mishmash.
> </p>
|
|
Previous Topic
