In the second part of “Surprise-Driven Sharing (SDS)” I wrote about how surprising I find it when people say things like “Once we finish this final feature, we are done!” when talking about custom-developed software. However, sometimes they add something like: “Well, apart from some minor maintenance.” This too surprises me.

I think their perception of maintenance is upgrading some dependency once a year because of a security issue, and it is, of course, a good thing that they protect themselves in that regard. But what I find problematic – and surprising – is that they differentiate between initial development and maintenance. Especially if they have one team taking care of the initial development and another doing the maintenance.

Dog food and handovers

The first problem with this setup is that the first team will not “eat its own dog food”. That is, it will never know what was good in the long-term and what was problematic. Therefore, they will continue to make the same mistakes in the next project and the next and the next...

Another problem is the fact that handovers always bring overhead costs, knowledge loss, and time consumption. Typically this mindset is combined with batching up good ideas for a second version and getting another team on board to do most of the new development work. Again this brings overhead costs, knowledge loss, and time consumption. The reason is probably a haunt for efficiency but it comes at the loss of effectiveness (and efficiency).

I suggest a totally different viewpoint. Almost twenty years ago an old friend of mine suggested that it might be helpful to clarify how software development should be thought about. Rather than the common viewpoint of a project for version 1 and then getting rid of the team, he suggested talking about all development as maintenance. “Maintenance starts after the first commit”, he said.

Gardening model

At the first meeting with a prospective client 13 years ago, I suggested a model of “a gardener team” for developing an important piece of software. The gardeners (developers) have a certain amount of time set aside, like a constant minimum pace, which they always use to take care of the garden (software). Sometimes something new needs to be planted (a new feature) without any delay, sometimes there’s old compost to deal with. More or less every day weed is taken away. With the pace and quality given, all the discussions every day are about how value creation can be optimized for. The client told me that this model resonated with him; he was the son of a gardener. :)

As you noticed, I wrote “constant minimum pace”. Of course, the gardener team can grow temporarily at times of need, but the core team is always there and the ramping up and down is done stepwise and without big, abrupt changes. It’s also important to stress “minimum” here. Too much time will create challenges of its own.

Another thing I like about the model of a gardener team is that the best design ideas rarely come about on day one. Not even on day ten. But given time there might be a breakthrough thought, like an epiphany moment. An idea so obvious that you can’t understand how someone didn’t think of it until now. One that is helpful in many respects when put to use. The reason for this delay is that you needed to live in the real situation for a while to see and feel how it really was. Even if this idea somehow had come to you on that first day, you wouldn’t have been able to recognize it for what it was. It would simply have drowned in all the hundreds of ideas which, at that moment, seemed equally good.

In Kent Beck’s latest book Tidy First?, he explains that he learned early in his career that clients valued his work the most when he opened and upheld opportunities in the codebase. It wasn’t about implementing new functionality by speculation, it was about keeping things in good shape for being prepared to take care of the next unknown opportunity or need. Keeping a good balance between new features and new options is key.

Investments vs running costs

I once discussed the problem of viewing development and maintenance as two separate phases with the CIO of a traditional company. He neither agreed nor disagreed with me. Instead, he surprised me by saying they’d always done things that way and it would be impossible to change.

Maybe one reason for this separation is that companies differentiate between investments (initial development project, capex) and running costs (maintenance, opex). And running costs are considered bad by investors and shareholders. I would like to turn this around: Why on earth take the risk of a big investment when you have the option of transforming it into running costs which can be stopped or pivoted at short notice and have a brutal focus on delivering value early and often?

A helpful model?

I know that using metaphors to describe aspects of software development can be problematic. Metaphors are models and all models are wrong. But some are also helpful. I do think the metaphor of a gardening team can help describe how to deal with your most important software development – the one that gives you a competitive edge.

This article was originally published on LinkedIn. Join the discussion and read more here.

About the Series

Surprise-Driven Sharing (SDS) explores moments when established viewpoints are challenged, sparking reflection and learning. Read other parts of the series: