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.
