Sunday 11 October 2015
While in many ways a subset of temporal technical debt, the impact of unaddressed technological debt is significant enough that it’s worth breaking out as a separate category.
Technological Technical Debt occurs when the age of the technology stack used starts to cause issues. These may be minor at first, but the longer left unaddressed, the more serious the issues will become and the more expensive any remedy will be.
One of the things that makes technological debt so serious is the way that it gets significantly worse over time. This is largely caused by the ongoing march of other technologies as they move forward with new features and architectural changes.
The clock starts ticking on technological debt as soon as the vendor announces any end of life dates. When the product stops receiving regular updates, or worse, when it stops receiving security updates, problems start to creep in at an ever increasing rate.
Targeting Windows 98
If you were writing consumer software in 1999, it made sense to target Windows 98 - the most stable, performant and feature rich version of Windows yet released. The new features of Windows 98 and its success in the marketplace made it a compelling target for developers.
When Windows XP was released in late 2001, thanks to the tireless efforts made to achieve backwards compatibility, almost all Windows 98 software continued to work. This left vendors with an interesting decision - upgrade the software to a native Windows XP application (leaving those still running Windows 98 behind), or leave things as they were.
At the time, it seemed to many to be obvious that the best choice was to maintain compatibility, targeting the widest possible market with an application that worked on both Windows 98 and Windows XP.
Fast forward to early 2007 and they suddenly found the software wouldn’t even run on Windows Vista - many good practices that had been merely advised in the past were now strictly enforced, and many poor practices that had been tolerated by Windows XP now resulted in application crashes or the appearance of the oft hated User Access Control dialog.
By continuing to target Windows 98 long after it had passed its use-by date, these vendors accumulated technological technical debt. The long success of Windows XP in the marketplace, and the issues Microsoft had in getting Windows Vista out the door (including the famous Longhorn development reset) allowed them to get away with this for a long time and made the realities of Windows Vista into a nasty (and expensive) surprise.
Visual Basic 6.0
Using Visual Basic 6 for bespoke enterprise software development in 1999 made very good sense. Enterprise developers the world over were able to quickly and effectively create in-house software for an extraordinarily wide range of businesses.
However, even though many people report success running the Visual Basic 6.0 IDE on Windows 7, it has been officially unsupported since April 2008.
To support their enterprise customers, the Visual Basic Team has put in considerable effort to ensure that the applications themselves can run even as recently as Windows 8.1.
However, it looks as though any company still using VB6 applications, or anyone still using VB6 for development, is going to have a hard time of it as they upgrade past Windows 8.1.
Borland Delphi 7
Using Delphi 7 for native Windows development in 2002 was a very good idea - the product was mature, the IDE was productive and the resulting executables blazing fast.
By 2006 - and the sale of Borland subsidiary CodeGear to Embarcadero, not so much.
Management of Technological Technical Debt
As with any technical debt problem, there are many approaches you can take to address the problem. The worst thing you can do is to pretend that it’s not an issue - the progress of time takes away options; if you bury your head in the sand and ignore the issue, you might run out of time.
Stay Informed - you need to stay up to date with the vendor’s announcements about your technology stack. Get on the mailing lists, subscribe on twitter or connect on Facebook. Do whatever you need to do to stay informed about what’s happening. Many Visual Basic 6 developers failed to do this and got a nasty surprise when they found their applications wouldn’t run on Windows Vista without triggering UAC.
Start early - once you know there is a sunset date for something, start planning the work you need to do. There might be a simple alternative or upgrade you can fit into your existing schedule. Starting early allows you to avoid any mad scramble for a fix when things break - preserving your reputation and your customer-base.
Minimize dependencies - every dependency you take, whether on a technology platform, a third party library, an open source tool or an internal framework, is another link that might hold you back. I know of one company that attempted an upgrade from Delphi 5 to Delphi 7 at least three times - each attempt failed because one or more of their many dependencies were incompatible.
Keep Up to date - if you do take on a dependency, ensure you stay up to date with the latest appropriate version. Other software vendors have to face technological debt as well and should be updating their products too. They’ll be addressing their limitations, opening the way for you to upgrade as well. This applies to your core platform as well - continuing to develop on .NET 1.1 in 2015 does not bode well for the future.
Modularize - Where possible, create seams in your system that are in some way technology agnostic, as these will allow you to upgrade or replace parts of your system without affecting others. A client consuming a REST interface doesn’t care about the technology stack used for implementation - so you could completely replace the server (or the client, for that matter) without much impact. This is one of the drivers for the evolution of microservices as an architectural pattern.
Conclusion
Technological Technical Debt is particularly dangerous because you can often get away with ignoring for many years before it emerges in the form of an issue that threatens the very existence of the product. Importantly, the key thing you must do to avoid it is not a technical activity - stay informed.
Comments
blog comments powered by Disqus