I’ve been giving talks for quite a while now on best practices, unit testing and other things that aim to make our lives as developers easier. Having myself suffered and lived in a World where nothing was put through automated testing, QA was usually delegated to our customers, and having faced the problems that I and other members of my team encountered when something went wrong on deployment, I’ve truly come to appreciate the value of how certain practices improve my code (and my life). In fact it makes my work more enjoyable. It’s fun. I’ve been on both sides of the fence and I’m on the greener side now. It’s like when you quit smoking (I actually did that too, It’s been 6 years and I’ve not looked back. You can too!).
We loved the songs
I’m now on those greener pastures, running and skipping, with the wind blowing through my hair, freezing my bold head, and singing how unit tests are great and following certain design principles are wonderful. People hear my sing away and they really enjoy it. They love my entire repertoire. They enjoy the dark ballads where I pour my heart out about the pain I suffered during those early days, because they identify themselves with those problems. They enjoy the nice energetic melodies where I talk about how to ease the pain. They see it can ease their pain too. The show ends on a high!
Then it’s over!
This is great and all, but it’s not for me
I was at two of these shows last week. The first one was 4Developers and one of my talks was a short-talk on unit testing with JavaScript. For some reason they had put me on the PHP track, so I was standing in front of an audience of PHP developers, something I know absolutely nothing about. But it was OK. I was there to talk about JavaScript and Unit Testing.
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
(rough figures obviously)
Two days before that, I was giving a talk at the Architecture Forum in Madrid, on design principles. I asked a similar question. I got worse results. Primarily because at 4Developers there were roughly 30 people in the room. At the Architecture Forum, there were around 200.
WTF?!
It sounds absurd doesn’t it? Think about it.
“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”.
See, developers live in the real world with tight schedules. They have to deliver to the customer. Their boss and customers are waiting. They don’t have time to do all this theoretical nonsense. In an ideal situation, with all the time to waste, of course they would do all we talk about. But that’s not the reality. They have a product to deliver and this kills their productivity.
What we have here, is a failure to communicate…
For those in the choir on those green pastures, it is crazy. We realize that there is in fact no decrease in productivity. We understand that by taking time to write maintainable code we are making our lives easier in the long run. We appreciate the fact that unit tests allow us to find a higher number of bugs before deployment. We realize that a unit test is not only about making sure our code works now, but that it will also work in the future, and if something breaks, we’ll know about it before we ship it to the customer. We won’t jeopardize the customer’s productivity by stopping his activities because of our failures. Last but not least we also know that unit tests can in fact define our specifications.
Do we fail to communicate properly? Is the Grand Finale missing?
Don’t look at me…
As I mentioned initially, I also didn’t unit test or write maintainable code. So what made me change? Was it a blog post or conference?
Well, I had suffered the issues so I knew I needed to find a better way to do things, and gradually with a lot of time and effort I started to improve how I did things. But it wasn’t an overnight process. And it isn’t over. I’m still at it.
The point however is that I also live in the real world. I’ve had my fair share of bosses and PM’s that thought writing a CRM was dropping a component on a form and hooking up some properties. I’ve had tight schedules and deadlines to meet, but I didn’t throw in the towel with some excuse.
See, all those reasons above are excuses. It’s up to you, as an individual, as a member of a team, to improve what you do. You job involves talking to customers, to project managers, to your boss, to fellow team members and making them understand. Your job doesn’t start and end with writing code. You’ve read that blog post or gone to that talk and seen the value it has to you as a developer. You need to communicate that value to those you deal with.
Your boss doesn’t pay you to write a unit test, of course he doesn’t. But I’m betting he didn’t pay you to write two IF statements instead of one Switch statement either. He doesn’t pay you to comply with the Single Responsibility Principle or care whether you broke the Law of Demeter.
See, what he and your customers do care about is how what you’re doing adds value for them, and it’s your job to not only deliver, but make sure they see that.