Mr Asylum White has finally decided to join the DGI team. This addition significantly increases our chances for realising our long term strategy of achieving World Domination.
(mr Asylum White analyzing a paradigm shift)
Recant Heretic Priest
Epic Retina Stretcher
Irate Erect Sphincter
Erratic Pretence Shit
Antichrist Creep Tree
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.
Welcome to the new (and hopefully somewhat improved) Dark Grey Industries site !
Many thanks to all you fourteen year olds who have been flooding us with comment spam and also to the four friggin’ thousand attention seekers that registered as users. Your input (literally) have been invaluable in our decision making process regarding migration to a different CMS.
Agile and Lean came storming the door
Around and around the teams would go
Bigger and better, faster and more
But then Agile and Lean brought a friend
His name was SCRUM, I kid you not,
“Certified” is what we all had to be,
SCRUM couldn’t tell us – but faith so strong
So now I know,that I’ll never be
“Damn good coffee!” I said to myself. I was sitting at my usual table in the “Restaurant at the end of the Universe”. My waitress, always the same girl, had just taken the order and left for the counter. “Lovely Rita”, I called her, because that’s her name.
Today I had ordered the “Bundle-O-Burgers”, or BOBs, as they were conveniently called here, my favourite meal in this particular restaurant. Taken simply with plenty of water to drink. And, not to forget, while waiting for this feast, a cup of the famous “Barista Guild’s Cuppacano(tm)”, or, a little less convenient, but good enough for this story, I decided, “Barcano” for short.
I got my book out and was just finding the page I’d gotten to when I heard a dear and familiar voice. “Uncle! Hey, may I join you?” I looked up and there was my nephew Danny with a boiling-hot Barcano in his hand, newspaper in the other. Like me, he was in his work clothes, so I figured he was here for his lunch, too. We whatsupped each other and even did a casual high-five as he was sitting down opposite me. “Cool”, I thought. Oh yeah.
Our BOBs arrived and we dug into them. Delicious, as always. I was on my way into the third one when Danny craved my attention – “Uncle?”. “Stop calling me that”, I said. “I’m not your uncle, It’s just an economical narrative technique I employed, so that everyone would make the assumption that I know you really well.”. Danny went “Umh, OK, ah, er – Dude?”. Oh no. “Just call me ‘Man’”, I demanded. “It sounds cool but not overly so, and besides it’s true”.
I looked at him, baffled; “You get paid, don’t you? And I mean, a satisfied customer who pays you what you are owed, and possibly even retains your services on his next project, isn’t that recognition enough? What more can you realistically hope for?”
Wow, I thought. Ridiculous, but at the same time maybe not all wrong. I did a huh again – slightly more successful this time. “Well, er – what have you come up with so far? I mean, the underlying philosophy and ideas, and such, what will you base this movement on?”
He looked at me. I looked at him. I didn’t know what to say, so I said it; “Listen, these statements make even less sense. They are just babble, and they’re not about your trade in any conceivable way. You can’t expect to rouse passion and commitment from anyone with this.”. He was still looking at me. “And you obviously forgot at least one: ‘Not only cooperating with gravity, but also planning for it’”. His eyes focused again. “Nah, that sounds just contrived and obvious.”. Irony wasted. I let it go.
This final tirade shut me up. It was clear he was on to something, although I had my doubts. It was contrived, it had no substance, no intended public, nothing provocative or indeed no point at all. At the same time, I realized that it might actually work if the ‘movement’ was presented convincingly enough. Assuming of cause, that the aspiring professionals of the plumbing business didn’t think to hard about what they signed up for.
Lunch thoroughly over, we did our takecares and our seeyousoons and I left the restaurant thinking about this “Craftsmanship” thing he’d come up with. It could actually work for more trades – any trade I could think off. Could something like this conceivably appear in my own profession?
Our chief weapons are: SQL Server, SQL Server Mobile, Reporting Services, SSIS, Replication Services, Analysis Services and a fanatical devotion to Microsoft!
We’ve tried Analysis Services. It wasn’t all that nice.
Well, then: Our chief weapons are: SQL Server, SQL Server Mobile, Reporting Services, SSIS, Replication Services and a fanatical devotion to Microsoft!
Replication Services is quite a bitch to maintain and service, isn’t it?
Our chief weapons are: SQL Server, SQL Server Mobile, Reporting Services, SSIS and a fanatical devotion to Microsoft!
(gives angry stare)
…SSIS doesn’t really solve any of the really hard problems we’ve been having either…
(pauses slightly, breathes in)
Our chief weapons are: SQL Server, SQL Server Mobile, Reporting Services and a fanatical devotion to Microsoft!
Sir! Report generators are too simple for most business cases, sir!
(thinks for a moment)
— Our chief weapons are: SQL Server, SQL Server Mobile and a fanatical devotion to Microsoft!
SQL Server Mobile is a nightmare to debug, sir!
– Our chief weapons aaare…
(stares at soldier # 6 briefly, soldier # 6 makes no signs of motion)
…SQL Server and a fanatical devotion to Microsoft!
(lights up, steps forward)
SQL isn’t always the best solution, sir!
Our chief weapon is a fanatical devotion to Microsoft!!
(edges forward, slowly)
Sir…? You’ve mentioned vendor independence…?
NOBODY EXPECTS THE INQUISITION!
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.
Architecture is by definition a design that even architects can comprehend.