Why your digital restaurant needs a clean and well-maintained kitchen

Nick Rowlands — Wed, 07 Apr 2021 12:10:33 +0000

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.

Clean as you code. Make it part of your daily work.

Or neglect cleaning

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.

Build evolutionary architectures.

Or don't reorganise

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.

Further info

How to measure and improve line management for developers

Nick Rowlands — Sat, 16 Mar 2019 20:58:16 +0000

I was talking to two colleagues the other day about how to structure line management within teams of developers. One of them said they don't like the term line management as, for him, it comes with a bunch of negative connotations. I kind of agree. Maybe I'm thinking of management 1.0. I like the idea of management 3.0.

There are two operating modes to the line manager role, the coach (the default mode) and the traditional manager role, which deals with admin, conduct issues or disciplinary proceedings. I'm not convinced these roles can or should be carried out by the same person. But I'm new to managing so what do I know?

Improving line management across a department

One of my current objectives is to improve line management across the department I work in. In my view, the most important responsibility of a line manager is to look out for the welfare of the person, help them to succeed in their career and work through any issues that arise.

If I'm to improve line management, I must be able to measure it. What results should a line manager should be measured on? Through discussion with colleagues and reading around the topic, I've come up with these outcomes:

Team member feels safe to talk about anything (high trust & good rapport)
Line manager purposefully creates space to reflect, brainstorm and solve problems
Team member knows what's expected of them
Regularly talks about career development

I want to do a quick anonymous survey with everyone to get a baseline of where line management is currently. I need come up with a few questions. Maybe I can directly turn the above into yes/no questions to get a quick benchmark?

Once I have a baseline, what are things that we can do as a department to improve line management? Some of the ideas I've come up with are:

set a minimum frequency of one-to-ones (the Civil Service guidance is at least every 6 to 8 weeks. This is too infrequent to build rapport)
write down actions that come out of 1:1 to help with keep both people accountable
set objectives with agreed ways to measure success
every line manager goes on appropriate training (at work I've been on a High Quality Coaching Conversations workshop)
Regular feedback on performance as line manager from team member being line managed and their own line manager

We're in the "plan" stage of the plan-do-act-check method. I'm really keen to improve until we get good line management across the board, whatever "good" is.

An alternative take on one-to-ones

The colleague I mentioned earlier prefers the term "personal retrospective". This immediately makes sense to me as it makes me think of the retrospective ceremony practiced commonly in agile teams.

The definition of retrospective is:

Looking back on or dealing with past events or situations.

But in one-to-ones we must also look forward. A "futurespective" seems the obvious way to counter this. A common definition of a "futurespective" is:

An exercise helps agile teams to find ways to reach their goals, agree upon their way of working and define a Definition of Done.

Liz Keogh wrote How to run a Futurespective | Liz Keogh, lunivore where you "step forward into the future" and "look back at the past negatively" and "look back at the past positively" and "create actions" to work help achieve the positive events that are yet to come.

This could work.

DEV Community: Nick Rowlands