I’ve been around the block and shipped a lot of software. I’ve worked at tech companies ranging from three to 10,000+ employees. I’ve built software that’s been given away for free and sold for $50M license fees — and just about every price point in between. Every one of these products was developed and delivered differently, and after having the chance to compare and contrast them all, I’d love to reveal the one true way to ship software.
I’m abashed to confess that I cannot.
I’ve discovered and rediscovered the “right” way to build and ship software many times. I’ve found near-religious zeal for certain practices (say, precise coding estimates, thoroughly detailed specs or UI design via A/B test) only to find the magic gone when I tried to apply it to some other product.
In a profession where we carry out decade-spanning holy wars over tab widths and capitalization, it’s no surprise that people get attached to their development and release habits. But if shipping so much software has taught me one thing, it’s to be an agnostic.
Different methodologies optimize for different goals, and all of them have downsides. If you maximize for schedule predictability, you’ll lose on engineer productivity (as this turns out to be a classic time/space tradeoff). Even when you aren’t dealing with textbook tradeoffs, all investments of effort trade against something else you could be spending the time on, whether it’s building an automated test suite or triaging bugs.
My fellow engineers, please stop asking “Is this process good or bad?” and start asking “Is it well-suited to my situation?”
Jocelyn Goldfein, a former engineering executive at Facebook and VMware, hits the nail on the head in this post.