Making code maintainable: mind your edit-per-change ratio

One of the most fundamental problems when dealing with the world on any level, whether your issue is technological, physical, or conceptual, is handling change. People are fond of saying that the only constant in the world is that things will change. That’s certainly true, but that nugget of wisdom doesn’t actually tell us what to do about all these inevitable changes.

In some industries, such as construction (for example), people are very careful about what they do because they know how hard it will be to change something after the fact. In the digital workplace, however, people don’t seem to think as much about this sort of thing because it’s relatively easy to change things. After all, everyone’s dealing in bits and bytes at a fundamental level. However, if you take a higher-level look, you’ll see that many times things are not as easy to change correctly as you might think, and the costs associated with these mistakes and after-the-fact edits can be enormous.

Take a web site, for instance. (I bet you saw that coming.) After a web site is launched (and even before, sometimes), changes have to go back and forth between designers and coders, production and design, and back again. Many times so-called final versions are just the next revision and not actually set in stone, no matter what anyone says. For a web developer, all these changes can be really troublesome, however they also provide an opportunity for rapid, iterative improvement of your (X)HTML and CSS code.

In a recent project I worked on, I found myself faced with the challenge of positioning two columns of data that each had a different number of elements inside of them but that ultimately had to be the exact same total height. My production manager, who fell in love with floated layouts a long time ago, wanted to position the page using one column floated left and the other floated right, with their dimensions fixed so as to give them both room to fit inside their parent. This seemed perfectly logical to me, so I implemented it that way.

As the project moved forward, however, I realized that in our design changes to this kind of floated layout would require a minimum of editing two files. First, we’d need to edit the HTML source of our page to change the order of the content boxes inside the floated columns, and second we’d need to change the dimensions of the elements in our style sheets. Instead, reimplementing the design with absolute positioning would require edits to only one source file, the style sheet itself, where both the position and the element dimensions could be specified in a single CSS declaration.

With all the frequent changes the design department was making, this argument ultimately won everyone over, and the site uses absolute positioning for the design. The key concept to take away from this experience is that part of making things easy in the future is to design with change in mind, to be as flexible as possible from the get-go, but also to think about the actual implementations in such a way as to lower your edit-per-change ratio as much as possible. The fewer things you have to change, the easier it will be to change things moving forward.