TITLE: Don't Forget Your 3000-LOC Check-Up! AUTHOR: Eugene Wallingford DATE: July 06, 2011 12:23 PM DESC: ----- BODY: Yesterday, Michael Feathers tweeted:
If a code base is more complicated than a car, shouldn't it have a maintenance plan too?
I asked him, "Refactoring every 3K miles?", and he joked back, "Well, maybe every 3K lines." I had thought about using LOC in my tweet decided to stick with the auto analogy. Whatever its weaknesses, LOC seems to be the first place programmers' minds go when we talk about the volume of code. (Though, as much traveling as Feathers and other big-time consultants and speakers do in a year, maybe 3000 miles is the right magnitude after all.) Feathers makes a serious point, even if he didn't mean it too seriously. When we buy a car, we implicitly accept the notion of scheduled maintenance: change the oil every so often; have the engine tuned up every so often; replace the battery and rotate the tires every so often. We accept it because we know that it makes our car run better and last longer. When we buy software, we want it to run forever, as is. Or the company who sells it to us wants us to run it as-is forever -- or buy a new version. Imagine having to buy a new car as soon as your current car started coughing, wheezing, or seizing up on dirty oil. I mentioned refactoring in my joke because it is part of the maintenance plan built in to XP and used in so many agile approaches to software development. XP discourages long-form maintenance in the form of refactoring every few months or even weeks. Instead, it encourages a sort of continuous maintenance, in a tight test-code-refactor cycle. It's kind of like checking your car's oil, fluids, tires, etc., after every use. When we do that to a car, it's usually because the car is in bad shape, breaking down as we try to extend its life. But continuous refactoring of a code base is usually a sign of robust health. It means that we know our code is in good shape and ready for use -- and extension. Teams that maintain their code on automobile-like time scales are usually sitting on a time bomb. Users may be able to use the code, but the programmers dare not touch its internals. My other thought as I tweeted was about our inability, or perhaps unwillingness, to make this idea come alive for the students in our university CS programs. It is an inability because it is so hard to create ways for students to live with any body of code longer than a semester or two, and time is a necessary ingredient facing the need for maintenance. Of all my project courses, compilers seems the most frequent teacher of this lesson. A semester may not be long, but a compiler is complex enough, and a non-trivial language spec hard enough to understand, to accelerate the sense of age and deterioration. It is perhaps an unwillingness because most every CS faculty I know makes very little effort to change courses and degree programs to make this lesson approachable. The good news is that making changes to bring this idea within our students' learning horizons also brings a lot of other important software development lessons within their horizons. -----