In my do far short career I stumbled across a huge pile bad-written piece of code. So I want to estimate how long and how much it takes to maintain it and how long and how much it takes to just write from the start.
I want to convince my manager (and aid him) towards a direction that we should gradually re-implement pieces of our business logic. For that I need to show something in a matter of money and hours.
Do you have any methodology on how to do that?
Latest comments (4)
I have used sonar to calculate tech debt. On one of our projects we had almost 30 years of debt.
Long story short it's always cheaper mantain it than coding from scratch in short term.
It depends on the size of the project, for a little project refactoring/rebuilding cost is cheap, for a huge project it could cost tones of money.
Also depends on the structure and "shape" the project has at this point.
The natural evolution should be:
Of course a microservice based application is cheaper to mantain (from the development point of view) but the infrastructure cost is relatively more expensive (also one or more server engineer is a must).
There are lots of applications that remain as a hybrid with some monolithic parts, some services and some microservices, with both bus event communication and api gateway, no matter the company. I read about all that from IBM engineers posts and i live it everyday.
I'm creating new apps microservice/service based but still mantaining a big legacy e-commerce; this maintenance tasks are some kinda living in the hell but... The business is not ready to start coding it from scratch. Even when i woke up and know that the day has come, it will not be a "we're starting to code it from scratch now", it will be more like "let's think which parts could we move into a service/microservice architecture and which technologies fits better to reach what business needs now, and what must need in a future", then start coding those parts while, obviously maintaining the legacy code. This process to rewrite all in a new shape could take up to 3 years with a 10 ppl team as least as we need to maintain all other software, solving the business needs and solving issues from current software while coding new one.
My advice is that, if you are a junior developer, forget about involving yourself in a crusade for the good code, last time i told a CTO that we need to start a project to write from scratch a 20+ year old app i almost was fired, even having 6 years of experience. The same CTO that didn't accept a JS + CSS refactor i did to solve issues with the app on not IE browsers and decrease the load time by 3 seconds...
I wasn't fired at this point but i left for a company with better people managing the teams 😅
Be Careful calling out Tech Debt
What worked for us, wasn't convincing managers to take on a full scale refactoring project. Rather, we agreed to create a User Story named "Tech Debt", and added work items to it as we discovered the "bugs". We were able to get this agreement due to the pressure of getting other stories done in compressed schedules, but having to trip over the bad stuff over and over again.
Without a collection of items spelling out tech debt, managers don't see it.
Outcome
Unfortunately for us, each sprint planning session ignored the tech debt items, simply because the business had other higher priority items. After about four months of this, we realized Tech Debt never floated to the top.
How to Approach Tech Debt
Our own solution was:
"Any time we opened the code, we agreed to refactor to make it better, but only for a narrow limited scope ".
"We would make sure the new and old code was fully tested (using automation)". This was the key to success. We all agreed that even one line of code change is potentially dangerous.
Become the Best Tester in your Department
My advice would be to become one of the best test creators in your organization. Let the tests speak for themselves by creating bugs you find, so it will show up on the daily scrum work board.
Managers and Scrum leaders don't like bugs! Many of them feel they should only be created when found in production, but that attitude is how tech debt grows, lack of visualizing Bugs means they don't exist. Bugs should be created whenever a bug exists, even in dev after a sprint. The bug queue is really our best friend, as it is a catalog of the current functionality of our product. So what, if the bug backlog is large, at least it's visible and planning can occur.
Who let the Tech Debt in, and why is it still here?
Tech Debt is a manifestation of a much larger, environmental issue. It's everywhere, starting on the very first line of code, it's like a toxic mold, which requires a lot of effort to remove. Without removal, the product simple dies a slow death. Managers must recognize tech debt.
Be Careful
Be very careful to always maintain a positive attitude towards this effort. Reason: The managers who are there now may have been the ones that approved the architecture that created the "tech debt". They may be interested in hearing about the effects of their decisions 5 years ago, but most will not. Especially when it cost the company a lot of money to bring in someone that did the work in the first place.
You could look into Tech debt, there are ways of calculating how much time it will cost.
Check this post out medium.com/the-andela-way/what-tec...
If you search on dev.to, there are a lot of posts about this topic, see dev.to/search?q=tech%20debt
There are also some tools to do it automatically depending on the language as well.
Side note: I'm currently working on a project that was handed to us, that has something like 3yr tech debt on a 1yr project xD