Eitan Suez's Blog

Extreme Programming Archives

Stoked: Not Just for Surfers Anymore

I sometimes enjoy describing feelings a software developer might experience, at certain moments during development. For example, a while back I blogged about "Grazie Signore" moments.

This past weekend I attended the Northern Virginia Software Symposium and was fortunate to have a little time to spend with my NFJS comrades. A most vivid comment that Justin Gehtland made during one discussion was how stoked he was about this software we were discussing.

It occurred to me on the plane ride back to Austin that the term "stoked" is normally used to describe the feeling one gets when surfing. Perhaps it's also applied in the context of extreme-sports related activity.

To my wonder, the term could be applied, and very aptly so, to moments that we, geek software developers, have in our work. That feeling arises when we do something that we think is extremely cool, that perhaps hasn't really been done in that particular way. For example, I sensed that feeling when reading a weblog I came across on java.net a while back, having to do with a very cool idea that occurred to one of the Wicket Framework developers. See Wicket + Swing == hmmm...interesting....

I believe that this feeling is the driving force behind the hordes of us out there, of any age, who spend their spare time coding, pursuing the creation of something that, to them, is so incredibly cool. So, just like surfers can't stop surfing and continually strive to be in that most special state of being stoked, so do software developers.

Code Rot: Mental Exercise to Better Understand Code Rot

My brain has been slowly digesting the concept of code rot, triggered by skimming random articles or blogs that have recently mentioned the term. Code Rot. It's a good word. We've all experienced it. But it's another thing to understand it. What is code rot??

The process of evolving and improving upon code is a dynamic one. Some say it has a life of its own. But its thread is fragile indeed. So many software projects end up being abandoned, scrapped, killed. It happens slowly and sometimes it takes a while to realize what's happening. Even though a good term, the code itself doesn't really rot. Do you recall the sales pitch for moving from the old "analog" world into the new "digital" world? The claim was that in a digital world, the signal never fades. Its amplitude is encoded into bits and thus its value can be restored with precision. So the code doesn't really rot. It's the same old bits.

It occurred to me that software is similar in ways to the little i recall from my study of viruses in 10th grade biology class. The real issue here is that the tango of writing code is danced with two partners: the programmer being one of them, and the code being the other. Our minds are frail, and they tend to forget. Just as telecommunications signals fade and need to be amplified at certain intervals, so does our memory.

As we write code, we say that the code starts to take on a life of its own. What do we mean by that? The code we write may satisfy our original requirements. But that does not mean that it's so tight that it can only satisfy those requirements. There's always a little extra room, certain combinations of paths that will produce a bug or unintended behavior. Furthermore, the knowledge of the system begins to split between the code and the programmer. There's what's written down in the code. And then, there's what the programmer discovered while writing the code, or while refactoring the code, and that he (or she) didn't write down. Certain protocols perhaps, certain frailties in the code, something to revisit at a later time, after the deadline has passed. This is the substance of code rot. This knowledge is somewhat essential. It's kept in short term memory. It needs to be refreshed. If it's not, then treading through the code becomes more difficult. A new programmer has to deduce and learn this unwritten knowledge on his own. So documentation helps fight code rot. Take the time to write documentation. Some things are easily inferred from the code. Others are not. Put that information in the code itself so when the code changes, this information gets revised accordingly.

I just got an email from a friend saying:

I'd also like to thank you for leaving a help file on your projects, namely the code at . I've run across legacy code from another dev, and I'm having trouble finding where to start.

The code is like the DNA of a virus. It sleeps, and waits a human being to come and discover and reactivate it. A fluent understanding of the code requires one to constantly review it, work it, refactor it, practice it. It's not just an exercise in learning, but just as much an exercise in refreshing our memory cells and re-acquainting ourselves with software that oftentimes we ourselves had written, but have forgotten. If not tended regularly, a certain fear starts to set in that prevents us from getting more intimate with the code.

One of the reasons I'm a big Java proponent is that the fight against code rot is already a difficult and constant one. Furthermore, one of the activities necessary to fight code rot is (as i've already stated) the constant review and improvement of existing code. The diligent practice known as refactoring. Even if you end up changing the code and then changing it back to its original state, the exercise would not have been in vain: you are now re-acquainted with it. Other languages [shall we say] lend themselves more easily to obfuscation abuse. If code is difficult to read, then this precious task of re-learning one's (or someone else's) code becomes much more difficult. The weight you're carrying now going up that hill has doubled.

One of the ideas that my brain has subliminally decided to share with me, is that Code Rot is very much related to the concept of what people call "writing maintainable code." I believe "writing maintainable code" mostly means "writing code that makes the fight against code rot easier."

Let's expand on the virus analogy. A virus is not categorized as a life form. Most of the time it's not actually alive. I guess it's dormant: a bunch of code just laying there doing nothing [my learning of biology started and ended in 10th grade so please go easy on me here]. Some event triggers it into activation (maybe it bumps into a cell), at which time its "life" resumes and its code suddenly starts executing again, hijacking some poor cell nucleus and running the cell's machinery against the virus's DNA instead of the cell's. The other side of the analogy (hacking) may go something like this: we discover some piece of code (maybe we join an open source project, or maybe we pick up an abandoned open source project on sourceforge) and start familiarizing ourselves with it. The code-programmer duo starts becoming alive again and the software starts to evolve again, to improve. This is the opposite of code rot. Project success is analogous to the virus winning and overtaking its host. First a few copies are downloaded, news of the code grows, more downloads follow. Before you know it, this code is replicating itself all over the world. The main difference here is that our software virus is a good one. Hibernate is such an example. Eclipse is another. JBoss is yet a third. Code rot is on the other side of that curve. When the project velocity goes down, when bugs are not being addressed at the rate that your customers approve of. It's a hard fight.

What can we take away from this mental exercise? One is that the ingredients of a successful software project are code and programmers. That people and computers exist today in some sort of symbiotic relationship. That "Code is like Tang: Just add programmers and bang! You've got a success story?" (is that what the .com boom was all about??) :-)

Ok, let's get a little more serious: awareness of the notion of code rot is important. Code is dead without good programmers to wield it. Programmers that care enough about the code to tend to it daily. Management should not underestimate the cost of human resource turnover in the software industry. One of my previous jobs was at such a place, where little importance was lent to the knowledge original programmers had in the systems they developed. XP is a good recipe to fight code rot. Test driven development: Amen! Pair programming: Amen! Refactoring: and let us all say.. Amen!

This work is licensed under a Creative Commons License.