Ministry of Justice abandons key plank of £280m IT project

I feel dirty for saying this but you mean like Exchange can? Or dirty in a different way Google Calendar?

If 95% of the business world can run on those 2 - why on earth is anyone considering a bespoke system?

I assume the hard bit is actually client access, authentication and user protection/management, cant see the calendar itself being that tricky.

Yeah, it's definitely not as simple as that summary sentence makes it sound. Beware the oversimplified requirements eh? That kind of optimisation problem with complex constraints is non-trivial - and that's before you get in to the technology needs of most magistrates, plus their wish to have their own time wishes accommodated (all of them).

Probably paid too much for it, but it definitely isn't an alternative to an Outlook shared calendar.

Re: IT, fostering delusions since 1977

Excellent work. Having run out of various construction analogy’s even after the many successful projects completed. It never staggers to amaze me how the general level of understanding of building a secure data-intensive website, basically equates to a graph in excel and sticking pictures in an email to the stakeholders. It’s also not that hard if you generally manage around the requests and stick to the plan. Ta da! A system that works. As ever the cost of all the process except for build and testing outweighs the usefulness and certainly avoids hitting the target five years ago. On the other-hand I can see the benefits, the dev team has been downsized, financial targets have been met and promotions gained plus the gap is now ten years away. #anewbumperreallyshiny

Re: IT, fostering delusions since 1977

Here's a thought for anyone, government or otherwise, contemplating a non-trivial software project: if you do not devote at least as much attention to analysis, planning, costing and resourcing to the project as you would to the purchase and erection of a home extension, forget it: it's going to fail. Expensively.

That is true, but in the case of the British Civil Service, I can assure you that vast amounts of money and time ARE poured into analysis, planning, costing and resourcing.

Unfortunately, none of that helps when the people making decisions don't know what they're doing, but won't delegate to those who do. This applies to almost all aspects of government policy making as it does to expenditure decisions, which is why most government IT projects are a mess, why defence procurement is such a never-ending disaster, and why energy, transport, taxation, welfare, healthcare and every other government policy are such convincing screwups.

Let me offer you a minor policy example from today. Government are "consulting" on a policy that will require energy suppliers to purchase small scale renewable energy power at a positive price, even in the expectations that the deluge of subsidised renewables currently being built will cause periods of negative wholesale prices. So, having subsidised 100% of the asset in the first place, when those subsidies stop, your and my 'leccy bill will go up to pay for power for which there is no demand. Elsewhere, to create the demand to use this power, selected commercial users will be paid "demand turn up" payments to actually use power. So there you have it: A crap-headed idea, a full "impact assessment", the involvement of every consultant and interest group that can dip their bread in the gravy, an expensive consultation, more analysis, then hand over to the clowns of Ofgem to plan a ridiculous and expensive implementation, and a stupid anti-common sense outcome.

Let no man say that the Civil Service do not devote attention to analysis, planning, costing and resourcing. They just don't give a flying f*** about the outcomes.

Re: IT, fostering delusions since 1977

No, waterfall is all but dead these days in software. Remember the software crisis? Massive failures like NHS National Programme for IT and BBC Digital Media Initiative. Hundreds of millions of pounds invested in IT projects without a single line of code making it to production - that's the hallmark of waterfall. Waterfall is a key element to how Sun Microsystems, IBM, Yahoo etc all worked, and they were simply outpaced by the FANG crowd doing agile. Read last year's 'Accelerate' book for plenty of research showing the agile/devops juggernaut delivering way way more than teams using waterfall.

Houses, bridges etc are mostly commodities. Built endlessly all over the world to the same well-worn architectures, same materials, same methods over many decades. Also very expensive to change anything once built. That's why waterfall and detailed specs up-front are best for building these sorts of things.

However, software is a very different beast. You're likely building something highly unique, and new for users, so you're simply going to get it wrong if you try to plan it in any detail. Tech changes quickly, so your raw materials and techniques are changing under your feet. However changing what you've built is cheap, enabling you to do prototyping and put stuff in front of users early on, to significantly de-risk big decisions. Being flexible like this often makes a huge difference to the success. Deliver an MVP to production within weeks and you'll find out very quickly if it is adding value and where to focus effort. YAGNI (You Aren't Going to Need It) is a big thing for cutting cost. You mention complexity, and in agile you should of course consider architecturally significant issues up front and review them as stuff comes up.

Sorry to the remaining waterfall brigade, but even by planning incredibly intelligently and thinking really hard at the start you're still onto a loser on average. Sorry that agile has been hyped up by arrogant kids in t-shirts and trainers, but all the evidence shows they are right.

Re: IT, fostering delusions since 1977

@Milton: IT, fostering delusions since 1977 .. “*¹ Agile: applying faddish, laziness-inspired 'methodology' in deferring the hard work of analysis and understanding of details, and delaying the realisation of disastrous malfunction and wastage—until it's too late.”

This should be printed out and posted on every wall in every IT company in the land, well said sir !!!

Re: IT, fostering delusions since 1977

Here's how things work in the real world of software development:

Customer spends 2 years and massive amounts of money developing an unambiguous, watertight specification. This takes endless rounds of meetings, consultations, requests for comments, workshops and fact finding trips.

Specification is put out to tender. The only companies willing to wade through the 3000 pages of specifications are massive, multi-national conglomerates (MMNC). Small, innovative software companies know to avoid this potential clusterf*ck.

After a year, there are only 3 tender bids, all from the same 3 MMNCs. All 3 bids are similarly priced and will take several years to complete. The tender is awarded to the same MMNC which has several other, similarly sized contracts.

Work commences and initially proceeds well until the first change request. It turns out that some requirements have changed since the spec was developed 3 years ago. Some things are no longer needed but other things are now essential. MMNC does an impact assessment and says project will be only delayed by 1 month, with no impact on cost. This emboldens people who now think that *all* changes are free. Changes now come in thick and fast as a lot has changed in the intervening 3 years. MMNC then says that project will be delayed and cost more as changes are not really free, after all.

Work still goes on until someone notices that the colour of a widget is not specified. All work stops while the colour is queried with the company. This takes endless rounds of meetings, consultations, workshops and fact finding trips. After 3 months, a decision is made on the colour of the widget and work recommences.

The above cycle is repeated until something is *eventually* delivered at twice the cost and twice the time. Users try it but their needs have changed in the 6 years since the spec was written, so they don't use it.

The 'blame game' now starts in earnest with the company and MMNC each pointing the finger at each other. This continues until the next specification is developed and put out to tender.

Re: IT, fostering delusions since 1977

+1

But, no, you’d use 1700 napkins, just for the contract, so one actually working on the system, rather than the doc and contract, would have the time to become knowledgeable about the system as a whole.

Paperwork and CYA would trump working software. Agile it up to make it look good. Testing? Hah!

Truth is, between rapacious and incompetent consultants and indecisive and incompetent bureaucrats, I have no idea, after working in software all my life, how you could systematically bring even medium complexity gov projects to satisfactory ending.

https://www.cbc.ca/news/canada/ottawa/phoenix-ibm-contract-union-pay-government-1.4295827

Agile after Alzheimers?

Legacy application:

* underlying hardware isn't made or serviceable anymore

* underlying system software is not updated or supported anymore (e.g. compilers, libraries)

* original architecture no longer extendable (they've retired)

* application no longer maintainable (see above)

It's not 'legacy' even though still used, but legacy because practically and realistically "we can't go on this way!"

Without forethought and continual attention, software systems age and become fragile just as people do.

legacy: 4. A piece of ones' history left behind for following generations to experience.

No, that didn't include any PCs. But it did need to cope with a very complex identity verification process and complex on-boarding processes, and a lot of audit functionality (unless you'd like anyone to be able to pretend to be a judge online for a bit?) Still screwed though.