You start to build something new, and it feels great
Perhaps you know the feeling? A team begins to build a new product. The technology stack is selected, and coding begins. You set up spaces where you will code and ship into. Soon you are flying. Writing good code and good features is never easy but work rolls out fine: predictable, with low friction. Changes and enhancements dropping into the spaces you’ve curated.
It feels like beginning a game of Tetris. You have lots of space and time to work out where to place your shape. There’s room for errors and corrections. You could keep doing this all day.
Things change, and not for the better
A few months later something shifts. Change is no longer easy. Things don’t fit anymore. You're walking through syrup.
The team’s time is taken up with juggling the management of what you have. Adding new things to your product in a reasonable timescale is a constant challenge. There’s always a time sync or a reason why a desired feature is much tougher than it should be.
You are no longer playing Tetris on easy; dropping in blocks and clearing the board. The Tetris game board is almost full, and it takes all your attention to find space to keep the game going.
How do we get here?
Software don’t come for free
New work appears when shifting from fresh green fields to supporting and maintaining a live product. But often the friction in additional development grows well beyond that, and optimising the product and business for the support needed for a live product is not enough (though an interesting topic for another day).
We don’t write all our own software. We use 3rd party and open-source libraries, and that helps us go fast. However, we should also acknowledge that this does not come for free. These libraries get updates, bug fixes, and security patches. Engineering teams need to stay on top of this and ensure that their software is built on good and trustable foundations. This takes time and thought.
Further development friction is the fault of the future
Those two areas are not the complete picture, not by a long shot. There are a broad range of contributors that cause development friction, but what it boils down to change. Change is hard.
What we have built is likely unsuitable to solve the next, new, problem. How could we have known where we would end up when we started?
It can be that the good code we need is surrounded by cruft. Things we don’t need that get in the way. Bets and debt - produced by time-to-market pressures and experiments. We often build more than we need, either accidentally or to discover what we need to know.
Success can bring complications. Maintenance of a growing changing system in a growing changing organisation is hard and needs commitment, focus and time. We also might not be able to see that what we own and maintain is slowing us down, maybe we need to remove more than the cruft. That conversation can be very hard to have. We often love what we have built and see sunk costs as a commitment to a route.
Ways out
In my next post, I’ll break down the friction agents into some grouping that can help us navigate our way through the drag, but there are a few broad areas we can think about before we use a model.
Predict and protect
We can certainly work to predict what’s going to happen and try to prevent its worst effects. Can we build less software when we are at the learning stages, or keep it malleable to adjustment or removal?
Communicate and collaborate
A ‘No’ often offends. After all, if everything has been going well, and then it all slows down, what’s to blame? Expectations have been set, and maybe commitments have been made?
I wonder sometimes what folks are hearing when I explain we need to go slower. They look surprised, and sometimes disappointed. Are they worrying that the engineers are getting lazy or bored? Do they now see us as a problem or a blocker rather than a team that solves things?
I think it’s important that we not only know the game we are playing but that we get ahead of the game. Stop being damned optimists and expect the levels to get more complex. We should ensure we are communicating and collaborating with our fellow decision-makers to set expectations and make choices together. We are all placing bets and adjusting as we learn. ‘No’s may have to be delivered, but it shouldn’t come as a surprise.
Modern software development is progressive, not magic
Software is flexible and malleable, but not infinitely, at reasonable costs. Sure, Agile Delivery is iterative and incremental, but at its heart, it's about reacting to what we learn in the most valuable and useful ways. we need to design and then re-design as we gain new information. And we need to keep talking about that.
