Technical debt can make your team leave
Technical debt (also known as design debt[1] or code debt) is a metaphor referring to the eventual consequences of any system design, software architecture or software development within a codebase. The debt can be thought of as work that needs to be done before a particular job can be considered complete or proper. If the debt is not repaid, then it will keep on accumulating interest, making it hard to implement changes later on. Unaddressed technical debt increases software entropy. Also known as a feature gap. — Wikipedia
Yes, technical debt is real in most software companies. And here is why it is important to tell your team about how you are going to deal with it and repay it over time.
Let's take Company A that has a huge legacy code base that stills runs in production. The code base is 10 year old and it's still maintained the old way. Business was built on it, and it still grows on it.
In Company A, there are fresh junior developers willing to change the world and they have lots of passion for new technologies. When they look at the old software, they are angry, they feel it's just good to be thrown away and with reasons: 95% of the code is neither documented or tested.
Frustration is growing, and these young fellows are making a plan in the shadows to overcome the old software and overthrow the mighty seniors.
But it won't work business-wise and here's why:
Budget and ressources
For a 50 people company, you can't just give the budget for a big rewrite of the software. When 50 to 100 clients are depending on an old infrastructure, you can't just say throw it all away and replace it. As you have to maintain that, managers can't decide half of the team is going to work on newer solutions and the other half support the rest of the software. You'll end with two branches, with clients' needs and you'll have to backport everything from one version to another. And clients will not be happy with the time it now takes to have a simple bug fix.
Also if you have a support team, they'll need to handle issues on both software and you'll have to train them. That will cost time and energy which is usually not affordable.
Lack of planification and the Evil premature optimization
"I'll make it in 2 months". — Naïve Junior Developer
No you won't. And as you line down your arguments (like "it will make the app 20% faster, more maintainable, more scalable, this is the next big thing, bla-bla-bla), the planning is just going to extend and extend… Why ? Because you simply can't predict what side-effect all those new integration will have and the compliance with the clients will still remains and you'll have to stick with it. Therefore you can just multiply your 2 months estimation by at least a year.
With that, your managers are going to put pressure on you because you don't deliver as fast as you predicted. And you'll end up creating a new technical debt. You'll skip testing and documentation. And code without tests is just as bad as the old software. I don't care about how beautiful your indentation is, how performant your object keys-values loop function is. If you can't modify the code without automatically and quickly know if the behavior is broken or not, this is bad code.
Then of course, as you are a beast developer, you are going to optimize your code at the very root from the start. And you'll end up missing the point of just making it work properly first. Which will lead to beautifully-coded-non-working software.
And only after those 2 years, maybe you’ll have something working but project managers won't just accept to give it to client because of all the cost it might need with new installations and deployment tools.
People will leave the ship
It's not only developers fault. Realizing management has no plan to repay the debt and that developers are asked to work on more and more features still based on this Jenga Tower, your development team will eventually start to leave (except for the always-satisfied people).
They will start to leave because of the lack of motivation, boredom, and the sensation of being stuck, powerless.
With less working power, managers will have to fully focus on client demands and cut all research that could have been made before.
Always have a plan for your team to deal with the debt and communicate about it.
So basically, what can we do?
Baby steps make changes.
Dealing with technical debt isn't easy but rewriting everything is definitively not the solution.
Michael Feathers has published a book on how to deal with legacy code. To summarize, you need to cover this legacy code with tests. Any kind of test, at this point, is good. Once you covered it and you know what to expect from it, you can start the refactoring. An untested code means that any change you make will break something, according Murphy's law.
Oh yes, writing those tests will be pain and blood but ultimately, it will take less time than the big rewrite you were so fond of.
Once you have that coverage, splitting the code into smaller pieces to test will be easier and developers will see some light at the end of the tunnel.
#GetDisciplined
You will still need to add feature or rewrite functions in the code. And you'll have a budget to do so. Make sure to include the testing in it and tell your managers about it. Once they realize the positive impact on your job, they will be convinced about the benefits and will let you do more and more. If they don't, then I suggest you to leave the boat.
Then discipline yourself to write those test and make sure they run. Use tools to automate your tests like Jenkins, Travis.
Then make sure to document it. I cannot stress how bad is it to say "the code itself is the documentation". F*** that, just explain it in other words!
Not only you will make other developers' life way better, but you will also improve your own comprehension and skill to explain technical stuff.
tl;dr
If you think recreate the world is possible, then just don't and work hard to make it better instead.
