Originally Published on govloop.com: Source
In the digital age, IT experts have evolved from computer fixers to institutional power-players, oftentimes driving projects for critical changes in infrastructure. But in both the private and the public sectors, a lot of factors should go into building a new digital system. An important consideration is to avoid decisions that will incur technical debt.
Technical debt is a concept that reflects the hidden cost of implementing a sub-optimal IT infrastructure. Basically, the shortcuts you take to cut time or cost today will create headaches for you tomorrow. Any time you make a sub-optimal technology decision, you’re incurring debt for the future projects you’ll need to fix it.
Now before I get to how to avoid it I want to point something important out. Debt in any form is not always a bad thing. Smart operators can make strategic decisions to incur a little technical debt to create a certain value now, be that a faster deployed project or saving money for another project.
As anybody who has ever had a credit card knows, debt only becomes dangerous when you get reckless. When the interest that you’re paying on your debt cripples your ability to make the necessary change. Similarly, technical debt can be prudent, or it can be reckless.
So how can you avoid the reckless accumulation of technical debt? At then end of the day a competent manager should know what to do, but for those that are interested here are a couple of tips to keep your project team on the right track.
This one should be a no brainer. If your development starts before any design is in place, it’s like driving in a foreign country without a map. And the chances are you’ll need to come back and rework things that weren’t designed correctly. If this happens, and you identify refactoring that will be necessary, don’t delay it, because your coders will be building something that they’ll need to fix later. Or, you can change the design and build it correctly the first time around.
Now obviously it’s impossible to create a perfect design up front. Business requirements can and usually will change up until the day the project is finished, and reworking will be necessary to go in and make the changes to comply with them. But knowing that everything is not always in your control, try and be smart about planning the things that are in your control. That way you’re not accumulating technical debt at twice the speed.
While you’re in your planning stage, ask yourself what other areas of your infrastructure this project will affect. If there will be necessary integrations (which in all likelihood there will be) then figure out if your design can work in a plan for that. By doing this early on you save yourself the time on refactoring and reconfiguring if two systems won’t play nice. Be prepared.
Of course you are going to get pressure from your higher ups to deliver on a project as soon as you can. After all, time is money. But decisions you make to cut corners will cost you down the line.
If you just do the minimum amount to get a project finished, it will be released with a substantial amount of technical debt. And the risks of any anticipated refactoring will increase dramatically, especially if it becomes integrated with the rest of your IT infrastructure. Save the nightmare later, do it now.
Your 3rd grade math teacher taught you a valuable lesson, “show your work.” Make sure that your developers and project managers document their work so that if/when any change needs to occur, there is a clear roadmap to do it.
Your IT needs are going to change, think about how much the landscape has changed in the last decade alone. Unless you want to keep scrapping and rebuilding a new system every couple of years, it’s in your interests to crate a flexible modular software design.
Modular software allows you to make changes to one component or functionality without having to change everything. Tightly-coupled components create a web of technical debt that makes even the smallest changes massive and expensive. Don’t do that to yourself.
If you have a large team it can be tempting to segment them and have them develop parallel branches that you’ll merge later. This is all fine and good but you will spend time and money later on merging them onto a single source base. Change developed in isolation accrues technical debt. It’s usually better in the long run to have your whole team on a single road map.
A test suite is a collection of test cases to make sure your software does everything you need it to do, it is one of the cornerstones of Quality Assurance. To ensure compliance with business requirements, test cases will create the necessary conditions to prompt behaviors in your software that are considered desired or optimal. It’s a great way to search for screw ups.
The real world is NOT a test suite, and when you just throw your system out of the nest before it’s tested you risk a world of embarrassing malfunctions, system failures, and costly repairs.
Now, I don’t want to knock IT contractors. Most of them will base their business off of providing you the best possible solution so that will continue to contract with them or give them good recommendations.
But also be aware that sometimes contractors could skip steps intentionally or mistakenly that will incur technical debt, creating more problems for you and more billable hours for them. The best way to avoid this is to do your research and get to know the clients your potential contractors have worked with. It’s a simple phone call that could save you millions of dollars.
All of these steps are straightforward approaches that have helped project managers to deliver long term solutions that don’t break the bank. As I mentioned before, a little bit of technical debt can sometimes be strategic, but keep an eye on it to make sure it doesn’t get out of hand. And as always, plan ahead.