6 ms·
Is it more important to have perfectly tracked projects or projects which ship 20% faster? It's far more important to have perfectly tracked projects. A pe
by quanticle 4y ago
Is it more important to have perfectly tracked projects or projects which
ship 20% faster?
It's far more important to have perfectly tracked projects. A perfectly tracked project which is guaranteed to deliver on a particular day is gold. It makes planning for the rest of the organization much easier.
To use a programming analogy, it's like the difference between latency and jitter for real-time systems. Many real-time systems will happily sacrifice considerable amounts of average latency, in order to minimize jitter. It's far better to have a process that completes in 200 ms every single time than it is to have a process that completes in 2ms most of the time, but, occasionally takes 2000ms.
Similarly, from a managerial perspective, it's far better to have a team that gives you good visibility, allowing you to plan for a completion date (even if that date is farther into the future than you'd like) than it is to have a team that mostly finishes projects quickly, but occasionally bogs down and takes a year to finish a project that was initially estimated at two months.
The problem is that far too many organizations have neither. They don't have visibility, and they finish projects late. For these organizations, your dichotomy is a false one — better tracking is how they will ship faster.
- ethbr0 4y ago> better tracking is how they will ship faster There's a reason PMs are reviled to mildly tolerated by engineers: they believe the map is the end product, not the territory. The correct answer to which is more important is "It depends." There are many businesses where shipping 20% later leads to ceding first mover advantage and losing the game. Largely what's being discussed in the article. More detailed and accurate project tracking and projection doesn't deliver quicker shipping. Effectively prioritizing outstanding work does. They're similar but definitely not the same.
- quanticle 4y agoThere are many businesses where shipping 20% later leads to ceding first mover advantage and losing the game. Are there? Can you name some examples? Because when I think of technology, first-mover advantage counts for very little. The first successful web browser wasn't NCSA Mosaic. It was Netscape. The first successful portable music player wasn't the Nomad, it was the iPod. The Macintosh long predated Windows, but Windows has by far the larger market share. Same with iOS and Android. Google was far from the first search engine. Facebook was far from the first social network. Amazon didn't invent e-commerce. In automobiles, Ford was first to mass production, but it was overtaken by General Motors by the 1930s, and they both were in serious trouble when the Japanese auto manufacturers, which didn't even really get going until after World War 2, arrived. So in which business exactly does shipping 20% later lead to "losing the game"? If anything, the real risk is in shipping a half-baked product too soon.
- ethbr0 4y agoAdSense, Amazon, Apple II / iPod / iPhone / iWatch, CNN, JavaScript, Netscape, Netflix, PayPal, Roku The critical window isn't when something is first possible (e.g. when the first product appears), but when the combination of technical abilities, component price points, and market characteristics intersect to permit success. To use a physical example, the iPod and iPhone were great products, but they were hits because they launched with the features they did, at a specific point in time, at a specific price point. We know that potential for success infection point existed then, because they did build a working device and achieved success. Consequently, if they had not completed those devices when they did (say, +20% time), another device could have achieved their success. Maybe nobody on the planet existed other than Apple who could do it... but the possibility was provably there. Or in simpler form: Netflix was far from the first streaming video service. They were the one who launched with the right features at the right time. Nobody cares if you catch a small wave perfectly. What matters is catching the best wave of the day, in the brief window you have.
- quanticle 4y agoThe reason all those examples you cite became as successful as they did is because they spent that extra 20% to get it right. They didn't just ship some MVP out the door. They spent a huge amount of time and energy to get the product as close to perfect as they could before shipping. Steve Jobs, famously, became concerned about the aesthetics of the traces of the circuit board on the original Macintosh [1], spending $5000 (16,330 in 2023 dollars) and a couple of weeks, to have a circuit board created with better aesthetics. Then they threw that board away because, it turned out that aesthetic traces don't actually correspond to good signal propagation. That's the reason that Apple, especially, has been so successful. It's not because they launched at some perfect time window. It's because they launched damn good products. If the iPhone had launched in 2008, or even 2009, it would have been just as successful. We just would have had another two years of mediocre Windows Mobile/Symbian OS/Blackberry devices. [1]: https://www.folklore.org/StoryView.py?project=Macintosh&story=PC_Board_Esthetics.txt https://www.folklore.org/StoryView.py?project=Macintosh&stor...
- 4y ago
- robertlagrant 4y ago> More detailed and accurate project tracking and projection doesn't deliver quicker shipping. Effectively prioritizing outstanding work does. This is it. With the advent of broad, powerful tools you can use to automate off your codebase, there's less and less manual rote work that needs tracking, and a greater and greater percentage of creative, hard to estimate, engineer-driven work. And the best way forward is to plan releases with certain features, and flexible timelines, or plan releases with fixed timelines, and flexible features.
- marcosdumay 4y agoTracking does not guarantee anything. Tracking only tells you have missed the release after all of your plan is already destroyed. You seem to want estimation. And you will keep doing exactly that, "wanting", because estimation isn't something that scales to big projects or multiple ones.
- quanticle 4y agoWe're not special [1]. Programming isn't that different from other engineering disciplines. The difference is that, somehow, programmers have developed this anti-intellectual attitude that keeps them from doing the hard work needed to develop the estimation tools that other engineering disciplines take for granted. Step one in developing those tools is tracking. [1]: https://www.hillelwayne.com/post/we-are-not-special/ https://www.hillelwayne.com/post/we-are-not-special/
- humanrebar 4y agoMajor infrastucture and other construction projects are behind schedule and over budget constantly. So I guess I agree that software isn't that special, but I'm a different direction.
- cageface 4y agoWe are special in that nobody wants to spend the time to spec software in detail up front and we usually make major changes to requirements in the middle of the process. If we had something like a detailed blueprint before writing a line of code and the requirements were set in stone we could get a lot closer to other engineering disciplines in terms of predictability. With the kinds of planning and estimating processes we do actually use you’re lucky to get within a factor of two of reality.
- ethbr0 4y agoThe way I've heard it phrased is "If the physical properties of concrete changed every two years, civil engineering would look a lot different." (forget the source)
- wpietri 4y ago> A perfectly tracked project which is guaranteed to deliver on a particular day is gold. It makes planning for the rest of the organization much easier. This is such a good example of prioritizing internal desires over customer needs. > better tracking is how they will ship faster My long experience is that heavy tracking is strongly correlated with slower shipping. Because tracking is treated as a substitute for actual domain competence.