A few months ago, Florent Pellet invites me for a Brown Bag Lunch for CEGID about BDD. The presentation I did was close of this one from the Lyon Human Talks.
After the presentation, I had this interesting and surprising question: “Well, that was nice, but how much is is to put it in practice?”
My answer was:”It costs nothing but the required energy to understand the method and to use the appropriate tool (SpecFlow in your case).
– Really? This is just a question of choice then?”
Exactly. This is the choice to work better. And this is what we endlessly repeat as software craftsman. Doing TDD, BDD, DDD, having build server and continuous integration, or even continuous deployment, in other words: work with serenity, it is a choice.
Corollary we can assert that work under pressure, be seen as a code monkey without any value to add, working 12h a day without the possibility to be proud of your product, it is also a choice.
And if I do this assertion today, it is because I started working in bad conditions as well, trying to convince myself that I had no other choice. You know TDD looks pretty cool, but it is clearly not possible “in real life”, because, after all, “it is different for us”. We had these impatient and unhappy customers, the short deadlines; we just have “no time for this”. We are doing real work!
And one day (the read of Clean Code acting as an electroshock for me), I understood that if I started to test my code, if I try to work in TDD, no one will come and stop me. Ok I tried to speak about it to my colleagues without success, but does it prevent me to do it on my own work? No. So I started to produce new tested modules. I learn about code legacy management, what’s the best architecture to use to test a Silverlight application. I quickly see the difference: tones of questions arise as I learn.
Of course, I often doubted, I even accept to develop a product for more than 6 months without any tests. (You know, the prototype was produced in a week, how could you imagine you’ll need 6 months to turn it in a professional product…And It was really dependent of a SDK, so it was pretty hard to test…Anyway, we always find some excuses). I still regret it. I quit my job a few months after this product was realesed. I choose that after that, I will only work on project with unit tests at least.
This is one of the main reason I started working as a freelance. I was tired to listen to managers explaining me that customers are not ready to “pay for tests”. And guess what? Now I earn more, I work less, I am more proud of my work, and I learn more in 1 year and 6 months than in the previous 3 years.
But how could you enter in this virtuous circle of continuous improvement? As a developper, I can suggest two starting points:
– Do some technological surveillance via twitter, blogs, conferences, formation, User Group… To know how to test your code
– Then, test your code
From that point, everything will run smoothly. To have good tests, you will learn to write better code. When your code will be better, you will learn to improve your tests.
When both will be in an acceptable level, you will think about a better software factory (build server, continuous integration, continuous deployment…).
Then you will be able to make your team more productive, because you won’t be slow down by little technical details day after day. You will improve yourself by spending more time to learn. In the end, your customer will thank you instead of be feared for each new version of the product.
As the pressure from your customers will go down, you will have more time to improve your code…And so on.
I you do not like your way to work, hack your job, change your method, learn to be better, change of company if this is the only solution!
Don’t panic, just hack your job.