Blog

I didn’t make a code change.  I just updated the CSS…  Sound familiar to anyone?  Or how about, By the way, I moved some stuff around in the JSP.  But don’t worry, I didn’t change any code.”  I am sure I am not the only one who has heard this before, usually right before an iteration meeting or a client demo.  And when you hear that, if you are like me, you go into that meeting with a sense of dread - knowing that this “non-code” change is going to awaken the demo gods, and something is going to unexpectedly fail in mid demonstration. 

We have processes in place to prevent untested source code from making it into a demo environment.  So why don’t we do the same for CSS?  Or JavaScript?  Or JSP pages, and so on?  The root cause is the lackadaisical attitude toward the view layer or client executed scripts.  We don’t consider it to be “code.”  I am trying to change that mind set.  My philosophy is If It’s In The Code Base, Then It IS Code…

That philosophy was derived from a real world experience, which I encountered in my early days as a software engineer.  As part of an Agile development team, we had periodic iteration meetings, in this case every week.  During these iteration meetings, we would demonstrated each Task completed in an environment that was separate from the local development environments.  At the end of business the day before an iteration meeting, the most current build was pushed out into the demonstration environment.  While the developers could continue to work, the only tasks considered complete were the ones that were in the code base at the time that the build was pushed.  If it didn’t make it into the source repository, then it wasn’t completed for the current iteration.

It so happens in this instance that a certain web page was not formatted as expected.  The developer noticed this, and quickly made the needed change the morning of the iteration meeting.  And because no “code” was changed, they were able to get it snuck into the demonstration build.  Unfortunately, while the change did indeed correct the formatting error, it also broke several other aspects of the application.  In this case it duplicated a form element that was being bound by Spring into a Form Backing Object.  The property editor was not able to convert the array of values that it was now getting into a single value that the FBO required, and so the functionality was broken.  And it broke right in the middle of the client demonstration…

As the Lead Developer on this project, it was my responsibility to prevent stuff like this.  I take full blame for letting the change in.  But I was sucked into the By the way, I moved some stuff around in the JSP.  But don’t worry, I didn’t change any code.” trap.  Now I know better.  These days when I hear someone tell me that they didn’t change code (just some CSS), or try and sneak a “cosmetic only” change into a build or release, I simply remind them that CSS (or JSPs, or HTML, or JavaScript, etc) is code, and needs to be treated as such.

If It’s In The Code Base, Then It IS Code…  Keeping this mindset can prevent a lot of unexpected application failures during demonstration (or even worse, the product release).  Don’t fall into the trap of thinking that it isn’t.