Quality Control in an Uncontrollable World
In my time at Ministry of Velocity, I’ve run across several Companies of a Certain Size who do a very peculiar dance in opposition to modern software development practices. They’ll produce lots of charts, reports, and time estimates. You know the kind.
If you ask around, the issue isn’t merely an annoyance. People seem to know they’re junk. Folks that receive these reports don’t trust them, and the middle managers producing them know they’re only a ritual.
When the commitments and lines and charts and time/money estimates turn out to be garbage, everyone involved goes through a second kind of dance: several meetings of disappointment and confusion. Maybe even a firing. How dramatic!
Here’s the part that drives me up a wall: everyone involved goes through the same steps the very next day. Management might expect that, once the Bad Actors have been scolded or fired, the results will be Different This Time. Developers might nervously agree amongst themselves to pad their estimates.
The cynic in me wants to say that this is a vicious cycle driven by an industry-specific drive to troll each other. But good people do this dance, too.
So what do these companies actually think they’re doing, and what should they do instead?
Don’t Worry, It’ll Work at Scale
Companies of a Certain Size take a certain pride in operating like factories. That’s not a statistically unlikely starting point, given that it’s the most common production model on the planet.
I don’t know much about factories, but they’re ubiquitous, and I’m feeling punchy. Let’s arbitrarily say that there are five roles, all of which we already talk about in software: Customer, Product Manager, Project Manager, Worker, and Quality Control.
Workers or Customers are a known commodity in the factory. Product Management is a kind of meta-ownership role, a proxy for Customer desires. It’s both useful and difficult. We like it, we know it, and Steve Jobs kicked ass at it. So let’s examine the rest.
Imagine a factory that’s been asked to produce a brand of jeans for next year’s spring season.
You Can’t Rush Art
Our Product Management role has already determined the size of the market, asked fashion buyers what their preferred styles and cuts will be, worked with sales to determine price points, and allocated a manufacturing budget on a line of credit.
Now our Project Management role steps up. Project, not Product. There’s a difference. Where a Product Manager might have a high-level view of the tasks at hand, the Project Manager has a more granular view.
Here’s an example of what a Project Manager would design at a factory:
Project Management is responsible for timetables, parallelizing workstations, staffing the factory floor, and making sure that the project comes in on time. Every stage and duration in the assembly line is planned by Project Management, down to how many seconds each pair of jeans spends in the sandblaster. Each machine in the assembly line is as replaceable as its worker.
Project Management is obsessed with time and money, and reports upward to the Product Manager. Workers report upward to the Project Manager. It’s a middle management role in factory, but as we saw in the video, there’s definitely an opportunity for the abstraction to be a helpful one.
For a sufficiently complex factory, knowing the impact of changes on Worker output is only knowable after the fact. The Project Manager has a simple tool for this measurement: a stopwatch. You lean over the railing, time how long it takes for someone to cut denim, then multiply. Projections are equally straightforward, and we can totally understand where a Gantt chart would be an emergent innovation.
So, what are we waiting for? Let’s just take these tools and put them in software land, right? If only.
Less is More
When the Project Manager makes changes to the assembly line, that change is done with a high level of confidence. Parallelizing workstations, changing their order, replacing a workstation with automation, or moving workers around the floor: these changes have physical manifestations, and directly measurable consequences on productivity.
However, in the software world, changes made by a developer may have far-reaching consequences, and the manifestations of those consequences are more complex than a physical change. Measurability suffers, as does confidence.
By asking for estimates and promises, then punishing humans for systemic complexity, the Project Manager’s role goes beyond obnoxious middle management. The role simply doesn’t apply.
It’s as appropriate as having Gordon Ramsay along for the ride. Actually, he might just instruct everyone to go talk to our customers directly, and where’s the fun in that?
Inspector 47 Thinks Your Pants are On Fleek
You might notice Quality Control long after they’ve done their job. QC leaves those little circle stickers behind for you find when you’re washing your jeans. It’s a physical job, driven by comparing a physical artifact to blueprints, specifications, and documented behavior.
If that comparison fails, QC sends those jeans to the incinerator. If the comparison succeeds, QC dispatches the jeans to Nordstrom Rack. Quality Control functions like a gate, because once those jeans are off the factory floor, there’s no getting them back. The most value QC can provide is to slow down economic output in defense of the brand.
Sound familiar?
Long ago, back when Jessica Alba was in ABC Afterschool Specials, software development shipped their product on CD-ROMs and floppy disks. Once those physical artifacts left the floor, there was no getting them back.
Times have changed. Jessica Alba is now a billionaire business owner. We don’t ship floppies anymore. In the eyes of younger, less honor-bound startups, we can sling code as fast as we want, wherever we want it. (Okay, fine, except for production; we’d need continuous integration and an acceptance process with our Product Manager for that.)
Regardless of its destination, Quality Control gates product releases at a most software companies. Those gates look like bug reports and code freezes, and the lower the confidence in the engineering team, the more those gates slam shut.
Code checks in, but it doesn’t check out.
The Quality Control Roach Motel
Slowing down economic output for a software team will kill it dead, faster than buying fancy waters or company sweatshirts, so what’s to be done?
The term “bug” comes to us from the world of hardware, where wayward insects regularly exploded inside minivan-sized blocks of metal and wire. Given that these blocks of metal and wire took years to build and launched various missiles, bugs are considered bad.
The term “bug” didn’t come from our brave new century: rapidly deployed web applications running on cargo containers full of CPUs. In fact, your rented VMs probably hum along happily next to a few thousand cockroaches.
Rather, in the world of software, our “bugs” are logical errors resulting from poor understanding about behavior, either ideal or actual, in isolation or when software is integrated.
In software, our first line of defense should be automation to detect that class of problems, with our last resort being constant human attention. If our first and only tool is staring really hard at a screen, finding an improperly-written line of code is biologically difficult for humans. Some of the biggest logical errors look totally reasonable in context.
Instead, rushed implementation, confusing business rules, or poor collaboration have caused a logical fault. My friend Elizabeth Hendrickson describes these deficiencies as discoverable by exploration. That rings true, and makes a great case for a simpler, explorable, usable product design as well.
Our model for Quality Control must become that, no matter where we’re coming from.
Dead Moths Don’t Fly in the Cloud
In our new world, we still produce reports of errors, because we want to eliminate them early and often. The responsibility for gating releases, previously held by Quality Control, is distributed appropriately.
Product Management work to simplify business rules, and to accept the final deliverable as being in concordance with those rules. Developers collaborate amongst each other to identify complexity, simplify the implementation of business rules, and automate the testing of the expected behavior. Finally, Product Management and Developers must collaborate to prioritize technical cleanup, so that rushed implementations don’t slow down development of the product in the long run.
Where Quality Control previously evaluated software and prevented user value from being delivered, with automation and an exploratory model, QC is freed up to improve quality.
Factoring Out the Factory
So we’ve removed two roles from the factory. Does that invalidate the whole model? Surely we can imagine a minimalistic factory with a single Product Manager and hundreds of Workers.
But we wouldn’t want to. That place would be a mess. The ideal team size is 4–6 people working on a single-purpose application, constantly focusing their energies on user needs while automatically ensuring the success of their old work.
The real secret here is that collaboration doesn’t require manual coordination, and that’s what sets software apart from the factory. Coordination can be as simple as a todo list with a state machine, like Github Issues or Pivotal Tracker.
Productivity doesn’t always look like a factory floor with neatly-stacked bolts of denim, rows of sewing machines, and identical smocks for everyone.
Productivity and collaboration at a modern software company looks exactly like working with your colleagues, knowing that everyone’s role is important, and feeling confident that everyone is responsible for the success of the company.
On the same note, hiding sales or business operations from developers, and vice versa, is a poor idea. For so many startups, that trifecta is the actual business. Bedrooms, garages, and coworking spaces have cranked out great teams for generations. Transparency and proximity didn’t kill them.
Is your team too big for that collaboration to happen? Consider reducing its size or dividing into different business units. Have a difficult team member? Nip it in the bud by either resolving those conflicts or parting ways.
At the end of the day, being at the right place at the right time determines wins and losses.
Ditch the factory model.
Be at the right place, right now.
At Ministry of Velocity, we help our partners compare newer and older models of software development. We value transparency, focus, collaboration, and empathy.
