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."
You: "Why?"
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.
Maintaining Software
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.
Complexity goes up therefore risk goes up. Software is harder to keep working and harder to change. Ultimately, everyone gets stressed and your customers are impacted negatively.
I didn't work on Monday because I had extremely poor sleep. Insomnia is something I've battled with for a few years now. I'm currently using Sleepio to improve my sleep. Sleep restriction is hard but works.
This week I was lucky enough to tune into some great talks as part of Justice Servies 2020 conference. Plus I listened to Chris Atkins talk about his experiences in prison, captured in his book A Bit Of A Stretch. He did a Q&A with colleagues and gave some insight into why investments around digital and technology can be hard to land, despite the better outcomes that could be realised.
the ability to face constructively the tension of opposing ideas and, instead of choosing one at the expense of the other, generate a creative resolution of the tension in the form of a new idea that contains elements of the opposing ideas but is superior to each.
Working in multidisciplinary teams sets us up for integrative thinking, it makes it more likely. The best multidisciplinary teams are curious about each others work and open to challenge. Peter Drucker said, “There are no marketing problems, there are no finance problems, there are no accounting problems, there are only business problems.” True, yet working within the bounds of business functions is often the norm. Business school teaches siloed working. It's hard to break out this habit. I've noticed a culture clash between digital teams and "the business" stakeholders. The business are often confused about the way digital teams work and digital teams are often bemused by seemingly antiquated ways of working, e.g. committees formed around single topics, formal minutes, etc... closing the opportunity for open and integrative thinking.
Back to the panel discussion, Laura spoke about how onboarding people on to high performing multidisciplinary teams can be easy. Less mature teams should slow down and make sure people have a chance to understand who does and who knows what. She'd run an expectations exercise to help people get to this point quicker. She made a brilliant point: "if you can't describe the value that someone else brings, you are missing a trick. You will be missing opportunities to lean on others expertise and experience."
Katrin worked in the German public sector. They are at the very start of building good digital services. It's a very legalistic culture. They're just starting to form multidisciplinary teams. This is fascinating. We shouldn't take the progress UK local and central government departments have come in their digital journey. I wish Germany good luck!
Sam made a point of encouraging new starters on existing teams to challenge the language they come across. Empower people to value the power of questions.
Kaz asked if the next step for multidisciplinary teams is outside of digital. This would be awesome, although who knows, this might already happen across MoJ. Digital definitely doesn't own this way of working. Indeed, when you Google "multidisciplinary team" results cluster around healthcare professionals working together to help patients.
What continues to be hard?
Understanding commercial routes to get people in. So complicated and constant source of frustration.
Increasing confidence when migrating systems from on-prem to public cloud. The difficult thing here is lack of domain knowledge, and overcoming hurdles to improve QA capacity and capability.
Who else did you talk to?
I talked with Giulio and Toni about cycles of work, and in particular, the legislative timetable and fast-tracked legislation, and the impact it has on teams. We were recently asked by a senior person if we could move some people from one team to another piece of work. Tom DeMarco calls this the myth of the fungible resource in his book Slack. I completely agree with the idea of making organisations less efficient and more effective. Departments like mine are already driving up a steep hill with the weight of old technology. Increasing the incline of that hill without increasing the engine size is not going to get us anywhere faster. Expect stalling to occur and slides back down the hill! (Remember, these are my thoughts, not anyone elses). Janet's blog post goes into aligning cycles, people and goals. Having a vision and set of guiding principles keeps us aligned, yet having no slack in the system deviates from this. A good strategy will identify the key challenges to overcome and the cycles and sources of work are challenges unless we can simply say no to lots of things. Another Justice Services panel session I watched was about innovation. Time to think and experiment is a key ingredient to innovation. And innovation is key to the long term health of an organisation. Slack (the book) represents operational capacity sacrificed for the interests of long-term health. Slack in the system also allows for maintainance and sustainable ways of working. And all this is linked to mental wellbeing.
Did you watch / listen / read anything helpful?
Spoilt a good walk by listening to the Integration challenges in an ERP-heavy world. And part 2. The problem they open with is digital technology is a major source of revenue these days. ERP processes are notoriously difficult to upgrade, incrementally change, putting "a fairly large technological albatross around an organisation's neck whilst teams try to chase digital opportunities". Mmm, sounds very familiar. Questions pondered: Where does an ERP system end and external new capabilities begin? Should an ERP remain the system of record? What are some guiding principles behind abstractions to the ERP? What are the modes of integration? How can teams be organised? What about the impedance mismatch of architectural patterns like REST and events, how do they work with batch-oriented or request-response patterns? What tooling is worth building? When is the right time to move from on-prem to cloud? And I learnt a new term: data gravity. And this article on cloud escape velocity - switching cloud providers puts the term into good use, making me think of a a few LAA Digital services that have recently been migrated and they challenges they had to overcome.
Did you meet anyone new?
Yes. But sadly I have run out time! Trying to get better at timeboxing weeknotes.