EN 24: There is always something to do

Top of the morning to you!

Next week’s the last one before starting my new role. It’s feels like going back to school after the summer holidays.

This week, we start with two awesome articles and a talk by Trond Hjorteland from the NewCrafts Paris 2023 conference:

• A Startup doesn't have to Grow into Product & Engineering

• The endpoint of Web Environment Integrity is a closed Web

• Thriving in complexity talk by Trond Hjorteland

The first article, written by Sriram Narayan is quite similar to my thoughts about startups, the importance of hiring and Conway’s Law. I highly recommend the second article, if only to read about the history of the Internet. If you’ve been following the newsletter from the beginning, you might’ve seen me mention Trond and sharing some of his stuff about sociotechnical systems, and his talk is equally good.

Let’s jump to the topic of the day.

A curious phenomenon happens when the team backlog starts to get rather empty. Drops of sweat begin to flow down the product manager’s face. Like a kettle about to whistle, the tension rises. In a few days, after the developers have gobbled down all the tickets, there will be trouble: the engineers won’t have anything to do!

Without tickets, the team will be lost in the world, without a goal or objective to write the next line of code. The idle developers are just money down the drain. The machine can’t stop, the show must go on. Finally, the product manager, or in other companies, the product owner, hurriedly comes up with the next big feature. If there’s no such feature yet, maybe a small one, or some business as usual work, a few bug fixes, anything to keep developers busy and utilised. At some point, the refinement meeting happens, and we have 10 more tickets to go, fully spec’d out, crisis averted! The clickety-clack coming from the relentless machinery, moving forward by eating tickets and producing code is a sweet lullaby, everything’s fine.

The thing is, there’s always something to do. Leave a developer alone with no tickets to do and, more often than not, they will find something to improve. Perhaps there’s friction in the pipeline that won’t allow them to push code to production quickly, or tech debt to pay since it’s getting out of control and slowing them down, a much-needed update to old libraries…

There’s always something to improve and little time to do it. The more we delay the improvements, the more it accrues over time. This is the concept of tech debt anyway (or very similar), we take debt now to invest and grow, with the assumption that we’ll pay it later after reaping the benefits of the investment. I also like to think of it as entropy, or as “if you’re not getting better, you’re getting worse”.

Idle time, in fact, is critical. Without it, teams spend all their time focusing on features, leaving all improvements for later. Idle time also allows us to reflect, imagine, ponder about our situation, it gives us space to be creative and learn, to put our focus on the pain or friction we’re feeling. We have to have slack in the system to be able to adapt to change, an always tensed muscle can’t be nimble.

I wonder what would happen if we were to embrace doing “nothing”, just for a bit, and resist the impulse of filling our backlog. In psychology, there’s this thing about emotions, if we hide or run away from them, they just get bigger and in our face. Ideally, we would embrace them, feel them and learn from them, even though it might be uncomfortable. Instead of constantly filling our days with features to make developers always busy in the name of efficiency, let’s stop, be with it and see what happens, with no rush to create work just for the sake of work.

Busyness is one of the main maladies of our profession and in life. Companies, teams, and individuals tend to judge their productivity by how busy they are, the more swamped they are, with no respite, the better. Busyness comes from trying to maximize efficiency by increasing the utilization of workers and running work in parallel. It seems intuitive, the more work we have in progress, the more we can get done in the same unit of time. But it doesn’t really work that way.

Occasionally when I’ve discussed introducing slack in the system, it tends to go in the direction of allotting a percentage of time for improvements, most famously: “20% of the time to work on improvements”. 20% of the time is about a day a week. This percentage might be enough for a good team with no major problems to keep on top of things, but for a team deep underwater, it’s not even scratching the surface.

If we want to have slack in the system by having a percentage of the time dedicated to learning or improvements, it needs to be in relation to the state of the application and how much friction there is. A team that doesn’t dedicate any time to learn and improve the system and itself, will be forced to stop to a halt, since a small change will take weeks, months, or years. At that time, there’s no 20% that’ll save you, it could be 100% or close to it.

At the same time, and while I’m a big fan of carving out a space for improvement and learning, it’s not an excuse to avoid doing continuous improvement as we code. One of the most important parts of being a professional software engineer in the industry is to create systems that are able to change as business demands and market/environmental forces change. It’s a business advantage to be able to pivot or evolve as demands change, and that’s our responsibility. This means that we should be continuously improving the code and the architecture, adding tests, refactoring, remodelling the domain as we learn… And to achieve that, there has to be slack in the system.