8 Tips to Avoid Reckless Technical Debt

William McNamara • August 8, 2017

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.


1. Define your project goals before you do anything else


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.


2. Anticipate necessary integrations


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.


3. Take your time to do it right the first time


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.


4. Document everything you do


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.


5. Flexible is better


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.


6. Try to avoid parallel development


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.


7. Test suites are absolutely necessary


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.


8. Be watchful of IT contracting companies


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.


By William McNamara March 19, 2023
Like many music enthusiasts, the most used app on my phone by far is Spotify. One of my favorite features is their daily or weekly curated playlists based on your listening tastes. Spotify users can get as many as six curated ‘Daily Mixes’ of 50 songs, as well as a ‘Discover Weekly’ of 30 songs updated every Monday. That’s more than 2k songs a Spotify user will be recommended in a given week. Assuming an everage of 3 minutes per song, even a dedicated user would find themselves spending more than 15 hours a day to listen to all of that content. That…wouldn’t be healthy. But Spotify’s recommendations are good! And I always feel like I’m losing something when these curated playlists expire before I can enjoy all or even most of the songs they contain. Or at least I did, until I found a way around it. In this articule, I’m going to take you through Spotify’s API and how you can solve this problem with some beginner to intermediate Python skills. Introduction to Spotify’s API Spotify has made several public APIs for developers to interact with their application. Some of the marketed use cases are exploring Spotify’s music catalogue, queuing songs, and creating playlists. You can credential yourself using this documentation guide . I’d walk you through it myself but I don’t work for Spotify and I want to get to the interesting stuff. In the remainder of this article I will be talking leveraging Spotipy , an open source library for python developers to access Spotify’s Web API. NOTE : At the time of writing, Spotipy’s active version was 2.22.1, later versions may not have all of the same functionality available.
By William McNamara August 1, 2022
Speech given at the University of Virginia on July 31st, 2022
By William McNamara March 6, 2022
Online gaming communities need to work harder to close the gap for their female users.
By William McNamara February 15, 2022
Hospitals hold the key to predicting how long a product will be on the shelf.
By William McNamara June 5, 2021
The game you're playing has probably never been played before.
By William McNamara December 21, 2020
Sometimes it's better to build it yourself.
By William McNamara April 6, 2020
Learn what steps you can take to get started as a Salesforce professional.
By William McNamara August 3, 2017
Originally published on govloop.com
By William McNamara July 25, 2017
Originally published on govloop.com
Show More
Share by: