When Discipline Breaks Down

What do I mean by discipline...  That was rhetorical so if you answered in your head, smack yourself on the hand and stand in the corner.

In the software world, discipline focuses on the patterns we follow in response to events or the breakdown thereof.  I try repeatedly and often unsuccessfully to drive home the idea that software development discipline is what allows us to efficiently and effectively add an increment of product.

Example.  The Wrong Value

My QA folks inform me that they expect a certain value to persist and it is always persisting as Zero.  I have two options.  Option 1 is to run the application and attach a debugger.  Regardless of the number of tiers in the system, this takes considerable time. Additionally, I have to have just the right input information to test with and it has to fulfill the requirements of the ENTIRE interface, not just the portion I care about.

As an alternative, I could select a tier and write a unit test pinpointing the portion of code that is potentially exhibiting the behavior. If the test passes, I can move on to the next tier.  If the test fails, I can then change the code to get the test to pass then commit.  Problem solved.

Today, we had a scenario where our public facing schema mapped to our canonical schema (our internal representation of our "thing") and it was reported that a certain value was not being persisted.  Since we had recently created the public schema, my partner insisted that the mapping between the two was wrong.  I immediately wrote a test that definitively proved the mapping was good.  It allowed us to pinpoint the area of the application where the behavior broke down.

McConnell and Beck both get kudos for instilling a personal discipline when I develop.  Immediate Feedback Loop.  In this case, writing a unit test to expose the problem is an example of an immediate feedback loop.  The test, when written where the problem does not occur, provides a regression test that can then be played back by the continuous integration server as a check.  The test that failed and then succeeded (when I fixed the problem area) stands as another regression check.



One of my biggest frustrations as an engineer is explaining to non-technical folks that I have to spend time writing tests to test my own code.  The ones that get it get my immediate respect.  They understand how much more efficient it is for me to write a test (that takes about 5 minutes to write) than to defer the immediate feedback loop to a feedback loop that incorporates multiple people and potentially some form of bug tracking tool.  They also understand that a bug found by me has less cost associated with it than a bug found during a QA test. 

My next challenge is to instill this discipline in my team.  I have repeatedly demonstrated to them the value of writing a test.  I'll likely do this again over the next 3-5 sprints.  In this case, repetition is probably the best teacher.

I have said this many times but recently it has become my greatest challenge.  It is far easier to build great software than it is to build great people.  Great People however, are the best long-term investment any company can set a budget for.