The Slow Effects of Moving Too Fast

Photo by Christian EM on Unsplash

Developing a product is a balancing act in trying to get the best product you can as quickly as you can. There’s a constant push and pull between management and development in needing more and needing it faster at the same time. To an extent, this is a healthy balance. Many engineers I’ve worked with need a little push to ensure they’re not overthinking a solution, and managers need the reality check a good team will give them when they ask for too much.

The common argument that’s difficult for anyone not on a software team to understand, though, is how going too fast results in slowing down progress. You will often hear engineers use terms like mounting “technical debt” or needing to “refactor” something somewhere because they were forced to go too quickly. If you’re not a developer, however, and you’re not deeply connected with software, those terms mean nothing and are difficult to quantify.

So how could developing too fast slow a team down? Let’s take some common scenarios.

Scenario 1: We have a deadline that we did not properly estimate and are in danger of missing.

In this situation, a development team either initially agreed to, or was simply arbitrarily given a deadline to deliver something they did not completely understand. Because they didn’t estimate the scope of the deliverable properly, as the deadline gets closer, the number of items to complete does not shrink in proportion, because new items are added to the todo list as quickly as you complete them. In this case a dedicated team kills themselves to get everything they need to get done, but they also sacrifice many things in their journey to get there.

The deadline comes and the team triumphs over their challenge. The deliverable is just barely met. Over the next few months, however, the team starts discovering a few things happening:

1. They missed some key items that fell through the cracks. These are typically important items that aren’t high-visibility as part of the deliverable, so it was easy to push them off for a bit and then forget about them. Someone, though, eventually remembers it and realizes it still needs to be done.
2. The work that was done and completed is buggy and unreliable. We got the delivery out the window, WOOT! But now, we are going to spend an eternity trying to get our product to meet a standard we’re proud to call our own.

These two items are the principle driving forces behind the biggest cost of moving too fast:

You are now prevented from making substantial progress in the near (or even far) future due to the cleanup you have to do.

What’s this cleanup look like? Fixing bugs that should not have been introduced or hurriedly completing features you did not know you missed are two examples. These are just two examples of what an engineer would mean when they say “technical debt”. The team is now so busy making sure the ship they built and launched floats, that they don’t have the time to add all the new, essential, features to that boat to make it worth sailing. Since every day they realize that there’s a new leak to be plugged, or an essential element missing (like a rudder), there’s no time to put in a larger sail, navigation system, or an awesome new rainbow colored sail. (Please pardon my ignorance of boats…)

This is a common problem in software, and one that’s been written about so much that I’m just repeating common knowledge in all the above. Recently though, I’ve seen this happen on my teams in a much smaller scale, and it results in a proportionally sized slowdown effect in these cases as well.

Scenario 2: Development of a feature takes longer than expected.

At first glance, this may not sound like a problem with going too fast, but I’m going to argue it is. Here’s the scenario:

Jim, one of your best developers has started developing a new feature that’s well scoped, documented, and straightforward to architect. Original estimations thought that this task would take around a week of development, but Jim finds that after a day, he’s done! He proudly writes up his accomplishments and starts working with QA to ensure it meets the standards of the feature, as outlined by management.

Working on the same thing day in and day out fixing it over and over again does not feel like progress, even if you are closer to your goal.

Unfortunately, over the next week, Jim finds that QA has found dozens of small and large problems with the work Jim produced. Part of it was Jim not completely understanding the full scope of what he developed, part of it is that some things were simply missed as a part of his development. In either case, Jim and the rest of the team starts getting frustrated because it seems they can’t get this single task off their plate. Working on the same thing day in and day out fixing it over and over again does not feel like progress, even if you are closer to your goal.

After a while, Jim starts trying to just get the task done. The quality that normally is required for features is starting to take a lower priority than simply not having that same thing to do. QA now feels pressured to lower their standards and approve the feature, just to have Jim off their backs. On top of all of that, the manager driving delivery of the feature is asking for constant updates on its status, making it even harder to ask for patience.

Now, a good team with a good product owner, solid team members (both in development and QA) will encourage Jim to take his time and do it right. But many more teams than good ones (and even good ones that are pressured enough) will finally cave and release the product getting a single approval from QA.

The result of this will almost inevitably be that Jim finds he missed a ton of things even after that week of work, all because he originally thought it would be done fast and it ended up being a slower process. Slower delivery does not mean the process or result was worse, it means that the feature was not well understood. Over time I’ve realized that it’s not just better to take some time to fix this misunderstanding, it’s essential to avoid slowing your future progress down.

Slower delivery does not mean the process or result was worse, it means that the feature was not well understood.

Moving too fast often does not have an immediate negative effect, so sometimes its easy to miss the cause and effect of a rushed delivery to the slow progress afterwards. Rushing to meet deadlines or get something out the door will always have a negative impact. Sometimes it’s worth the risk, sometimes it’s not. The worst thing you can do is to ignore that there is risk in play, and instead celebrate a quick win that ultimately harms your product and team.

My goal in writing some of these thoughts is not to encourage anyone to move slowly or even to educate on how you prevent this on a team or in an organization (though perhaps I will write on that in the future). Instead, my goal here is to identify some concrete, practical negative effects that moving too fast on large or small projects can have to the overall health and progress of a product.