Technical Debt: Making Something Ignored Understandable to Suits
September 29, 2020
I have been fortunate to have been on the edges of a several start ups; for example, The Point (Top 5% of the Internet), a system ultimately sold to CMGI / Lycos in the late 1990s. When the small team began work on the product, we used available servers, available software, and methods based on our prior experience. When we started work on The Point in 1994, the task seemed pretty simple: Use what we know and provide an index to curated Web sites. At that time, it was possible to scan a list of new Web sites select ones which seemed promising. This was at first a manual process, but the handful of people working on this figured out ways to reduce the drudgery.
I learned (as one of the resources for hardware, software, and money) that those early decisions were both similar to established business economics and quite different in others. Let me give one brief example and then address the information in “Most Technical Debt Is Just Bullsh*t.”
For The Point one of the wizards on my team used Paradox. I know the Georgia Tech grade and Westinghouse Science winner asked me and I just grunted. Who cared? This was a mere test of an idea, not a project for an outfit like Thomson Corporation or the US government. My partner and I had worked on a CD of bird songs, and The Point seemed similar to that effort. Who knew in 1994? I sure did not.
That Paradox decision created technical debt. The database was okay, but it was not designed for multiple humans and software systems to update the files on a continuous basis. We could not do real time because the cheapo Sparc server I had was designed to run an indexing system called STAR. We figured out how to make Paradox work, but those early decisions had lasting impact.
I realized that making a database decision was similar to Henry Ford’s River Rouge. That concrete and building built at one end of the giant complex was not going anywhere. First, Mr. Ford was busy making cars. Second, Mr. Ford needed the resources to be directed at making more cars. Third, Mr. Ford had to make decisions about now problems, not problems that were not fully understood at the time of making fresh decisions. As a result, River Rouge became a giant thing that was mostly unchanged and unchangeable. The same observation can be made about Google-type companies. (Think of new features as software wrappers, not changes to the plumbing.)
That’s technical debt. The focus, resources, and understanding to change what has been put in place and actually working is not a hot topic for a robust discussion of “Let’s do this over again.” Nope.
The Louwrentius article dances around this reality in my opinion; for example, recasting Ward Cunningham, who coined the bound phrase, the write up states: Technical debt exists:
as a form of prototyping. To try out and test design/architecture to see if it fits the problem space at hand. But it also incorporates the willingness to spend extra time in the future to change the code to better reflect the current understanding of the problem at hand.
The write up ends with this statement:
Although Cunningham meant well, I think the metaphor of technical debt started to take on a life of its own. To a point where code that doesn’t conform to some Platonic ideal is called technical debt. Every mistake, every changing requirement, every tradeoff that becomes a bottleneck within the development process is labeled ‘technical debt’. I don’t think that this is constructive. I think my friend was right: the concept of technical debt has become bullshit. It doesn’t convey any better insight or meaning. On the contrary, it seems to obfuscate the true cause of a bottleneck. At this point, when people talk about technical debt, I would be very skeptical and would want more details. Technical debt doesn’t actually explain why we are where we are. It has become a hollow, hand-wavy ‘explanation’. With all due respect to Cunningham, because the concept is so widely misunderstood and abused, it may be better to retire it.
My personal view is:
- Technical debt is a bad way to say, “A software product or service is like a building that can either be a money loser or be torn down.” As long as it works — generates revenue — do as little as possible to keep the revenue flowing.
- Technical debt is fungible. It is like the poorly designed intake infrastructure for River Rouge. The bricks and concrete are not going away without significant investment and disruption.
- Technical debt is poorly understood. Humans are not very good at not knowing what one does not know. I suppose that Paradox-like. Who knew?
The good news is that CMGI’s check cleared the bank and The Point is now mostly forgotten like its technical debt. Who paid it off? I didn’t.
Stephen E Arnold, September 29, 2020
Comments
-
- Subscribe to Beyond Search
Feature archive
News archive
-
