Everyone is writing unit tests, everyone cares about their tech debt, everyone performs refactoring… Sure! Enter the nearest dev team room and ask them several questions:
- Do you do TDD?
- Do you write unit tests?
- Do you perform refactoring?
And you’ll hear the same I usually do – “No”. And when you ask “Why?” the answer will be “We have no time!”.
I am a cruel PM, one of those guys who keep saying to the teams: “We have no place for that in the budget!”. But it scares even me. So, PMs, stop blaming the teams, it’s your job to protect them and forget about “We have no time!”.
Technical debt that kills your project
It always starts in a very optimistic way: we have a long backlog – clear goals to achieve, we have a whole budget, we have our deadline far away. And that is time to get to coding. Perfect! Developers start developing, analytics – analyzing, QAs – testing. And then we come to the balancing of the backlog – the business people are pushing hard to move forward with new functionality ASAP, users want to see more features, developers want try “that nice lib”. All of these things start invisibly, but confidently create a huge roll of the tech debt.
Developers have two main options to implement a feature – to make it fast and messily, which will make the future changes rather hard to implement or make it in a clear and smart way, which takes longer to implement, but makes changes easier in the future. The both options seem to solve the problem and deliver the same business value, which is the most important thing to the business. The first one seems even cheaper at first glance. But let’s look at the dark side:
As you see, there are “visible” and “invisible” parts of what we produce in the project. Technical debt is a term to describe the cumulative consequences of corners being cut throughout the development process. The basic idea is that a development team, over time, cuts corners due to lack of skill, laziness or pressure, which then manifests itself as a large backlog of technical inefficiencies that needs “paying off” in the future.
But all too often the accumulation of technical debt in favor of short-term success seems to be a terrible mistake. Like all debt, technical debt compounds with time.
As a result you are getting the big amount of code created, but the code base is so convoluted and difficult to understand that few new recruits are willing to work on it. Adding new features takes longer and longer as time passes. You have a lot of bugs which are hard to fix. Some parts of the codes are not clear and no one knows how they work. The battle seems to be lost.
I am not talking cowboy code is bad! It is very valuable strategy in the beginning – implement something fast in the easiest way, evaluate your ideas with users, change features, find your way. And then get to the good code through the evolutionary refactoring.
Your project is like a rocket – you are moving so fast, that you have no time for unit tests. You are not paying back your technical debt, because you are sure, you are not producing any. Your guys are so smart, how they can do wrong? 🙂
Unfortunately, manual testing strategies simply don’t scale well. The code base your are creating grows faster than your development team. Eventually you will not have the resources to continue to test manually without eating into development time, ultimately diminishing the amount of work that you can get done in a development cycle.
Think, I should write a separate article about the benefits of the tests and what you can get to them. For now I just say that you have no enough time(budget) to ignore them. Yes, you should use the techniques wisely 🙂
How to understand, that we are in a trouble
Here are some signs of the coming BIG PROBLEMS:
- You have no idea about tech debt, unit tests, refactoring or you don’t produce any tech debt.
- The bugs don’t stop. Your features keep been reopened by the QAs, customers keep reporting issues. Each fix produces 10 new bugs. That is a sign that your code base has become bloated with too many short cuts, old engineering assumptions are no longer appropriate, or things have just gotten messy over time.
- Your code has too many // @todo: Not good solution, come back and fix
- You have no tests. I am working in mobile and expect mobile teams say “our applications do not require unit tests”. But let’s start from the server side. Do you have tests there? Do you have any business logic in the client app? Keep asking 🙂
- Developers don’t perform refactoring. Business say “We have no time!” on all their “Please!”. And the worst situation: you have to cope with spaghetti pile and guess to hire more developers. More ugly code being piled on the old ugly code, and engineers leaving after a short time only for you to hire new engineers…
- Velocity is doing down
I am not the person who knows the ideal way, cause I have survived through the difficult times with teams and I worked with great developers, who threatened me to eat my brains if I won’t listen to them. So don’t think that I am so smart to avoid all these issues ^_^
What PM can do
Some practical tips for PMs, who are working in outsource companies:
- Do not ask your client’s if they need unit tests. If they need refactoring. You just do that – they have to adopt your development process, because you are the professional in this field and they hire you to solve their problems, not create new. I have heard from a lot of my colleagues, that client’s are against all these things and teams can do nothing with that. But don’t give them any alternatives. You just work this way. And no argues. Of course – talk to them, explain why, explain what they will get from that. But still – no alternatives.
- Set the process: it can be story analysis-tests-development-integration tests-manual qa or other. Just set it, no mess or “will do it later’ aloud.
- Make your tech dept visible. Create a separate line on your scrum board for that. Any developer should be able to post a new task there, when he creates or sees a tech debt. When you see it – you realize, that it exists.
- Share the code. There should not be the owners of some parts of the code in the teams.
- Perform code reviews. One of my teams came up with the idea to review the code of each developer before push by the other developer/developers from the team. It is not long. But all the team was aware about the new features, they gave so valuable comments!
As the conclusion I should say that you don’t need to find any additional time – you already have it. It is not longer you will be surprised, that your average speed remains the same and keeps to be stable. Stealing the time of the future just leads to the collapse in the end.
And one photo of my guys, as they are amazing: