The meta definition of debt goes something like this:
“A debt<T> is created when a creditor<T> agrees to lend a sum of assets<T> to a debtor<T,R>.
In modern society, debt<T> is usually granted with expected repayment; in most cases, plus interest”
In other words, If you borrow something, etuiqette dictates that you pay it back – especially in instances of debt<money>, with interest. If you don’t, bad things will happen to you, and you’ll probably end up having to sleep under a bridge – with aching knee caps as a possible consequence of using the wrong T for creditor (chosing creditor<bank> is usually a better idea than creditor<Tony S>)
In the case of debt<technical>, creditor<enterprise>, asset<time>, “debtor<T>” gets interesting.
It is worth mentioning that the consequences of technical debt actually varies according to the developer’s religion. Islam prohibits lending with interest, so a debtor<developer, Sheik Yerbouty> gets away with paying less than an instance of debtor<developer, Catholic girl> where interest has been a concern since the days of Charles Babbage. On the other hand, an instance of debtor<developer, Jewish princess> implementing an especially inefficient piece of code, will literally get away with technical murder (According to the Torah, all debts should be erased every 7 years and every 50 years)
Another consideration is that we (for the type definitions above) actually need two instances of debtor<T>. This is because one usually goes out of scope before the transaction is complete. This is especially true for the pair<debtor<consultant>, creditor<enterprise>>
To complicate matters further, the semantics change dramatically across the domain of type parameters.
In the case of debt<financial>, creditor<institution>, asset<money>, debtor<Joe> we have just defined the driving force behind the global economy, growth and prosperity.
If we switch back to the technical debt type parameterization scenario, we end up with the unit-testing mafia’s classical rhetorical dilemma “pay now or pay more later ?”. In this case debt is interpreted as bad and should therefore be avoided at all costs. Unfortunately, their intepretation is based on their inability to grasp the concept of two temporally coupled instances of debtor<T>
Technical debt is a good thing. It’s what makes the IT world spin. Without it, every system would work flawlessly and be so easy to maintain and extend that 95% of us would be out of a job – and therefore probably end up having to sleep under a bridge. There is actually an argument to be made for a significant global increase in the aquisition of technical debts.
1: An enteprise with a large technical debt will likely require the services of an increasing number of developers to keep things under control (and probably also additional manpower to compensate for the software’s inability to support the core business processes). More developers will introduce more technical debt and the cycle continues. Eventually everything will collapse and the original software has to be replaced by new and improved software. Fortunately the introduction of a piece of new and complex software requires the services of domain- and software experts. If the software gets complex enough (and it will, if the debt is large enough), one will have to refer to the previous implementation to be absolutely sure that all the implicit knowledge contained in the old implementation is transfered to the new implementation. This includes representations of data and logic. If (reader<executive> == typeof(you)) Goto 1;
Debt is good. It’s very, very good.
It provides more jobs than any enterprise can ever get rid of by downsizing. If they select the outsourcing option, the technical debt increses even faster because of a higher technical interest. In addition to this, it will also (eventually) drive your salary skywards due to the fact that educational institutions don’t scale, but technical debt does – exponentially.
Normality and semantics are hereby restored.
[Ed: Some definitions may accidentally have been ripped from Wikipedia in the process of writing this article]
This won’t hurt a bit. Just take a deep breath and relax – while we introduce you to the…
If you’re a developer, you’re probably thinking something along the lines of:
“Is it… ?”
If you ever presented a design like that to anyone – you’d probably be out of a job. You can, however replace the blob with a more traditional ESB long-box representation and dangle the services below it (This is one of oldest marketing tricks known to man, also known as the “homeomorphic swap”)
It still has the same topology and the same coupling issues that are indicative of “something that knows too much” and “a certain brittleness”, but now – you have become architect material.
As an architect, you might be tempted to make an argument that everything is fine and dandy, because it’s loosely coupled.
If there were no hardwired endpoints, and you had a service discovery mechanism powered by a Wintermute AI at your disposal – you would probably get away with it (The odds are – there are – and you don’t). That is, as long as your architecture only needs to support read operations.
The “Bus” concept is somewhat analog to a semantic sucker punch. The word itself practically induces associations to some kind of Matrix like hosting mehcanism that suddenly made distributed computing easy.
The one thing the analyst forgot to tell you all those years ago at that expensive conference - was that an ESB is a piece of software that is running on a piece of hardware. There is a high probablity that your ESB actually obeys the laws of physics. I.e. it doesn’t really work, does it ?
REST didn’t kill SOA – there was no need.
Three months of uninterrupted service in a hostile environment has to be a new Annoyatron record. People have literally dismantled office equipment and even been on their knees trying to locate the source of the 12KHz sound. Successful deployment tactics seems to be associated with sound reflection and diffusion.