Come sit by the fire, boys and girls, and I’ll tell you a story about how one developer changed an entire organization.
The developer (obviously, from either gender, but I’ll pick mine) is interested in learning more about software. He feels some pain in the way he develops today. It can’t be that they get to a death march every time.
So he begins reading. Publications, blogs, newsletters. Maybe goes to a user group session. And then he stumbles on the subject of unit tests. He hears it’s good. Doing a little digging, he finds it makes sense to him. Another silver bullet? We’ve tried so many,
So our guy digs a little more. In his off-hours, he sets up a test project and runs it. His mind starts to wonder if this is applicable to “real applications”, like he builds at work.
He talks to his manager to allocate some time for this, within the current project. He gets a few hours to see where this could fit, and to show what the value he’ll get once unit testing is introduced to the project.
After applying the same techniques he read about, he understands it’s not so simple. He can’t just write tests on the current code. All those dependencies. But our guy is lucky, he discovers Isolator. And he lives happily ever after.
Until next Monday. His time is up. “How much is this going to cost us?” asks the manager. “So and so”, he says. “But we’ll save so much at the end!”. “We can’t risk our project right now”, says the manager diplomatically. “We’ll do this after the next release”. Ok, sighs our hero.
And after the release- surprise, surprise- there’s no time to introduce unit tests. It’s time for drastic measures. “I know I’m right. I’ll do this on my components. No one will know”. And it works, but something is up. Integrations go more smoothly. Less bugs returning from QA. “You’ve gone guerilla on me again?” asks the manager. “How can we do this with the entire team?”.
I’ll stop with the fairy tale here. Too bad, as it was going well. Obviously, it doesn’t work this well most of the time. But the question remains: How do we transition from a one man operation into full team and organization implementation?
The answer is simple. Good management and leadership. As a manager, you need to make sure your decision about implementing unit tests is really implemented. That means training on unit testing and tools. Tracking the number of tests, and giving adjusting feedback to developers who revert to the old ways, Track the number of bugs, length of integrations, anything that will prove or disprove the process is implemented. There are enough tools today that give the manager metrics of how the process is going.
Unit testing is a tool, a process. In order to see the results across the organization, we need managers to make sure the process gets implemented. That takes leadership and good ol’ fashion management.
If not, our developer will no doubt remain isolated.
