Every development organization has tech debt. Modern development projects have gotten so large and complex that there are now dozens of libraries, frameworks, and services implemented in a modern solution. Additionally, there are always new techniques, new modules, new frameworks, new skills, and new perspectives. Applications are now ecosystems, constantly evolving, and our perspectives about them must evolve as well.
Yes, a burn down chart looks better when you pay down the debt. Yes, security flaws can force you to pay down technical debt. Yes, most developers always want to fix all the things, including impending dead technology. Modern solutions have many stakeholders. The modern roadmap has to include benefits for existing customers, senior management, the people you send into the field, and net-new customers, coming in based on new features that need to get implemented.
You can’t implement new features that help to retain customers and acquire new customers if you are always paying down technical debt. Here are 10 good ways to tell if you need to re-evaluate plans to pay down some technical debt:
- There’s a new version coming out. Let’s face it, there’s always a new version just around the corner. But a release can be imminent. Take into account the timeline of a new release and choose where to spend your precious development capital, being careful of frameworks, libraries, and services that have a new version about to come out.
- A version is too new. A cooling off period is necessary with any new technology. Otherwise, you’re learning about all the bugs and limitations of a new solution in real-time. The larger a development organization, the longer it takes to develop the institutional assets required to perform a large-scale effort to implement new technology. And the greater the risk if you go the wrong direction. For example, if you are already updating production applications to Angular 2, are you sure that’s a good idea?
- You have to retrain an entire team. Retooling an entire scrum team, or larger efforts require you to rethink how you approach various problems, and can require hundreds of hours of training for engineers. When you are looking at larger projects, consider how much time the new tools will save versus the cost to bring in experts to train your staff, as well as the hours required to actually do the work.
- You can’t hire talent that know the new technology. This is a huge red flag. Maybe you can’t hire someone to help you out because the supply is tapped, maybe you’re trying to implement a framework that’s too new, maybe the library is too old, or maybe it just plain sucks. Either way, if you can’t find engineers willing or able to implement, rethink the whole situation.
- The cost of doing the project is greater than the cost of other efforts if you do not do the project. Not paying down technical debt accrues interest. That interest can build up over time. But what if it doesn’t? What if the new project makes others more complicated, or doesn’t simplify others? Consider the impact to other initiatives, both positively and negatively when prioritizing your technical debt; especially smaller projects.
- You have to replace other parts of the solution to make the new parts work. We’ve all been there. You have 4 libraries that don’t work with the new framework. If you start the implementation of new technology, you’ll want to check on each interconnected framework and library prior to beginning to do so, if only so you can properly estimate the time required.
- Solutions come with new licensing requirements. As noted, most modern projects are ecosystems of dozens of open and closed source libraries (if not more). Many teams now keep a document, or entire database, of the types of licensing used for each of the building blocks that make up the stack of a given application. Each time you update to a new version, you’ll want to first validate that you aren’t entering into an entirely new set of licensing terms.
- Initial tests go poorly. OK, so you don’t need to scrap a project just because projects where you attempt to scratch the surface go poorly. I like to start with some small wins, stick my toes in the water, and then re-evaluate timelines based on how the initial tests go. You want to get some nice momentum on the burn down chart before you head into deeper waters when doing larger development projects.
- You can’t compartmentalize the new technology. Let’s say you’re implementing React Native into an application. You already have a user interface that users have been using for, in some cases, several years. Can you implement React on a screen-by-screen basis, or given the architecture of your existing app, will you have to do the whole thing at once? If you can’t compartmentalize the new technology, is it really right for you?
- You are spending more to pay down technical debt than on new features. Mature products often get you into a place where you’re spending more to keep up with your existing code base than you spend to implement new features in your tools. When you get into this kind of scenario, you definitely need to stop accruing technical debt; however, you should re-evaluate whether a much larger rewrite would be more appropriate than fixing little things here and there.
- Your goal can be accomplished in another way. Let’s say you have an API, and you never bothered to ship documentation on using the API. This is actually pretty common. There are tools like HATEOAS (https://spring.io/understanding/HATEOAS) that can allow you to basically self-document the API within the API. Is it better to do that or publish a quick PDF on using the API? Either way, you need the PDF. Most of us would, if time allowed, prefer to go the HATEOAS route; however, again, we have to be judicious with our time.
Ultimately, we all have a limited pool of resources. And as our solutions grow, the amount of effort required to update parts of the code will grow as well. A lot of these tips involve taking into account the resources required to update the building blocks of a larger application, or project or timing. There’s no doubt that the longer you incur the debt on each of your initiatives, the more interest each incurs. But sometimes, it’s important to keep a larger picture in mind.
With limited resources, there is no right answer when it comes to keeping your code modern. You don’t want to accrue too much technical debt. Otherwise code will become unwieldy and developers will run away from your organization when they realize just how much of a hurdle it will be to update your code. But you have to implement new technology in order to keep from keeping up with 30+ year old FORTRAN code in 2016. Next time product management and developers compete for prioritization, check these tips, and see if you’re going down the FORTRAN route, or keeping too modern; hopefully it’s somewhere in the middle.
krypted August 11th, 2016
Posted In: Articles and Books, Product Management, Programming
reasons not to pay down tech debt
Leave a Comment
We’ve all got a box sitting around somewhere, full of cables and devices that used to blink away at us until we snuffed the life out of it all by replacing it. Some of us have 10 of those, full of tangled cables that maybe went to that one camera that we lost in 2009. Many of us remember the exact price we paid for each device in those boxes, such as that $699.99 firewall. It can be challenging to replace that device with one that costs 10% of that price, even though it’s more than ample to meet our needs. And we have a hard time imagining that after only using the thing for 6 years that it’s now out-of-date. After all, don’t I still have that one sweater I bought during my freshman year of college? Won’t I need that laptop I replaced 3 years ago?
Chances are that you should burn that sweater and send the firewall and old laptop off for recycling. Of course, always make sure that you won’t be losing some data and have a backup of anything you’re getting rid of (that stored files), but chances are that some of that old stuff is completely incompatible with modern systems. Some things you should also consider throwing out:
- That old tape drive that has the backups from your server from 10 years ago.
- All those cables with pins in them. These days, HDMI, Lightning, USB, and Thunderbolt has completely replaced cables that have pins that get bent. They were great when the industry was young, but if you’re tossing things out, get rid of those old things…
- Old monitors. Yes, that 15-inch LCD cost you $500. No, you don’t have any devices that use the kind of cable that connects it to a computer.
- Old hubs, switches, cable modems, wireless access points, and firewalls. These days, most things are wireless. If you have a bunch of old devices that connected various Ethernet-based systems sitting around, toss ‘em. If you need to buy a new one, it will be super-cheap, and putting an old one on your network is likely to cause poor performance, network-wide. Old network appliances can also conflict with the addressing used on newer devices, and can cause outages.
- Old printers and scanners. These days, you might go months without printing, and like old cars that haven’t been driven in forever, they might require a mechanic to get working. Printers are $50 at Target. Ink costs more these days. When a printer has a problem, give it a good clean, and if the problem persists, recycle!
- Apps that charge you a recurring fee. Yup, these don’t fit in that plastic bin with the wires, but they cost you money. Likely every month. Everything from cloud services you tested to in app purchases that are billing monthly should be reviewed and cancelled if no longer needed.
Just toss all of it out. It will feel liberating to do so, and you’ll free up those plastic bins for other more useful stuff, like those VHS tapes of the Golden Girls!
krypted August 10th, 2016
Posted In: Articles and Books
Apple, MAC, old technology
Sometimes, your job gets old. Here’s a little article on when it’s time to look for other spots in your company or new jobs altogether http://www.huffingtonpost.com/charles-edge/signs-its-time-to-level-u_b_11210086.html
krypted July 29th, 2016
Posted In: Articles and Books
article, huffington post, new job, when to look for new jobs
Had the idea for this one during a yoga class the other day. It starts out like this:
This may sound a little surprising, but yoga and business have a lot in common. Yoga teaches us about depth and focus. But as I’ve learned, yoga can also provide valuable lessons about how to successfully run a business. And not just in regards to emotional IQ. Here are some of the top lessons that I’ve brought to how I do business from my yoga practice.
Read on here…
Anything I missed?
krypted June 26th, 2016
Posted In: Articles and Books, Business, personal
Business, practice, yoga
An hour into my first Reddit AMA with some super-excellent JAMFs!
AMA w/ Charles Edge and the Apple management experts at JAMF Software from macsysadmin
krypted June 24th, 2016
Posted In: Apple Configurator, Articles and Books, Business, iPhone, JAMF, Mac OS X, Mac OS X Server, Mac Security, Mass Deployment
JAMF, reddit AMA
I’ve worked with a lot of organizations switching between Mobile Device Management (MDM) solutions in my career. And I’ve seen the migration projects go both really, really well, and really, really poorly. In most cases, the migration is somewhat painful no matter what you do. But in this (my first) article on the JAMF blog, I try and organize my thoughts around a few things to look out for when migrating between MDMs/MAMs, and some context/experience around those.
krypted June 23rd, 2016
Posted In: Articles and Books, iPhone, JAMF, Mac OS X
Apple, devices, iPad, iPhone, MAC, mdm, Migration
Published an article at http://www.itbusinessedge.com/slideshows/10-must-have-apps-for-your-small-business.html on types of apps you should use when starting to put iPads in a small business. Obviously many a business has vertical needs, but a lot of apps are horizontal, so cut across a wide swath of industries.
krypted June 22nd, 2016
Posted In: Articles and Books, iPhone, JAMF
Next Page »
Been awhile since I contributed any content to the wonderful Bushel team, so provided an article on accounting concepts that every small business owner should know. A sample:
To be a successful small business owner, you don’t need to be an accounting expert; you can outsource that. But you do need a solid grasp of basic accounting concepts. As a small business owner, you need more than an intuitive feel for the performance of your business. Understanding a few basic Accounting 101 concepts goes a long way towards keeping the goals for your company in alignment with your performance. Here are 5 accounting concepts to get you started:
Read More at http://blog.bushel.com/2016/06/5-accounting-concepts-small-business-owner-needs-know/
krypted June 18th, 2016
Posted In: Articles and Books, iPhone, Mac OS X
ACN, Apple, Apple Consulting, articles, small business terms