[Estimated Reading Time: < 1 minutes]

Seth Godin recently asserted that

Don’t touch it! You might break it

is the opposite of

Touch it! You can make it better

I fully appreciate what he means by this (and we mustn’t forget that Seth Godin does not blog on the subject of software development, although a lot of what he says often has relevance) but in the world of software application support I think there is a middle ground in this case.

Improve it only if you are sure you won’t break it.

6 thoughts on “Break It or Improve It ?”

  1. The “don’t touch it” attitude is only a result of poor design and missing testability. If you have both to a certain degree changing things is much less of a pain because you immediately notice when something is not right.

    In the past whenever I refactored things (and sometimes rewriting parts from scratch) it was a breeze when it had proper unit/integration tests.

    1. Indeed, but unfortunately “poor design and missing testability” are sometimes an unavoidable fact of life when we are forced to work with other peoples code in whatever state they left it when they moved on and we are not always (if ever) allowed the luxury to improve our lot in this respect, even if it were practical to do so.

      1. If everyone sticks to the boy scout rule (http://programmer.97things.oreilly.com/wiki/index.php/The_Boy_Scout_Rule) then this is a good start. Yes, sometimes you have to deal with horrible legacy code. But if you have to maintain or even extend it imo its the the job of a responsible developer to get resources for improve/refactor/cleanup the code because it pays off in the future (see technical debt). Of course management has to play along.

        1. Needing to maintain or extend code is not an activity without context.

          In my 9-5 I am Tech Lead on a legacy application management and support team; Not an in-house team, but one which services clients. As such we are constrained in terms of how much freedom we have to determine the work we choose to do and even to an extent how we do it). The approach adopted by our clients when it comes to legacy Delphi code is to replace it entirely, usually with C#, but certainly never with new Delphi code.

          Our task in the meantime is to keep the clients existing apps ticking over, which means fixing bugs and making what few enhancements are absolutely needed (the threshold determination for which is itself that much higher). As consultants we can (and do) advise and suggest, but ultimately the client makes the call. Unfortunately in such circumstances there is rarely any appetite (not to mention budget) for spending time improving code that is already scheduled to be discarded (no matter how unrealistic that schedule perhaps is).

          I am sure you can imagine how difficult (read: impossible) it is to make a case for burning real budget now in exchange for potential cost savings and efficiency improvements (i.e. faster, more reliable changes) in the future on code that it has already been decided has no future.

          But it’s not all negative. Being forced to work within in such an environment presents a challenge in and of itself resulting in immense satisfaction when improvements are able to be successfully delivered even within these constraints.

          A New Hope was made at a time when George Lucas didn’t get all his own way and had to deal with being told “No”.

          The Phantom Menace was made when no-one told him “No” (and he could just ignore them even they did).

          😉

  3. The don’t touch it parts are usually the first areas I’ll look at understanding and improving as it normally will contain complex code prone to breakage.

    Though, it might already be well structured and I could learn something from it.

Comments are closed.