Time tracking has a bad reputation. Nobody likes to account for how exactly she is spending her working time. Developers want to code instead of struggling with administrative tasks like filling out their time sheet. In my opinion, this attitude is wrong. Granted, we build software for time tracking so the topic is naturally near to my heart. Independently, I really believe that a good time tracking practice can solve a big problem for many developers: It can help getting rid of hated technical debts.
Features vs. Refactoring
Beside my work on time cockpit, I often help teams in software companies to build better products. Many of these projects start with a code or architecture review phase. Stakeholders hire me to take a look at the current state of a project and give feedback.
Side note: A few weeks ago, I gave a presentation at a developer conference about C# code reviews. In case you are interested, here is the slide deck:
During review projects, I often discuss reasons for technical debts with members of development teams. In detail, the arguments vary from company to company but there is a common denominator: Developers complain because their managers don’t understand that software needs continuous modernization. They describe that they are forced to add new feature day by day but they are not given time to refactor or implement necessary architecture changes. They say that managers wouldn’t understand the problem, after all they are no developers.
Business Cases Instead of Technical Blah
Developers are often right with this diagnose. Managers whose job it is to look after budgets, sales, HR, etc. don’t understand what we are talking about when we developers speak about how important it would be to e.g. add professional dependency injection to a software product that is not broken according to the mangers' point of view. That’s no surprise, is it?
As developers, we have to learn to argument in business terms. Imagine you want to refactor a certain module in your software. Don’t present that idea to your managers prematurely. First, ask yourself questions like the follows:
- Can I present proof that the current situation is really a problem? Ideally you have measurable evidences.
- Am I able to describe the problem and the planned refactoring so that somebody without a PhD in computer science understands my point? Prepare a presentation including visuals and test it with people who are not as deep into technology as you are.
- Do I have a solid estimation concerning the effort necessary to do the refactoring? Am I convinced that my estimation will survive critical questioning of my managers?
- Do I have plausible arguments for what will be better after the refactoring? Ideally your arguments are based on comprehensible numbers and estimations.
- Can I link my suggestions to my company’s strategic plans (e.g. refactoring enhances scalability which is necessary for my company’s aggressive growth strategy)?
If thinking in such business terms is new for you, ask for help. Maybe you have a Scrum Master who has experience in creating and presenting business cases for technologically complex matters. You could even ask the manger you want to present your pitch to for help. Tell her that she should guide you through the evaluation process for your idea so that you know how to prepare in future cases.
Facts, not Gut Feelings
How does that relate to time tracking, you ask? Business cases are a lot about facts. A proposal for a technical change that is solely based on attributes like “cleaner”, “easier to maintain”, “modern”, “elegant”, etc. is weak. It becomes stronger by adding numbers. Examples:
- In the last three months, we spend x hours on support cases directly related to this weakness of our software. We think this effort could have been reduced by 75% by doing the refactoring we propose.
- It took an experienced developer who is new in our team three weeks until she could make first productive changes because of the unnecessary complexity of this piece of code. We could bring down that ramp-up time to a few days with our refactoring project.
- Our test team had to spend x weeks retesting the entire module because we have no appropriate automated tests for it.
- In the last month, support spent x hours dealing with y customer complaints about the performance of this function. Our telemetry data shows that performance is in fact not satisfying. We think we can fix this by...
- A quick-and-dirty prototype indicates that we can bring down average CPU load on our cloud servers by 25% if we do the proposed code changes. With that, we could turn off x servers and save y Euros each month.
For the majority of all software companies, personnel costs are a major expense factor.
Therefore, knowing how the development team has been spending their time is crucial when it comes to writing business cases. The time tracking you have to do for payroll is not sufficient. You have to know how much time you spend for e.g. customer support, internal support (e.g. for technical sales), administrative tasks, prototyping, testing, documentation, developing certain new features, etc.
It does not stop with time tracking:
- Make sure you have a professional support ticket management system.
- Make sure you estimate efforts for all your tasks. Compare effective effort with estimations and do a root cause analysis if you exceed the time budget substantially.
- Get an integrated ALM (Application Lifecycle Management) tool chain.
- Get a professional BI tool enabling you to dive into the numbers.
Your development processes need telemetry just like your servers or software components. This telemetry data will be the basis for convincing business cases.
Build Trust by Presenting Results
Finally, don’t forget to present results once you finished your modernization projects. Did your prediction become true? Did you even exceed the expectations? Again, it is important to have the numbers that prove that your concept was right.
Regularly presenting measurable results builds trust. If you do that, it will become easier to get resources for technical improvements you propose.
comments powered by