"In addition, Tiscali faced some IT issues in the past and worked pragmatically to fix them, resulting in some discontinuities between systems – we are repairing this now," www.computing.co.uk/computing/analysis/2252848/ringing-changes-talktalk-4893004
There are, no doubt, times to go for the cheapest, quickest most 'pragmatic' solution to getting systems to mesh together. But in getting to a solution for least cost there can be an accumulation of 'Technical Debt'. I know that one of my clients in my day job, keeps a measure of technical debt being accumulated in development projects. But it is difficult to persuade an organisation to contemplate such debt, let alone put it on the balance sheet.
It's never easy either to argue for spending money on technical debt when you can have new shiny functionality baubles. What we find we do at Village Software when working on clients projects is try to improve things as we go along. Most clients would not be happy if we suggested they spent 10’s of thousands refactoring a system with little or no functional gain. Hence I suspect we often do this on the cheap out of a possibly misplaced or at least poorly negotiated sense of professionalism. We have recently spent a five figure sum refactoring our Lab Solution to improve it under the hood, I've got to say this hurts and we are now on a functionality campaign.
I wonder what the effect of the current recession is on technical debt. In principle resources to deal with it are cheaper than in a boom time. However the need to gain the cost reducing, innovation gaining benefits of Business Information Systems at lower investments will surely lead to an increase in technical debt across the economy. Perhaps the UK is accumulating billions of technical debt in the public and private sector to match the vast national debt in the public sector and the balance sheet retrenchments in the private sector.
The term 'Technical Debt' by the way was coined by Ward Cunningham as a useful allegory. One of the great thinkers in current software development Martin Fowler describes it on his Wiki martinfowler.com/bliki/TechnicalDebt.html. He explains that getting things done, in a way TalkTalk's David Cooper describes generously as pragmatically, is like borrowing money, you have to start paying interest, eventually you have to pay it back along with the principal. Ward Cunningham has a neat little 4 point plan referring to technical debt in software development. (For those not familiar with the term, refactoring is the practice of improving software code quality without adding functionality). Cunningham describes technical debt on his Wiki (all these guys have wikis) www.c2.com/cgi/wiki?ComplexityAsDebt :-
- Skipping design is like borrowing money.
- Refactoring is like repaying principal.
- Slower development due to complexity is like paying interest.
- When the whole project caves in under the mess, is that like when the big guys come round and slam your hands in the car door for not paying up?
Others describe it by the allegory of lactic acid building up on your muscles during a run. In the wider world of Commercial and Government ICT we can expect a build up of such debt. For businesses without a strategic plan for ICT, the resources to deliver a plan or whose plan is to accumulate technical debt there is going to be a backlog. Alas 'Technical Debt' will not be appearing on balance sheets soon if indeed there were a way to measure it. I would be baffled if a student asked how to go about measuring technical debt in his company.
I have a feeling that the Information Systems people, like me, will somehow get the blame for letting such debt accumulate.
Life can be unfair, but it is indoor work no heavy lifting.
Interesting thoughts, Johnny. Coincidentally, I was dining with a friend on Saturday night. He was originally in bioscience but retrained during the dot.com golden age (1999). He works in information systems / IT and has recently taken up a new job. (Just some background!) Anyway, we got talking about systems analysis and systems interoperability. He had some funny stories to tell, many of which were about how his employers were always driven by short term-ism in any sort of systems implementation. They disregarded his knowledge and good practice in systems interoperability: "All this stuff you learn in university about systems analysis, etc. all goes out the window in a lot of firms. They just want the cheapest option, which often means a system which isn't suited to the organisation or interoperable with anything else we have! Problems can be sorted if and when they arrive. IT for competitive advantage doesn't figure!" And he's worked for big information rich organisations (many of them household names)! It depresses him that organisations still don't understand the role of information systems in business. The irony is, of course, that information systems are essentially at the heart of the organisation; however most members of the board are not information professionals. This causes problems whenever there are information problems that require solutions.
ReplyDeleteThe exception to this is the organisation for which he works now; information systems are at the heart of the organisation and there is significant buy-in from above. A similar situation exists in banks. He used to work for RBS and informed me that most banks have systems / IT guys on the board; they are central to key organisation decisions and are seen as indispensable in gaining efficiency...