Re: Winning people over to better development practises

[eyepopslikeamosquito]

in reply to Winning people over to better development practises

When I gave a lunchtime talk evangelizing TDD (Test Driven Development), I summarised the benefits as follows:

• Improved interfaces and design. Writing a test first forces you to focus on interface. Hard to test code is often hard to use. Simpler interfaces are easier to test. Functions that are encapsulated and easy to test are easy to reuse. Components that are easy to mock are usually more flexible/extensible. Testing components in isolation ensures they can be understood in isolation and promotes low coupling/high cohesion.
• Easier Maintenance. Regression tests are a safety net when making bug fixes. No tested component can break accidentally. No fixed bugs can recur. Essential when refactoring.
• Improved Technical Documentation. Well-written tests are a precise, up-to-date form of technical documentation.
• Debugging. Spend less time in crack-pipe debugging sessions.
• Automation. Easy to test code is easy to script.
• Improved Reliability and Security. How does the code handle bad input?
• Easier to verify the component with memory checking and other tools (e.g. valgrind).
• Improved Estimation. You've finished when all your tests pass. Your true rate of progress is more visible to others.
• Improved Bug Reports. When a bug comes in, write a new test for it and refer to the test from the bug report.
• Reduce time spent in System Testing.
• Improved test coverage. If tests aren't written early, they tend never to get written. Without the discipline of TDD, developers tend to move on to the next task before completing the tests for the current one.
• Psychological. Instant and positive feedback; especially important during long development projects.

The talk was well-received and did change both development practices and management awareness. I also illustrated each point with specific examples from our workplace (e.g. a developer refactoring without a test suite causing a rush of new bug reports from customers).

Updated 19-mar-2006: Improved wording. Also note that many of the ideas for these bullet points were derived from chromatic and Schwern's excellent Test::Tutorial talk. See also Unit testing -- module, book, and website suggestions wanted.

[simon.proctor]

Thanks, that's a good list to start with.

I wondered, did you find it difficult to handle some people in winning them over to this? How did that change over time?

[eyepopslikeamosquito]

I wondered, did you find it difficult to handle some people in winning them over to this?

For the people in my team, I had no difficulties whatsoever because I could sit with them and show them how to do it (as adrianh notes below: "show not tell").

For people in other teams, it depended on their interest and aptitude: some really surprised me by writing excellent unit tests without any prodding at all; others didn't seem to get it; others complained that they didn't have the time. Nobody said it was a stupid idea, the most common reason for not doing it was "I have a hard deadline and I just don't have the time right now, maybe I'll try it on my next project".

How did that change over time?

It's been over a year now, and TDD is growing slowly but steadily as the early adopters spread the word and show others how to do it. There are a certain percentage of programmers (maybe more than half) that don't read or study anything outside of work; the only way to reach them is to sit with them and show them how to do it.