The Mindset

In an ideal world every element of your design and every line of code would fit perfectly into the big picture. However, in reality, sometimes we have to create patches and workarounds to meet an ad-hoc necessity. There are cases which require some sort of an emergency fix “just until we have the time to sort it out properly”.

If you read my blog regularly, you probably know that I disapprove of such fixes. I strongly believe that the best approach in such cases is to solve the problem as part of the the big picture and make the fix coherent with the rest of the code. Quick-and-dirty fixes will cost you more than the correct implementation.

However, there may be special cases where you cannot avoid a real emergency fix. The question then is how to reduce the negative effects such a fix has on the internal quality of your product.

Use a Red Flag

The key to managing quick and dirty fixes and workarounds (apart from not using them) is to clearly mark them as a such.

The worst thing you can do is to let an ad-hoc fix just lie there as part of the production code. A developer trying to work with the code has no chance of understanding whether a certain piece of logic is part of the “intentional code” or merely a workaround. And if developers working with the code do not know which parts of it are merely ad-hoc workarounds, there’s a good chance these parts of the code will stay there forever.

You can probably see how this makes the code more complex than it really should be. Software which is built one patch over another is bound to become a maintenance nightmare.

If you clearly mark workarounds in your code, any developer working with the code will be able to identify them immediately. If you also clearly state the purpose of the workaround, any developer will be able to consider whether that workaround is still needed or not, and if there is anything that can be done to provide the more consistent implementation. In other words, the developer working on the code will be able to improve it now that the pressure is off.

Annotating workarounds does not mean just commenting them. By annotations I mean a predefined comment format that is easy to look up and identify. It is important that any developer coming across it will immediately realize that the code he is reading is a workaround which needs to be addressed.

Remember, when in need of a workaround, first try to avoid it. Do whatever you can to implement a proper fix. If you can’t avoid a quick-and-dirty workaround (I mean really can’t), mark it clearly. Let everyone touching the code know that it is merely a workaround. Let them know what was its purpose.

If you come across a piece of code which is marked as a workaround, do whatever you can to fix it and turn it into a natural and consistent part of the code.

This entry was posted on Tuesday, June 27th, 2006 at 11:26 am and is filed under Code Quality, Complexity, Simplicity, Refactoring. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.