Whoa!  Why does it need fixing if it is not broken?

I'd like to explore the definition of "broken".  Here is a modest list of signs of broken code.
  • A test is failing (I know, painfully obvious)
  • The code doesn't do what the user expects. (Likely, you actually have a broken test or it's missing altogether.)
  • The code is hard to read, hard to enhance and brittle.

I think the first two bullets are obvious and the customer will see the value in fixing the code.

The final bullet leads us to refactoring.  How do we know when we need to refactor?  I won't get into the details, but, perhaps from a simplistic perspective, I refactor code to do two things:  reduce duplication and reduce complexity.  Jeremy Miller has a nice post on the subject.

Certainly, we do not want to fix something that is not broken.  The point is that, perhaps we need to revisit what it means for code to be broken.  The code is broken if we are constantly having to fix it after making a "minor" change.  The code is broken if it takes us days to add something we expected to be relatively simple.  The code is broken if J. Doe is the only one comfortable enhancing it.

It is important to note that the code is not broken in this sense until we are ready to make a change to the code.  We should remember YAGNI when we are refactoring.  Refactoring for something we are going to need just means we are likely to refactor the code again when it comes time to add something we actually do need.

Can you think of other signs of broken code?
If there is ROI in regard to refactoring, where do we draw the line?

posted on Thursday, August 28, 2008 10:55 AM
Filed Under [ Agile Design Productivity Quality ]


# re: If It Is Not Broken, Fix It
posted by Mike Ellis
on 8/28/2008 2:06 PM
Thanks for the post.

I've been amazed recently at how many odd looks I've received for pointing out deficiencies in the code. The group consensus seems to be if the testers (all tests are manual at this point) don't say there's a bug, there's nothing wrong with the code. Well, the testers aren't perfect, some bugs are difficult to produce, and some things just can't be black boxed, such as coding standards, best practices, maintainability, etc.

Post A Comment