A common concern for developers who want to implement better software development disciplines in their teams is how to convince management to go along with these great ideas. How do we convince management to let us take time to refactor the code? Or practice TDD? Or adopt agile disciplines?
The answer is very simple: you can’t.
Look at this from your manager’s perspective: someone comes in and says, “We finally finished coding up Feature X. Now we need a few days to clean up the code.”
“Does the function work?”
“Yes, but it’s going to be harder to make changes in the future unless we refactor it.”
“Sounds to me like you should have written it better in the first place. That’s not my problem. We need to get these other bugs and features handled. As far as I’m concerned, Feature X is done.”
“But it will save more money in the long run to clean it up now.”
“In the long run, we’re all dead. Get to work on those new features!”
As far as the business is concerned, the development effort is a cost of doing business. We can always find money to do more work.
The one thing that business management can’t stand is risk. They want to keep the train moving smoothly and predictably down the track.
Save me money, meh. Eliminate risk? I’m all ears!
So what are some ways you can eliminate risk for your manager?
• You can make the application less bug-prone so that users will use it and purchase updates, and you get fewer support calls and better user reviews.
• You can make the application more secure so the company won’t be in the news due to catastrophic data loss.
• You can make the application easier to maintain and extend so new features can be added more quickly and the user base will grow.
• Think about your work situation. There are probably dozens of things that could help!
Notice that none of these ideas mentions TDD or refactoring or changing work processes. But better practices will be essential to implementing any of these ideas.
Now you have to show how you can actually deliver on these promises.
This is where the real work starts. In order to prove that you can deliver, you have to talk in terms your manager understands: numbers. Let’s say you want management to support your using TDD for development. What numbers will be most interesting to management?
• Development time for a feature
• Acceptance testing time for the feature
• Number of bugs reported for the feature
So you’ll need to prove that some or all of these numbers can be improved by using TDD. You’ll also need to be able to answer any questions about TDD that your manager may have. So you’ll have had to read a book or two on the subject. Maybe you take a course, too. You will at least have tried it at home a few times on some personal projects.
Next you’ll need to put together a proposal that appeals to your manager’s interests. You can show that in your personal home projects you’ve seen certain results. Or you can refer to the numbers in Steve McConnell’s “Code Complete” from the projects that he has measured. Or get other numbers from a source that you and your manager can trust.
Then you can ask to try it out on a few features – a very small test with very little risk. Just one or two people using it for a handful of features. You can show how you have been keeping numbers so far, and you’ll provide equivalent measurements for the results of the new features.
When you are able to show success in a small project, you can then be trusted to expand a little. Take on the responsibility for training your co-workers. Host a brown-bag lunch to teach them how this works. Get the team’s buy-in before trying to get management on board. Once you have grass-roots support, and you can prove success in smaller things, you are ready to expand. Take baby steps. Don’t be in a hurry. Slow and steady wins the race.
If you follow this approach, you are much more likely to succeed. Is it a lot more work? Of course! But if you really want to effect change in your team, this is the best way to do it! Go out and change the world – one feature at a time!