This week I've taken the time to watch a few things and write a tweet thread that proved popular.
Inquiry: Challenges In Implementing Digital Change
First up, was the Public Accounts Committee inquiry into Challenges In Implementing Digital Change. The committee used the written evidence well to ask the witness well-formed questions. Yet one member demonstrated the lack of understanding that one of the pieces of evidence opened with:
Dan Carden MP, instead of using the evidence to fill in his knowledge gaps, gave his ideas on how to implement digital change:
Surely starting every system from scratch in one department and the numbers of failures we've seen, if you were creating a system from the beginning wouldn't you set one system up across government - video
The film does indeed capture very well the challenges organisations face as they attempt to juggle legacy debt alongside new cloud platforms, and the dual IT environments these create.
HPE have a shiny manifesto too, which does repeats the themes many people say in the public sector, yet nothing gets done about them, e.g. "Current challenges such as legacy procurement and budget processes that are predominantly focussed on capital expenditure, only perpetuate the budget drain caused by legacy IT."
I was nodding at everything Tracey Jessup (CDIO of UK Parliament) was saying... "Work with treasury to think how to alter the Green Book and make sure it can best meet what's needed in the current cloud environment whilst also hitting everything it needs to around transparency for the public and the treasury."
The documentary features many more public sector people. Good to know there's a growing consensus on what the major systemic blockers to digital transformation are.
Suggestion: formally detach the DDaT function from Civil Service pay controls
I did a tweet thread! And it picked up some interest. What do you think Central Digital and Data Office (CDDO)?
Suggestion: formally detach the DDaT function from Civil Service pay controls. From where I sit, hiring people for technical roles has gone from hard to harder and awkward pay rules are not helping.
Software maintenance is important, and warrants more analogies. Maintaining a restaurant is an obvious thing to do. With software, maintenance is not as obvious as it is in the physical world.
Maintaining a restaurant
You: "Can I have the Tiger Prawn Goan Curry, Chips and Mixed Garden Leaf Salad, please?"
Chef: "Sorry, that will take 4 hours."
Chef: "I haven't cleaned for a few weeks. I need to wash pots and pans, scrub the surfaces, scrape the grill, restock, throw out the old stuff in the freezer..."
This scenario rarely happens of course. Maintenance activities are a business as usual activity. They are mostly invisible to the customer, except for the clearing and cleaning of tables. The customer's bill doesn't have a line item for maintenance. It's an operational cost to the business.
When maintenance activities are neglected, risks increase. Customers get food poisoning. Staff get stressed, then leave. Hiring new staff happens in a state of panic. Standards slip. Food inspectors enforce action when things get really bad.
When risk is so high, operations, and therefore customers, are impacted. The restaurant must close for a deep clean and reorganisation, or permanently close. Some equipment must be thrown away because it's so encrusted with harmful, hard to clean bacteria. And replacement parts don't exist anymore.
Customers value good food, and a memorable experience. They don't value what happens behind the scenes.
Clean as you code
Back to software. Customers value working software. Customers value quick response to their changing needs.
The expected lifetime of software is important. The longer the lifespan, the more significant maintenance becomes. The value of maintenance is the capability to respond to changes within reasonable time. Maintenance keeps things simple or, at the very least, enables you to manage complexity.
When you code, without cleaning as you go, risks build up. Software becomes harder to keep working and harder to adapt to change.
Unmanaged complexity makes it riskier to deliver new business value, address security vulnerabilities, remain compliant with regulation, and keep operating at an acceptable level of performance.
Expedient repairs are the natural state for software lacking preventative maintenance. They are costly and treat the symptom, by continuing to deliver value in risky ways.
Reorganise as you change
Some restaurants aim to keep quality high, so stay small and exclusive. They know what they're good at, their staff and customers value this specialisation.
Some restaurants want to adapt their business, offering more choice to more customers perhaps. They hire extra staff, perhaps invest in larger premises but most importantly they reorganise around a suitable commercial kitchen layout, factoring in the most important considerations - ergonomics, space, staff communication and safety. The outcome remains the same - good food, with more choice, to more customers.
Likewise, software that powers a product must reorganise as it scales its features and gains more customers. Reorganise software into small, disposable components. Small components are easier to build, clean and discard. Small is less complex, easier to change and keep working.