You’re under the gun to get a software release out the door. Your manager is breathing down your neck, your customers are breathing down your neck, tick tick tick tick! Time’s a wastin’!
You, as the software developer, know deep down that your code needs more testing, more unit tests, more integration tests, more code reviews. But there’s that ever impending deadline and the clock is ticking down to THREAT LEVEL MIDNIGHT.
You want to refactor your code, because you already see inefficiencies and duplicate code.
In an ideal world, your wish is granted. You spend the necessary time, refactoring and improving your code, with the approval of your manager, and all again is right in the world!
Of course, we don’t live in an ideal world. There are looming deadlines, schedules to meet, and bosses and customers to please.
So you leave your code in a state that, without a doubt, needs to be refactored and improved, but because of external factors as we just described, you cannot. And you start creating “technical debt”.
Big deal, right? The only person who actually sees or cares about source code, is the actual software developer. The customer will neither see, nor CARE what’s going on under the hood, so why does it matter if the code isn’t in a pristine state?
This is a very prevalent attitude in many companies. And unfortunately, very short sighted.
There are REAL COSTS to ignoring technical debt.
It’s absolutely true that source code, is never intended to be seen by anyone except the actual software developer(s) creating an application. Customers will not care HOW you create their application, only that it delivers what it promises.
So say you continue adding code to your application to provide new functionality and features, but continue to ignore any sort of time and effort to keeping your code clean, easy to change, easy to read?
Over time, more and more source code gets added to the application. Other developers may take it over, and add their own features and additions. You’ve got lots of fingers in the same pie, making changes, and perhaps the original developer is no longer even part of the picture anymore. They may have transferred to another department or left the company outright.
But even if the original programmer goes away, more likely than not, the code lives on. And on. And on.
People may leave, but SOURCE CODE LIVES FOREVER.
There are so many new additions and changes, that any new software developer, responsible for taking on the application, finds it impossible to understand and follow the whole thing.
Think this is implausible? Think about the Microsoft Windows operating system. It’s estimated that Windows 8 is around 40-50 MILLIONS LINES OF CODE.
If you think there’s one person who knows what each and every one of those 50 million lines of code is doing and how they all interoperate, keep dreaming.
Is every line of code in Windows completely optimized and completely without technical debt? Think again.
Your code will most likely never reach the scope and size of Windows, but the principle remains the same.
Technical debt affects both small and large software programs.
When code cruft starts to grow in a program, the code becomes more brittle. When I say brittle, I mean it’s hard to change. Code is hard to change, when making a change, affects other parts of the code in unexpected ways, and/or breaks existing functionality.
It is very easy to get into this state of code when no proper thought or care is put into keeping the code in a clean state.
I’ve personally taken over applications, that have existed for years and years, without any attention paid to working down the technical debt. There’s no unit test, no documentation, and even the original developer is no longer available to consult.
Changing even a single line of code becomes a nightmare, as it breaks functionality in other places in the application. You suddenly become AFRAID to touch it, much like being afraid to handle sticks of dynamite.
This has REAL DOLLARS significance. A new change, which should take only X amount of time and effort, suddenly becomes 20X times the effort. And as we all know, software developers are NOT CHEAP. Suddenly, the financial and time costs to implement some new feature increase exponentially.
Sadly, some companies ignore the real costs behind ignoring technical debt, and they end up getting mired in codebases that drag them down, and discourage software developers from making any radical changes to the codebase, for fear of breaking major functionality.
Ignoring technical debt also has negative personnel consequences. No developer, given a choice, chooses to stay at a company that ignores or worse, FORBIDS, developers from paying down technical debt. Sadly, it personally gave me no choice but to leave one company which discouraged any sort of activity related to paying down their technical debt.
The companies that are willing to spend the time and money to work down technical debt are the same companies that will reap the rewards of faster development cycles, cleaner codebases and happier software developers all around.
