2024 Public Training Schedule
November 18 – 21, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
December 9 – 12, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- June 27, 2018
- Specify Behaviors with Tests
In my last blog post, I discussed different ways of introducing test-driven development to teams. The bottom line is to give developers an experience of benefiting from doing TDD. Once they see how their tests catch bugs that otherwise would have perhaps escaped and had to be fixed later, and how TDD helps them keep focused on building software that fulfills acceptance criteria, and gives them the opportunity to refactor and clean up their code, then developers begin to see the benefit for themselves and want to continue to do it.
But convincing some managers, especially those who really don’t understand what software development is all about, can be a challenge. I believe that constructing software is fundamentally different than constructing physical things. Software is unique and very often the techniques we use to manage other kinds of projects don’t work for managing software projects. It takes a while to gain experience as a manager in the software industry.
Quality is important in virtually every field but quality in software and software construction is critically important. But we have to understand what quality means in the context of software. Reliability, security, and performance are the effects or result of deeper causes that come from good developer principles and practices at work.
Volumes have been written on programming and how to do it well. If I had to sum it up in one word that word would be testability. When we make software testable it is also of high quality and so the cost of maintaining and extending this kind of software is lower than untestable code.
When managers ask me what’s the most important thing to hold their developers to I always say testability. Have your developers write testable code because that code will be more cost-effective to maintain and extend. Given that industry spends five times more on software after it’s released than it initially cost to create, it’s clear that maintenance is very important. Since testable software costs less to maintain we want to encourage developers to write testable software.
The best way I found to encourage developers to write testable software is to have them do test-first development. With this one practice, we encourage code to be not only of high quality but also independently verifiable. If we build good tests then we will also be building a reliable continuous integration system that will allow us to automate regression.
There is value in catching bugs early. There is value in having a reliable continuous integration server. There is value in being able to confidently make last-minute changes to code. These are the valuable things that we get from doing test-driven development and when managers see those benefits in action they often get on board with having their teams do test-driven development. But just like developers, managers have to see the value of these practices for themselves.
Previous Post: « Introducing TDD to Teams
Next Post: Independence »