Software Development Speed vs. Quality: A Tech Shop Conundrum

Having worked as a software engineer in and out of Silicon Valley for several years, I’ve seen it all, from a mammoth sized multi-billion dollar transportation company, to a large struggling tech company, to a medium sized tech company growing up into a big one, to a tiny startup redefining an industry. Despite all of their differences, they all have one thing in common – an unspoken dilemma regarding software development speed vs. quality.

Like any craft, whether it’s woodworking, cooking, or software development, it’s impossible to achieve both quality and speed. This is why cheap furniture looks like crap, fast food is unhealthy, and hacked code is buggy. Despite a lack in quality, business models that optimize for speed can still be very lucrative because sometimes people need speed over quality.

Like any craft, whether it’s woodworking, cooking, or software development, it’s impossible to achieve both quality and speed.

In the world of software development, there is pressure to produce high quality code as fast as humanly possible. Features and products need to be built fast in order to fulfill contracts, get new deals, stay competitive, get more users, etc., all in the name of keeping a business alive. However, since it’s impossible to have both, as an organization or team you need to decide whether you’re going to slowly build a very high quality product, or quickly build a low quality product.

We can think of the two extremes as “modes”. A tech shop can either operate in a quality mode, a speed mode, or somewhere in the middle. A tech shop can never be in two modes at once.


So how do you know if you should operate in quality mode or speed mode? Interestingly, a healthy tech shop will have natural advocates for both extremes. It’s important to understand the perspectives for each of these advocates when deciding which mode to run on at any given time.

Advocates for Quality

In general, the advocates for quality are the people designing and building products, and of course QE and QA (quality engineers and quality assurance folks), of whom literally have quality in their job descriptions. Designers and engineers are by their very nature craftsmen and craftswomen. They are motivated to create amazing, beautiful things. If left to their own devices, they would spend months or years achieving perfection.  Advocates for quality define their success based mostly on the quality of the products that they produce.

Advocates for Speed

On the flip side, advocates for speed include executives, product managers, sales, and marketing folks. Just like everyone else, these parties would ideally like high quality polished products, but at the end of the day, they are driven by dates. Features and products need to be completed by a certain time or else it could cost the business lots and lots of dollars, or worse.  Advocates for speed define their success mostly on their ability to hit deadlines, grow the business, and generate revenue.

Natural Tendencies

It’s very common to see startups and smaller companies lean towards speed mode, i.e. move as fast as possible, while larger companies lean towards quality mode, i.e. move at a snail’s pace. This is because startups and smaller companies are doing everything in their power to be disruptive, which means moving fast at the expense of quality. Larger companies, in contrast, are already well established, and cannot afford to release low quality products. Therefore, larger companies typically have slower release cycles (on the order of a year or more).

It’s also typical to see micro level shifts from quality mode to speed mode within a single release schedule, whether at a startup or large company. This is because early on in a release schedule, designers and engineers are laying the foundation for a new feature or product, and are spending a lot of time making it great. Later on in a release schedule, advocates for speed (i.e. execs and product managers) will start to put pressure on the advocates for quality (designers and engineers) to get the feature or product done in time, at all costs.

Origins of Conflict

As an organization or team, one thing that you don’t want to happen, which I’ve actually seen quite often at all points in my career, is to have some team members working in quality mode, while other team members are working in speed mode.

Amongst engineers, this is problematic when certain individuals are producing more features with lower quality, while other engineers are producing fewer features with higher quality. This is a problem because it can drive a wedge between the two groups of engineers. The former engineers will feel that the latter engineers aren’t moving fast enough, and the latter engineers will feel that the former engineers are producing poor code riddled with technical debt.

Alternatively, if engineers are operating in quality mode, and product managers are expecting features to be delivered faster, tensions may arise because the product managers will feel that their deadlines are at risk. The engineers may feel like they are unfairly being asked to produce lower quality work for the sake of speed when they had expectations of producing higher quality work.

As an organization or team, one thing that you don’t want to happen is to have some team members working in quality mode, while other team members are working in speed mode.

Managing Expectations

As an organization or team, it’s important that everyone has the same expectations in regards to quality vs. speed. Make sure that everyone understands when you are operating in quality mode, and when you are operating in speed mode. Whenever the mode changes, i.e. optimizing more for speed over quality, or vice versa, make sure that everyone is on the same page. Managing these expectations will make release cycles go much smoother, and keep your advocates for quality and advocates for speed much happier.

Plan B: Reducing Scope

In addition to software development speed and quality, a third dimension that may be considered is scope.  Scope refers to the total set of features and UX polish that makes up the thing that you’re building.  Sometimes, towards the end of a release cycle, you might have to sacrifice scope in order to hit deadlines while still maintaining a high quality product.  Some examples of reducing scope are cutting out fancy transitions and animations, dropping support for older browsers, or living with performance problems.


Eric Rowell

Hi there, my name's Eric Rowell. I'm the founder of Coder Lifestyle, founder of Html5CanvasTutorials, the creator of the KineticJS library, author of HTML5 Canvas Cookbook, and the creator of BigOCheatSheet. I've worked in the Tech industry for about five years while at Yahoo, LinkedIn, and Platfora, and I've also worked in the Transportation industry for two years while at BNSF Railway. I'm currently leading the data visualization efforts at Platfora.

  • Tomasz Rydzyński

    Hi there! Thanks for those thoughts. Good point about aligning the mode of everyone and changing it depending on the present needs.

    I have a question but first let me prove you a little :)

    Since you’ve put speed and quality on the same axis, I guess you’re following the line of thought where many other things, for the sake of argument, are constant. For example that there is a certain amount of skill available and it can be used either to deliver many things fast, or fever things with a greater quality.

    In my opinion, organizations thinking merely about speed vs quality don’t understand the problem.
    Likely it is possible to increase both speed and quality. I have not seen a place on earth where all contributing factors are maximized. And only if they were, you would need to sacrifice one for the other.

    This speed vs quality simplification is true, to some extent, but only if we’re talking about a present situation. Let’s say you have one man and ask him to find a nice stick right now. Obviously, the longer he looks for it, the higher the chance for a nicer stick. Speed vs quality indeed.

    However, organizations last in time, and as it passes, things change. A mindful company can steer these changes in a proper direction. There are tons of things involved, like rearranging people’s tasks, hiring, motivation, good and bad time investment (frameworks or technical debt), proper planning, company’s mission, and so on.

    So, what’s your take on that? Which factors would you list as the most important to address first, to get closer to the speed vs quality line? In other words, what you’ve seen as the main blockers on an organization’s path to shipping faster AND better?

    • ericdrowell

      @tomaszrydzyski:disqus you’re right, there are certainly factors to consider other than quality and speed, such as scope, number of resources, skill level, team dynamcis, variable deadlines, shifts in priority, etc. And you’re right, this article is assuming that all of these other variables are constant. Amongst all of these variables, the speed vs quality relationship seems to be a universal struggle in all situations regarding software development, so I chose to focus on that particular relationship rather than trying to formulate relationships between all of these variables simultaneously, and make this article virtually impossible to comprehend.


    Hi there Advisor at and CX Insights Leader for that billion dollar technology company you’ve never heard of! TE Connectivity. I would say the graph of the Speed vs Quality curve is great but can be better. Large companies like ours likely also have extremely robust and matrixed (adds another layer of sophistication to my situation) sales and marketing teams where revenue gen is a top priority. So my Data Science team has traditionally prioritized speed over quality. I’m designing our strategy so that we revisit where we stand and I’m telling the business look, we need to decide what we want. Is it speed or quality? If we want quality (predictive and prescriptive analytics) we have 3 options, we either add headcount to focus on taking the high impact reports we need and taking it to the next level 2. we level set with the business and flat out say hey we need to take more time building solutions (not going to fly) or 3. we make process improvements to gain capacity. We’re doing a combination of 1 and 3. adding headcount (to accommodate volume from a BU who just recently invested in us) AND ALSO identify the low value add transactional activities sucking up our capacity and in agile way so we don’t disrupt the business- we introduce continuous improvement initiatives across people process technology that make incremental capacity gains to create bandwidth so we can focus on quality. It’s very exciting and happy to connect with leaders pounding their heads over the same challenges. Thanks for the great post!