You’ve started doing TDD or unit testing your systemverilog code with SVUnit, your defect rate is down and you’re producing better code. You’re at the point where your experience could benefit the rest of your team but you’re not sure how to get the point across.
What do you do?
This is a question I’m getting more and more now that people have started either doing TDD or unit testing code with SVUnit. Producing better code is exciting stuff and folks think it’s worth spreading the word to the rest of the team.
Here’s what I’ve been suggesting to people…
Don’t Get Frustrated
Surprise! People can be skeptical of new ideas! I certainly am. In fact, I think people should be skeptical of everything. TDD and unit testing are quite different from the norm so expect skepticism at first.
It’ll take a while for people to come around so be persistent and don’t give up when the first answer is “no”. And even if after several months of trying you’ve had no success at all, remember that TDD or unit testing are making you a better engineer. Maybe people will eventually come around, maybe they won’t. Either way, there’s nothing to get frustrated about while you wait because you get to carry on with the good work that you’re doing!
Become an Advocate
As an advocate for TDD or unit testing, you’re there to speak up when the opportunity presents itself (or you create opportunities to speak up!). Simply informing people of the possibilities is important so don’t be afraid to talk about the new techniques you’ve been practicing and tell people about the benefits you’re seeing.
(fwiw… people usually use the word evangelist here but I prefer advocate. Maybe it’s just me, but I always think of evangelists as loud/preachy folks that are in your face and never let up whereas advocates are vocal yet calm, confident and practical in they way they lay out their position. Whatever term you prefer, the point is to speak up and inform!)
Hold an Information Session
If you feel interest growing within your team, doing a lunch-time presentation can be a good way to spread the word to a larger audience and generate larger group discussions. It can also be a good move to get a better understanding of what might be holding people back!
Do a Demo
As a follow-up to the information session (or instead of the info session), consider doing a group demo. TDD and unit testing are Greek to some so words may not get the idea across effectively. Showing people what you’re doing as you describe it will make it much easier for them to connect the dots. Even better would be to have people do an example for themselves during your demo. You can reference the README.txt in the install directory for this. You should be able to have everyone write and run their first unit test fairly easily provided SVUnit and simulator are accessible to all.
Emphasize the Benefits
I’ve always considered the major benefit of TDD or unit testing my code as a decrease in the number of defects I produce. Others have told me that the speed of unit tests is a big selling feature. I think both simulation speed and lower defect rates are points you can emphasize with the rest of your team. The fast/easy/reusable/uniform setup and usage model is something you can emphasize as well, though be sure to show people that instead of just telling them about it. UVM proposes the same so remember there’s quite a range in our collective understanding of what it means to be fast/easy/reusable/uniform!
If you just tell people what you’re doing, it’ll be too easy for them to forget. But if you tell people and then remind them constantly (without being an annoyance!), people will see you’re practicing as you preach… and maybe that’s the nudge they need to give it a try.
For that reason, I think being visible is probably the most important thing you can do long term. Being visible, to me, means you’ve posted your successes, failures and overall experience somewhere people can see them, like a whiteboard outside your cube that people will see as they walk by or (less good) would be a dedicated intranet page. This will be hard at first if you’re not used to putting your work on display or inviting critique. It gets easier though, trust me :).
A few ideas that can help keep people in the loop…
- a list of lessons learned
- defect counts (your defects and the defects you find elsewhere)
- a running total of tests with corresponding runtimes (remember speed is a selling feature)
Find a Protege
I feel safe in guaranteeing that most people will be skeptical of your big new idea and brush it off at first. But I can also guarantee there will be at least one person that sees the light. It may take a while, but he or she will be there and they’ll want in.
That person will need your help. I’m talking real help; sit with this person, work with them, help them write their first few unit tests and be there for them when they need it. Open door policy; 24 hour assistance and all the rest. This is a chance to double the size of your idea. Don’t miss it!
If you have the chance to take a training course from someone who knows what they’re talking about, do it. If training isn’t an option, read a good book on your own time. Do the examples and get to know all the ins and outs of TDD.
(or a great book on introducing change that’s been a big help for me is Fearless Change by Mary Lynn Manns and Linda Rising. In fact, some of the ideas I have here come directly from their book 🙂 )
Ask For Help
Finally, we do have enough people experimenting and practicing TDD and unit testing with SVUnit that there are people out there that can offer pointers based on what they’ve gone through themselves. If you’re stuck, feel free to reach out to me or others via the blog. I sometimes turn questions into blog posts (that’s what motivated this post) as a way of enticing others to weigh in and help out.
Hope this helps!