Continuity Applied to software development processes

5 min read

It wasn't long ago that I became a tech lead for the first time in my career, and right after, I was also considered a Staff engineer. That changed everything, from the person deep into coding (still cause I love it) to the person who represents the technical vision of a team and tries to move the group to a better place, technically speaking.

I find myself into future and process thinking more often than I was used to, long discussions with product and design teams, back and forth on ideas, POCs, and the most terrible thing every engineer hates, fighting and negotiating time to work on technical debt and improvements.

It has been interesting! I've learned a ton, and although it has not been that long in this position, I've been exposed to quite some tricky situations already and have been thinking a lot about long-term continuity. I think I can come up with a math formula to prove that long-term continuity can help with software development processes. Isn't this a master's thesis or something? Perhaps I should return to academic life.

The success cases and the hidden continuity processes

You might wonder, "Why is Diel talking about this now?" The most tricky situations I have been in are related to negotiating time, and if there is something I am obligated to agree with YouTube business coaches that time is finite, the most wanted and expensive resource.

So why do some areas have success and others don't? I can't simply accept it is only because they have the time to focus. Let's be honest; many mistakes are made along the way, even when focusing full-time on something, which can be translated to "lost time," and we lost a lot of time. Time is essential, but not the only success factor to take in.

You know where my hunting is, hence the article title. Continuity applied on top of time is a success factor. Take a quick look around you:

Try it yourself:

{The desired action is successful}, because of a process of continuing doing {desired action}

The boring continuity graph and its surprising side effects

Desmond Tutu wisely said, "There is only one way to eat an elephant: a bite at a time." He meant that everything that seems daunting, overwhelming, or even impossible can be accomplished gradually by taking on a little at a time.

A little at a time... continuity.

We will always have big projects to work on, which is excellent. I would hate not to have any impactful or complex problems to work on, which usually translates to lots of work on many different fronts. How can we progress in multiple areas while keeping a good pace on delivering new features, UX/DX improvements, maintenance, fixing bugs, and more?

I'm not advocating having a team that focuses on all of this stuff at the same time, but to be critical and think about what can be parallelized, taking into account the team's capacity so that we can have continuous health progress on areas that will have a positive impact but would never be prioritized.

Your company won't go bank corrupt if the team takes three weeks more to deliver that big feature and yet fixes some bugs and improves DX along the way. But you can only start with people who believe you give them space to succeed and support a solid/healthy process.

Applying the continuity formula

Work that needs to get done Available/wanted Time

Let's suppose we have a migration work to get done, we would:

This list of actions gives us a very boring constant line:

linear graph

No one sees the side effect of that constant visual representation; we eat the elephant one bit at a time. The side effect is that you will start with lots of work to get done but also linearly decrease this number and get closer to the finish. Isn't this how everything works in software?

linear graph

The unmeasurable side effects

As with everything with humans involved, there will be some side effects that I like to call the unmeasurable ones; they are unmeasurable because we are talking about human feelings, motivations, and beliefs.

Think about this: if your team has been mentioning and asking to work on a long migration that has become a significant problem for the team's velocity and quality for years, this will directly affect the team's happiness and motivation. Not addressing big concerns/projects like that can drastically decrease the team's trust in the company's capacity to support a solid and healthy process.

Side effects also extend beyond productivity metrics. It can increase innovation and creative problem-solving by applying continuity and giving back time to teams since they are not spending all the time and energy trying to figure out how to eat the elephant.

Ultimately, we all have one goal: to ship with quality and faster.

Diel's avatar, the image contains a border that will be full when the scroll of the page is done