The Problem

When asked to make changes to an existing codebase , software developers tend to only focus on accomplishing the task and less on preserving the integrity of the existing codebase.  Whether this assignment is a small feature or bug fix, a developer is often asked to accomplish it by a deadline.  For an experienced developer, this is business as usual, and they have learned enough lessons for this not to be a problem. However, for an inexperienced developer, they will often neglect to consider something very important while implementing the software solution: the scope or effects of their changes in relation to the existing codebase.

The Example

After I had been at my first job in the industry for a month or so I had done nothing but bug fixes.  One day the head of the IT department called me into his office and asked me if I wanted to put a small feature in a legacy Rails 1.X application. Naturally I jumped at this opportunity to prove to him I was capable of more than just bug fixes.

The Failure

Initial Success

The task was nothing terribly complicated and I finished the majority of it without much trouble. When I was done I told the lead developer on the application and was instructed to test all of my changes manually (no testing suite for an application this old) for all the browser versions we supported.

Internet Explorer 7

When I was implementing this feature, one thing that I had never done before was a rounded border on HTML blocking elements.  Implementing rounded borders was rather easy after a little research (googling).  However, when I went to the page with the rounded borders using the test environment that emulated Internet Explorer 7 (IE7) my rounded borders were square.  I was determined to match the mockups given to me by the graphic designers and be deemed worthy of being given more complicated features. So I did even more research to figure out rounded borders in IE7 and I came across the answer. To save you a click, it is stated that if this line <meta http-equiv="X-UA-Compatible" content="IE=7" /> is present rounded borders will not work in IE &.  I quickly went to the root of the layout of the application and there it was, BINGO!  I changed the meta tag to  <meta http-equiv="X-UA-Compatible" content="IE=9" /> and voila, it worked!

The Fire

With testing complete and functionality completely on par with the specifications, I told my lead developer that I was done.  My code was pushed to production about noon that day and I headed to lunch.  When I got back from lunch the account manager that handles that application came to my desk right away.  She was telling me how users of the application couldn’t log a metric they needed to do daily (a very big deal). Immediately I thought to myself that I had never altered any of the code that dealt with metric logging so this is not my fault at all. Thankfully, I did not tell the account manager that and I told her I would be happy to investigate.

The Investigation

I quickly spun up the application locally and started to try to replicate the bug.  Sure enough, I could not log the metric either.  Thing is that I wasn’t getting any errors in the browser console or in the server log.  So, I started my normal bug fixing procedures and pursued that while constantly updating the account manager about the lack of progress I was having.  Quickly I began to panic and just as I was about to ask the lead developer to help me investigate, I did a quick check of the commits I made for that feature.  In my mind I thought all of the changes were in new files and so they shouldn’t be affecting functionality from existing files, right?  Well I was wrong about ALL of my changes being in existing files. I did make the one change to the root layout of the application which the whole application used.

The Fix

I stared at the line for about two minutes in complete shock.  Could me have changing this single meta tag have caused this huge inconvenience to the user base?  In the end, I changed the line back and tested the logging.  It worked and all was well again. The users could log the metric they needed to, and after speaking with the lead developer I realized that the lack of rounded borders in that application was known and expected.

The Lesson

The lesson to me now seems pretty obvious: the scope of feature should be the only place code changes occur.  What I mean by that is, say you are working on feature A and it involves files A, B, and C and while you are implementing your feature you run into a problem with a value being set in a variable in file D.  Your first inclination may be to change the value being set so your feature works.  Well I am here to tell you, you SHOULD NOT change the value in file D.  Instead you should look at how you designed your feature or bug fix and make it work with the value set in file D.  This might mean a quick redesign of a function or even starting implementation from scratch.  However the alternative is to risk breaking user space (which is a no no) and then having a fire to extinguish.

Post Mortem

After all of this I did a little introspection on how and why this happened.  After much thought, I came to the conclusion that it was because of one reason.  This reason was because I was too eager to prove myself and never once took a step back to ask, is this change outside of the feature I am working on?  Now, a little more seasoned from failure, I make sure before I contemplate making a change to a file that is out of scope of the feature to seriously consider all ramifications of the change.  Unsurprisingly, 10 out of 10 times I find a way to redesign my code to work without making those changes.