The Dog-Pile Index

My team and I have a new term: the Dog-Pile. It refers to the set of systems which, in our opinion, are so badly designed, or so buggy, or so poorly managed they should be thrown out and everything started over again.

It is no great admission there are systems in this list, because, lets face it, every organisation has a DogPile. In fact, its probably true to say that any system, no matter how well designed or implemented, degrades over the years till it is fit for the Dog-Pile no matter what. Systems do that you know, degrade. Rationality suggests we just admit this and work out how to manage it.

Anyway, I've stared wondering about a new IT management measure: the Dog-Pile Index - a number which is inversely correlated with the overall maturity of the IT organisation. Organisations with a relatively low DPI are very mature, the sort that are completely on top of all best practices that make things work reliably, even years after design. And, of course, those with high dog-pile indexes are poor at those same practices.

I suspect that most organisations have an average Dog-Pile Index, because most IT organisations are, actually, very average. Average is what you get in a race to commoditisation, which is what big IT is these days. There's no shame in it. Furthermore, and I know that many people will find this controversial, I'd say that the public sector IT has neither a worse nor better DPI that any private sector organisation I've worked for in the past. Its just that public sector problems are immediately in the public eye, and you can cover up private sector ones pretty easily most of the time.

All this accountability and transparency is a necessary thing of course, though I do regret that the few failures we have tarnish everything else we do. 

It is hardly surprising that any IT organisation, hamstrung by cuts and under constant change pressure, does stuff which occasionally results in a new entry on the Dog-Pile. I suspect the real trick is knowing that something is destined for that list and cancelling it quickly enough. And, of course, making sure that new entries only do happen occasionally. 

I guess, considering all that, my Dog-Pile Index isn't really a very good reflection of the relative goodness of an IT organisation after all. So let me try again.

Here's my second attempt at a new IT metric: the Time To Dog-Pile, or TTD, which is average time, across an IT estate, from Design to Dog-pile for systems as they degrade, and bigger TTD is better. As I said, every system makes the Dog-Pile in the end, so how long that process takes is an excellent measure of how good your IT organisation is.

Measuring the TTD, I'd say my Department has a fairly high score. For example, during the economic downtown, when demand for services increased by at least 30%, nothing blew up and we maintained operations pretty seamlessly. Considering some of those systems were being designed and implemented around the time I was leaving High School, I think that quite an impressive feat. And there are lots of other unsung examples, plenty, in fact.

Despite the occasional bad press we get, I am actually glad I work where I do. There are plenty of places where the Time To Dogpile is only a few years, and I've been part of some of them. It is a horrendous strain, with constant fire-drills when things go down, or exhibit that boundary-condition defect you can't trace, or become too risky to change because you can't predict the consequences. 

This is all slightly toungue in cheek, of course, but what's the TTD and DPI of your organisation? 

Comments

[Henry Law]

I love it. We could have an automatic generator of TTD figures, based on analysis of emails among the technical community about a proposed system. If too many emails say "That'll never work", we have TTD=0.

There's probably a close correlation between the size and complexity of programs; could there be a function f such that TTD = f(KLOC)? That would suggest that only programs of zero size -- consisting only of comments -- would persist indefinitely.

Where I'm working just now we have standard formats for some documents, including a "Current assessment"; I'll lobby for a TTD estimate field to be added.

Yes, I know you wrote "tongue in cheek" and my comments are in the same vein, but there's great value there nevertheless.

[James Gardner]

OO, that's an interesting idea, creating the TTD from email traffic... you could imaging a daily dashboard being sent to management with a forecast of the TTD based on present sentiment.

[Steve Law]

I was just talking to someone the other day who is hoping to retire soon at DWP; one of the guys who helped build the legacy systems that still lie at the core of the business. We were all still very proud of old ESE and DSE (core components of legacy). As the song says, we ‘built them strong, and we built them to last’ (Jimmy Nail) – 20 years isn’t too bad. I guess the systems timbers are starting to rot now, and all the components have become very non-standard. Let’s hope with the new systems and whatever chosen design approach, they become more business and customer friendly, but just as intrinsically solid and architecturally flexible enough to last.

[James Gardner]

You can rest assured we are doing that, and the present system, creaking though it presently is, has proven its worth time and time again.

[Grant (PG) Rule]

Or you could measure the actual support cost per unit size of such systems (calibrated with respect to type & complexity of the required functionality, of course). The replacement or refresh of a 'geriatric system' would then be indicated when the unit_cost_to_support becomes higher than the unit_cost_to_develop (or otherwise replace).

BTW, the trend in unit_cost_to_support for most IT systems, when graphed, usually describes a 'bathtub' curve. That is, it initially declines, then stabilises over time, then increases as the system becomes 'geriatric'. Call me a 'curmudgeon', but I don't think any new measures are needed for this. Such practices go back at least 25 years.

Perhaps more importantly, you could analyse & categorise all the 'stakeholder demand' that you process and determine how much of it is 'failure demand' generated by the department's failure to resolve the customer's problem at the first attempt. Removal of the root conditions of such 'failure demand' can be expected to reduce the overall size of the estate (and hence the dog-pile) and lead to better outcomes for stakeholders… including lower costs for taxpayers.

[Steve Law]

It still surprises me that many of the actual DWP legacy systems where built from scratch to live deployment within a timeframe of about 18 months – they were knocked out like washers with a highly re-usable and tightly defined architecture (excluding the design and build of the underpinning infrastructure which took 10 years), yet today relatively small changes can take a significant time to apply. It just shows how entropy can build up both within a system and an organisation over time, this is not unique to DWP and would make an interesting case study.

[Andy Rouse]

Interesting comment from Steve Law. ITSA did have delivery as it's main aim and we did do some really good work that has stood the test of time, not sure we can claim the same since we got rid of ITSA and looked to rely on outsourcing and best shoring. Shame we continue down the "shove it out to the supposed industry world class suppliers and the second/third world code shops", we lost the control and the quality. It is also worth seeing that some in the industry are now seeing the mistake in best shore and outsourcing and bringing back in house (Barclays) just as we look to give more out.
What worries me is we fail to build the next ISCS as good as the last because quality costs and the current climate doesn't support this.
That said with the way we have failed to replace systems when the COTS fiascos have come along I still see ISCS lasting longer than the last ITSA boy/girl.

On the DoPile front we seem to be getting there sooner with the new stuff far quicker than the old stuff - any idea why James?

[bad times]

TTD all time high has to be Lotus Notes. We just implemented it to save money and god damn it's horrible.