Change code? Be afraid. Be very afraid....

In my role as a software developer I have come across many strange attitudes to coding, but none so strange as the fear of changing code.

A good example - I was working with a team trying to use XP techniques. I was hired as a XP developer to strengthen the team and get them over a busy patch - not as coach, but simply as someone who had developed Java code in an extreme agile environment. No problem there.

The product we were working on required new functionality added to it. Since the current software structure did not easily accommodate the new stuff I mentioned in the stand-up that I would be restructuring the internals to make it fit more elegantly. This kind of refactoring is normal practice in any agile team, and is necessary to evolve the design with emerging requirements, keeping it coherent and stopping it from descending into a meaningless Ball Of Mud antipattern. I thought nothing of it. But one of the senior engineers threw his hands up in horror at the thought. "You can't do that! You might break something!".

The thinking went something like this:

"Currently the code works. The area of code being touched took a long time to get right and there is a load of undocumented features we discovered along the way but we cannot remember exactly what these were. Therefore to change it is likely to break the end product. Also we don't have tests that check what the code should do so your changes might break the software without us even knowing it is broken. So any changes must not affect existing code. But we cannot test it so we can't tell if it does affect it...."

R-i-g-h-t.....so let's get this straight. The code "does something". We don't know what that something is (we don't have tests) but we suspect that this unknown something will change if anyone touches any existing code in a certain area. Therefore we cannot change the code, only add to it even though the new functionality should really require a structural change to maintain architectural integrity. But we can't even tell if the external changes have affected anything because we don't actually know what this thing does!

So the burning question is "How can anyone change any code anywhere if we (1) don't want any existing functionality to change and (2) we can have no certainty that a change has not affected existing functionality"

Now I should add at this stage that the guy in question is fundamentally a good, competent, normally coherent engineer (and is also a representation of several real-life engineers who I have come across in this situation!). Which raises the question why good, competent engineers can get themselves into this logical black hole and fear making changes in code.

There are several key issues here:

1. No tests. So we cannot reproduce what the product should do.
2. Lost information. The Team has not been sharing information effectively so nobody really understands why things are structured the way they are.
   
3. Undocumented features discovered in a third party library.
4. Unclear code. The code in question is satisfying several sets of responsibilities resulting in a monster 1500 line class.

The issues do highlight deeper issues with the way the specific team is working. They are indicative of several common behavioural antipatterns that often cause agile processes to fail. I intend to try and pin down specifics in later blog entries.