This is sort of a forgotten concept I came across some years ago when involved in an inherited project as I was working as auditor for a small company, but interesting enough, the real breathing of the concept did come out when diving into the thrilling world of Consultancy.

I think that the best example to describe and talk vastly about technical debt is pouring out the challenges a consultant has to fight on a daily basis at his work.

Eisenhower Matrix

We can’t afford ourselves to talk about Tech Debt if we, first don’t mention Eisenhower Matrix.

I don’t know very well about United States history not even about the presidents that nation has had along its history, but it turns out that Eisenhower, besides being an important man to many people, was a clever guy that came across an important discovery when serving the US Army back in World War II, perhaps urged by the imperative of making hard decisions during the war as commander.

Basically Eisenhower principle stands the idea of combining two basic aspects when performing some task regardless its nature: its importance and its level of urgency. The previous image is self explanatory when coming to grips of EM.

When debating to perform a specific task/project, is important to take these two factors into account. It’s pretty clear that important/urgent wins the race of this principle and when we have non important and not urgent tasks the best idea is to dump it into the trash.

Consultancy business fears Eisenhower Matrix.

The funny part comes when bringing EM into consultancy, planning and road-mapping a project is one of the most important parts of a project itself.

Nowadays, in the era of IOT, SAAS, IAAS, Serverless computing, Google, Amazon and an endless fill-in-the-blank, somehow, the business of technology has narrowed down to levels of fighting for a bit of what big companies like Google and Facebook have left for the rest of humans.

So, consultancy business has gone through the consequences of this by implementing a business model that devours Eisenhower Principles.

There are no important tasks, there’s only urgency. We play a blindfolded game with the customers by promising the job is gonna be done and it’s just a matter of time that we’ll pull everything off. The hunger for getting the next client/project is what only counts on this zero-sum game.

It all comes down to Image, not the content but the container. The real business value is: selling a facade that has not precisely to be what you do but the idea of what you do, this leads of course to wet paper on the hill. From the provider standpoint, we have a great product to sell that is: a highly skilled and specialized team of professionals that can build well standard compliant solutions for whatsoever the client needs. Even when the project specs and domain model are not defined yet. We just need a sentence that sums up your business needs and I can give you the magical recipe, exactly what you wanna hear.

And this my friend, is the business model sticking around out there in the market. From this point on, everything left is Tech Debt, the project is already sold and the development team is on its own at the same time that marketing’s is looking for another target.

Project Development Cycle => start coding right away idiot.

There can’t be right decisions out of this, by any chance. We developers, fall into sort of dying treadmill where a couple of sentences describe the whole spectrum of an ambitious system to build. And now comes into play my favorite term: Agile.

Agile Development

Agile development is a great concept, stated long ago to embrace new times, that eventually has turned into this crap where, illuminated ones in the sector, aim nothing but getting things done, no matter the costs, in the least of time. Since an image is worth a thousand words:

I think is out of the scope of this post to deliver a statement of what a development cycle is compound of, but I think is worth mentioning that it’s impossible to build a rich domain based solution applying such as disastrous formula as

abundant/rich domain model + misused agile concept + lack of analysis and design phase

it is more than clear that it doesn’t get worse from this.

Let’s suppose that we get the product done, no matter the obstacles we have found along the way to pull it off. Not to mention the business requisites getting fatter at the whims of the client, the non existence of proper documentation, no diagrams at all, nothing in the paper but mails and meetings with the client, not even mentioning the big ball of mud we have ended up with in the resulting code because of the bad decisions we have made. None of this is important, it’s just implementation details.

Springing Product Out

Well, we ship the product out to production environments so now comes the funniest part: Maintenance. This is where actually Tech Debt comes into view on its highest expression, everything known so far in terms of delays, setbacks, downsides, unmet requirements go insignificant when staring at the dimensions of what comes next.

How can you possibly unravel a ravel with a tangle as tool.

This is just an inkling of the beast right in the next corner awaiting to guzzle us up. So now problems emerge as if dwarfs:

  • Misunderstood requirements
  • Bugs
  • Uncompleted features out of rushes
  • Poor connections with external systems
  • Lack of proper communications with client
  • Absent of data/service contracts out of no documentations

If you compile all these factors together it becomes obvious that we get a nightmare that we can not see the end of the tunnel for. This is the moment of paying back for the bad decisions.

The project becomes a pain in the ass so no one wants to work on it as if a hot potato, and every attempt to fix a problem entails an endeavor n-times bigger than the initial one to create the feature. We now, from the developer point of view, face the consequences of a spaghetti-based design in the quest of addressing the problems popping and piling up at a vertigo rate. The product owner is overwhelmed as a result of the client complaining about a system that can not afford it self to follow the pace of conversions that supposedly was meant to on provider promises when selling stage.

Of course that concepts such as scalability, maintainability and extensibility are right out of context on this since this now has become a race for surviving not to mention that the system was doomed since its early stages.

Conclusion

We get what we deserve, we receive exactly in the proportion that we give. I consider this a much higher insight that goes beyond software development.

According to Eisenhower Matrix priorities scale , if we make decisions based on Urgent factor over Important we doom ourselves to eventually pay down for that kind of doings, and I can’t think of a better example to understand such a principle than a bad Software Design.

So when it comes to Software Development the price to pay comes to flesh in the way of Technical Debt. I know time is money ye, that’s why when making bad decisions we’re buying invisible debt that for sure will show up to blow up in our faces, so the time we think we are saving when trying to shorten up on deadlines will return sooner or later in the worst of forms Money Loss.