Upgrade Early, Refactor Often

This can also be titled: Update Early, Rewrite Often

I've seen a bunch of really crappy code and in this post I'll give my take on code maintenance, refactoring and upgrades.

When you maintain code, the purpose is not just to keep the code working. Some people spend their time making sure the code is working properly. Working properly isn't good enough. When you maintain code, you have to make sure it will be working in the future. A metaphor would be maintaining a house. You make sure that all the appliances are working, the water is running, and the phone line has a tone. However, you must also make sure that the foundation of the house is strong and firm. You can't wait until the roof falls down before noticing that termites have eaten holes through the frame. Or for rats and cockroaches to bite your face before noticing them.
Kia Kroas :=: 16 Jan, 2010 06:11:36

When you maintain code, you have to make sure that it is working now and it will work in the future.

The second condition requires effort to do correctly. Some code maintainers are only assigned to the task of assuring the code works properly instead of assuring it will work properly in the future. Sometimes this flaw lies with the managerial office where the lack of forward, future thinking masks itself as lack of funding, and sometimes it lies with the maintainer because of laziness or inability to comprehend outdated, legacy code created by somebody else. Whatever the reason or excuse, if the code can not stand in the near future, it is not being maintained.

The cost factor of maintaining code for the future seems most important for businesses. It takes time and resources to maintain code for the future. It is difficult to redirect more resources and capital to maintain a piece of finished software when it could be spent on other departments. However, all programs will have bugs after it is released and any company that wants to package a service alongside its software will have to address any bugs, errors, and feature requests that arise. And on the impossible chance that your software is perfect and bug-free, then consider other software updates and operating system upgrades. You will have to do maintenance eventually, start now and iterate slowly instead of rushing later and pushing messily.

Software tends to be very fluid with features tackled in quite often. The casual end user, fortunately, almost never lays eyes on the horror of the source behind the software. Programs that have survived many feature additions tend to have enormous hacks lodged throughout the source code either for backwards compatibility or adding features not planned for in the original design. At some point, it becomes more efficient to rewrite the entire monstrosity from scratch than to add more chaos to the jumbled mess. If it comes to that point, something is seriously wrong. (You can't trust programmers when they say a total rewrite is necessary unless they are experienced and have been working with the code for a while. New programmers, especially the younger ones, will always want to rewrite old code from scratch. Often times, the cost of a rewrite is more trouble than they thought. I'm one of those hot-shot younger programmers. I know.)

Code that is maintained should never need a complete rewrite.

Okay, maybe not never, but almost never. Source code that is properly maintained for the future should undergo refactors often. This may not be small refactors, perhaps the changes require a rewrite of a large chunk of the overall code because the original design had to be reimplemented differently, or perhaps the underlying technology has updated and deprecated items used in the original design. Very significant design changes that require reimplementation of the overall code base may be better off as a new application. A large change in overall design is a sign of a change in the goals of the software. Good refactoring removes the need for piling hacks on top of hacks. I like hacks and tricks as much as any other person, but they get confusing and look ugly.

I am advocating dividing the maintenance costs over time instead of lumping the cost all at once when a complete rewrite becomes necessary. Continuous refactoring of source code keeps the programmers happy and gives them a better understanding of the software they create. It keeps the source clean and friendly for any new programmers that will work on it in the future. Refactoring stands on the same platform as documentation and source comments. Complete rewrites produce brand new (sometimes clean) code, but it has not survived against the barrage of bug reports that its predecessor lived through. And bad maintenance on the new code will lead to another rewrite again.

I am most familiar with websites as a form of software, so I will use it as an example of software that must be maintained for the future. Websites need a web server and are usually written in a scripting languages such as Ruby, PHP, or ASP. On top of the scripting language is the framework or libraries that aid in creating websites with the languages such as Rails, CakePHP, or ASP.NET respectively. This sums up to three major dependencies already without naming dependencies of the dependencies. If any of the dependencies change too drastically, then it will require a rewrite of the source code.

Not updating the dependencies results in maintaining an outdated and insecure website. Updating the dependencies risks breaking the code. This is why you must maintain source code for the future. To maintain a website, the administrator or maintainer must check the recent edge versions and release candidates for changes that will affect the site. There is some diligence that must be had, especially upon a major version change. Refactor the code slowly as the changes and plans are being released. When something breaks, it will be something small that can be handled quickly. Waiting until the last minute to update the security releases is horribly irresponsible. Waiting until an old major version is deprecated and dead before switching to the new version is terrible practice. (Every once in a while, I see websites created by web developers who still run PHP 4. They should know better.)

Any enterprise-level programming language or framework publishes release candidates and snapshots long before the actual release is available. This is the chance to scrutinize development and staging environments for maintenance. Watch and clean up anything that breaks when tested using release candidates, perhaps comment on any concerns with something that breaks. There's no stress because there is no time constaint.

Any website out there must be maintained for the future to keep up with the competition. It must be ready to scale before users' browsing slows down the site. Although execution is different, all software should have similar goals--at least in the general sense. Small incremental updates are better than big rewrites.