Hariri comments about his experience in two developers shows, where he gave talks. He wrote:
As usual, to set the context, I asked a series of questions regarding unit tests:
“How many of you know what a Unit Test is” – 80% put up their hand.
“How many of you do Unit Testing?” – 10% put up their hand.
“How many of you think Unit Testing is valuable?” – 80% put up their hand
The first show was for PHP developers. I guess that PHP developers used to work a bit different than other developers, at least in my times of PHP dev. Maybe, today, they have more tools to do the job. But the second show Hariri attended, was in front of 200 persons interested in software architecture.
Recently, in an internal talk in a software company, @MartinSalias asked similar questions, and the results were like Hariri’s ones. I didn’t take notes about the results, but in one of my talks, the results had the same bias: lot of people likes best practices, XP disciplines, etc… few ones were implemented them.
So, where is the problem? Hariri writes:
“A is good. I like A. I should do A. But I won’t do A”.
People identify themselves with the issues we talk about. They see the value writing automated tests and complying with design principles adds. They get excited, yet they don’t do it. Why?
I usually ask this question too, and the typical responses are:
1. Tight Schedules.
2. Decrease in Productivity. Drag and Drop is more productive
3. Customers want deliverables. Tests are not deliverables
and my all time favorite
4. “I’m paid to write code, not tests”.
Well, there are many reasons, each software developer and team have reasons to not apply TDD, automated testing, code reviews, pair programming, etc…
Let take one topic: TDD. Why people are not using TDD more in daily work? My guess:
- They know what is TDD, but they never practice it, they have many doubts
- If they work in a team, not all members knows about TDD, and the TDD-aware person didn’t practice or master TDD.
What they need? I think they need three points:
- Know the rationale behind TDD (they grasp this point in talks, articles, conference, books…)
- Practice TDD
- Have a mentor to ask questions, resolve doubts
I resolved the second point working in my personal projects. And the third one, asking coworkers, using web forums, reading examples, more books, reviewing open source code project, and I still working in the above three points. But I guess not all software developer has the available time and will to improve their skills in the same way. I push for a “self-learn” software developer, but the reality is, not everyone has the time to take that way. And it is a way with risks: you are on your own, and if you don’t have a dedicated mentor, it’s difficult to learn all the topics you need to cover in order to be proficient in TDD or in another best practice.
I’m working with Hogwarts Project team, to resolve such points: give people the support to learn TDD, IoC, SOLID principles, and more. Not only example, but rationale. Not only theory, but practice. Not only practice, but evaluation and post-support. In our case, the end customer bought the best practices idea: we have not needed to convince management of the advantages of best practices. We are in the early stage of the project: first deliverables are beta ones, and only internally distributed. But I hope that when the project gains more moment, more material and gained experience will be published and shared with the community.