“It’s easy to make a mistake and have no idea that you’ve broken the software. A second set of eyes definitely helps. Lets face it, working in legacy code is surgery, and doctors never operate alone.”

“Working Effectively With Legacy Code” Feathers pp 317

I’ve being doing TDD for a year or so and the part I have struggled with the most is testing private methods. Should you test them at all? If so, how do you test them?

Michael Feathers’ book “Working Effectively with Legacy Code” has this to say about it:

“This question comes up over and over again from people new to unit testing: “How do I test private methods?”. Many people spend a lot of time trying to figure out how to get around this problem, but […] the real answer is that if you have the urge to test a private method, the method shouldn’t be private; if making the method public bothers you, chances are, it is because it is part of a separate responsibility: it should be on another class.”

I was looking for people’s experience on managing change when trying to improve software development processes and I came across James Shore’s Change Diary he wrote about trying to persuade a company to adopt agile methodologies. It’s full of useful advice, particularly about how you deal with your colleagues and frustrations.

At my company we’ve been going through a lot of change. I’ve only been there a year and it’s already moved beyond recognition. When I started there were a couple of projects, with the support of some of the management, trying to break away from the traditional approach to software development. There was a lot of excitement about Scrum, Agile and XP, enthusiasm abounded and slowly a movement emerged . As it caught on it became more and more apparent that the big problems lay outside of our control. It was all well and good having “sprints”, doing “pair programming” and so on, but as long as we were being tied to unrealistic fixed deadlines and budgets, projects were being to set up to fail from their inception and no amount of refactoring or retrospectives was going to do anything about it.

The movement became militant. We felt that our concerns were not being addressed and started to blame other people for our problems. We came up with a manifesto of how we wanted to build software. The plan was to send it out to all the developers, get them to sign it and present it to the management. Thankfully more considerate members of our community persuaded us all this wasn’t a good idea and the conversation turned about face. How can we engage the people we need to get involved in the discussions we were always having? The most important thing was that all the people involved in the process of building software are able to talk frankly and honestly. We realised it was our fault that we weren’t engaging with the people that mattered. We’ve organised a Goldfish Bowl discussion with the people we have been blaming for all our problems and the mood of the community has changed significantly. The militancy has gone.

It’s easy to see where this could have gone if we’d published our manifesto. OK, I’ll be honest, it was my idea, but everyone really liked it and we were all frustrated with how things were going. It was a worthwhile exercise and we all got something from it, but it took no account of the considerations of half the people we worked with so was therefore irrelevant.

Enthusiasm is great, but be careful with it. I think we were very lucky we saw reason in time.

Look for the signs, don’t get militant.