If it's not broken, maybe you should fix it anyway

Jared Parsons — Mon, 13 Oct 2008 15:00:27 GMT

I know this is goes against conventional wisdom but it's something I believe in. Every sufficiently large project has that section of code nobody wants to go near. The mere mention of it causes people to leave the room. It usually has a couple of properties

Old and Stagnant
Critical or important routine
Fragile
Written by a developer who doesn't work there anymore
Undocumented
Untested
Poorly understood

But it works and usually has for several releases. By conventional wisdom it is considered "unbroken" and not worthy of changing.

I disagree. Very often I find towards the end of the cycle more and more bugs start popping up in this code. It's a pattern I've seen in many groups across releases. These bugs are extremely expensive to fix because they are a) at the end of the cycle and b) being make in a piece of code that no one understands. Since it's not broken nobody bothered with the code and hence it stayed poorly understood (and likely just as untested). The bugs are doubly worse because no one wants to go near that code for fear of breaking the world.

Why let this code hang around in it's current state? It's bad and no one understands why. It's a constant source of pain late in the cycle and often in the middle.

I prefer to take a more proactive approach; fix it.

At the end of a product cycle I like to identify these pieces of code and attack them in-between releases. This is a relatively safe point in the release cycle to change poorly understood code. There is an entire release cycle ahead to catch the bugs introduced (and there will be some).

I don't break this code without thought. I prefer to take a pragmatic approach to the code in the following steps.

Attempt to understand the intent of the code (easier said than done). I contact the original author if possible
Poll the more senior developers on their understanding of what the code does
Design a new architecture if needed
Design a test plan (this is the absolute most important step. Why fix this if you don't bother testing it?)
Make the change

I've done this, or overseen someone else, on several pieces of code over the last few years. Thus far it's been a very big success.

C++ Refactoring: Default booleans and pointers

Jared Parsons — Mon, 29 Oct 2007 19:36:02 GMT

This is another recount of an experience I had refactoring some C++ code recently. In some ways this is also a follow up of my previous post about why you shouldn't use boolean parameters (especially default value ones).

I recently refactored a large set of API's in our code base to remove a common parameter. It was a member variable that was constantly being passed as an argument. For many reasons we decide that this was unacceptable and it was better to use the member variable for instance methods and if needed define static methods which took the parameter as a value.

After making the switch I recompiled and starting running regression suites on the code and found that a whole set were failing. It turns out that many of our methods had the following pattern.

class Student;

int CalculateValue(Student *pStudent, Manager *pManager, bool cache=false);

The parameter I was removing was "pManager". So now we have a function that used to take 2 or 3 arguments and now takes 1 or 2 arguments. Unfortunately, now all of the places that used to call this function with 2 arguments will now recompile without warning since pointers are implicitly convertible to booleans.

No matter. Redefined the method with the same arguments and did not specify an implementation. This caused compiler errors where necessary and allowed me to fixup the calling code.

Boolean parameters are troublesome. Defaulted value boolean parameters are much more so.

Yes you could attribute this to the fact that I didn't fully think through a subset of my changes and that's certainly fair. However if we practiced good coding standards up front, this could have been avoided. If we had originally done any of the following the code would be more resilient to changes.

Chosen an enum instead of a boolean parameter
Forced the caller to specify the boolean parameter by not providing a default

jaredpar's WebLog : Refactoring

If it's not broken, maybe you should fix it anyway

C++ Refactoring: Default booleans and pointers