Could we write unit tests? Do we get some time to write unit tests? Is there a budget for writing unit tests? How could I convince my manager that unit tests are important?
I am totally sure that almost every developer knows this questions, do you? What was the outcome? Could you persuade your manager that it is important to write unit tests? Sandro Mancuso, Software Craftsman and founder of the London Software Craftsmanship Community, gives us some insights in his book, how a Software Craftsman would handle this.
I got the Ok from Sandro to publish the part about that topic. Thanks for that Sandro. And by the way, there is also an interesting part of how you could convince your team to write unit tests. But there are many many other interesting and inspiring chapters.
How do I convince my manager?
The simple answer is you don`t. It`s easier to ask for forgiveness than to get permission. Just go there and do it. When it comes to technical practices, why would your manager care anyway? Manager want projects delivered on time, on budget, and with no bugs, and they want to make stakeholders and clients happy. Who cares if we use TDD, if we pair, or have continuous integration? Besides us, no one.
If we asked our managers, “Does the code need to work? Is it OK if we introduce bugs every time we touch the system?” what would their answer be? “Sure, go ahead and write the worst code you can possibly write. That`s what we hired you for. Screw the users. They can call and complain if they are unhappy.” If your manager says that, make sure you call the nearest hospital or find another job.
We are expected to delivier quality software. We are expected to deliver good solutions. So, when it comes to TDD, pair programming, continuous integration, or any other practice you think can help you to achieve that, just do it. Don`t ask for authorization. Don`t ever put a task card on the board called “unit testing”. A unit test is not a task. You cannot say that a coding task is done if you still have a pending “unit test” task for that code. Don`t split coding tasks into two tasks: one hour to code this service class and another hour to write unit tests. They are not separate tasks. In this case, you just have a single two-hour task to implement a service class that works. Testing, regardless of which type, is part of the coding task and not a separate thing.
Whatever you do, make sure you deliver value to your customers. Be transparent and honest about your progress but, unless they ask, don`t keep highlighting all the minor details about how you are implementing your code – it`s not important. I`m not saying you should lie or hide anything. I´m just saying that telling your manager that you will take a specific amount of time to refactor your code or write unit tests is totally pointless. Who cares? What is important for managers is when you are going to be done, and by done we mean provide code that works according to the business specefication and is in production (or ready for user acceptance testing [UAT]). Tests and refactoring are part of any coding task. The more technical details you expose, the more managers feel they micromanage you.
My recommendation: buy this book, it`s a must have for every professional software developer!
— Julian Kleinhans (@kj187) March 16, 2016