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.
Tracking 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.
We'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.
We 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.
The 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)
I think we're outliers in a couple of ways. One is what you mention -- we're usually both the architects and the construction crews of our projects, and we do both parts at the same time.
But there's also a step back -- how long does it take you to fully design, but not program, a particular piece of software? If you give a general contractor a particular set of blueprints, he can tell you roughly how long it will take to build, both the ideal number (if there are no scheduling or shipping delays) and what it probably will end up being. But if you tell an architect you want a design for a particular size and purpose and style of building, she can also tell you roughly how long it will take to draw that up.
How long does it take to design a particular piece of software? What makes a design take a day or a month to iron out, well enough that you can get a correct estimate of the amount of time it will take to build it?
I don't think we're good at that, as a profession.
> I don't think we're good at that, as a profession.
We aren't. And, as an industry, we have managed to convince ourselves that's a good thing. Agile methodologies, after all, are an attempt at making such efforts unimportant.
Nope, that blogspam article misses the mark by a mile. The major difference in almost all software environments is that the software requirements constantly change, even after the initial version is done.
Estimates in civil engineering are going to look just as bad as software if it was common to keep adding floors of different sizes to a building after it was complete followed by a “pivot” of turning the building into a support structure for a suspension bridge.
Software that is as rigid as tradition engineering projects in the real world can certainly be estimated, this happens in safety critical stuff all of the time. But the estimates are long, and requirements cannot change without massive delays, which is terrible for most software use cases.
You realize that this sort of requirements change happens all the time in construction projects, right? Granted there are limits to this, but the vast majority of construction overruns are caused by changes in requirements.
It’s still a change before it’s done and it’s pretty constrained. Scope changes too big are just completely impossible because of physical constraints, lack of permits, etc.
The requirements changes in construction projects are child’s play compared to the ridiculous stuff in software. “Oh, now that we have this data visualization app finished, please add in support for collaborative visualization exploration with synchronized views and voice chat.”
Requirements change in non-software projects but rarely do they change the project into a completely different category like "I know we started building an office tower and it's halfway done, but now the client wants it to be an airport." This happens in software all the time.
Yup, in fact this is the strategy for profit maximisation for many, many construction companies. You look at the plans/requirements and if you spot loads of missing things you bid a low price with high prices for changes and make loads and loads of money.
Source: this is what my Dad did for a living, and I spent a couple of years doing it in my twenties.
It is also the strategy for profit maximisation for many, many software companies. "Change request" is a big deal in outsourced enterprise software dev. It is so bad that 'honest' software development groups that estimate accurately and don't have a culture of change requests cannot compete.
Major 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.
true, but the comparison to other engineering disciplines does not hold up well at all: while everybody understands that planning when building a House is important as once it stands you can only change it at significant cost this does not hold true to software development. here we press a button and the house is constructed and with CD even delivered to the customer.
my take: we ARE very special as our problems have not ever be encountered in the course of mankind due to the very nature of software.
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.
There 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.
But as a member of a small-ish company, I remember there was this time the sales VP insisted that we MUST have this product out by a certain tradeshow. Engineering worked hard and delivered, and although the thing had warts, it gave our company an advantage: the current market leader showed up at the next tradeshow a couple months later (e.g. "20%") with a similar product and price point, but our lead in time meant that we were able to exist as a strong competitor. This single product launch and subsequent sequels lifted our company for quite a long time.
So now when the sales guys insist we might need something by a certain date, I carefully evaluate rather than dismiss out of hand - I've learned to trust their role as well.
AdSense, 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.
The 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.
I think that's an oversimplification. The original Mac was a terrible computer. It was slow, it had too little memory, it overheated, it wasn't expandable, the keyboard was deliberately crippled by removing the arrow keys, it had a single button mouse, and it required almost endless floppy swapping.
The graphic UI and the case design were distinctive. But what really sold it was an incredibly sophisticated ad campaign that carpet bombed key media outlets with super-expensive exposure.
The problem with Symbian/Blackberry/Palm wasn't just mediocre technology, but a lack of dazzle. The products were functional but mediocre. But they were also marketed in mediocre geeky/corporate ways that just weren't that interesting to most consumers.
The original iPhone was barely more functional. But again, exterior aesthetics and a huge marketing and PR campaign forced open a consumer market for a product that was - like the original Mac - barely finished.
The problem Google has is that its products and its branding are heading rapidly towards mediocrity. It reminds me of DEC - an engineering giant in the 70s and 80s, which forgot how to read the market and innovate in the 90s, and crashed far more quickly than anyone would have predicted.
Quite likely, if the playing-field was level, or at least they'd have lost huge market-share.
Facebook bought Instagram in 2012 precisely because they were a direct threat. The FTC could have blocked that; or more recently, prevented tighter integration with FB+WA.
Currently they're using lobbyists to try to push TikTok (and WeChat) out of the US market.
Yahoo imploded because it had to pander to the short-term whims of the stock market; Zuckerberg references this frequently when talking about how FB (i.e. he) maintains control of its stock and autonomy.
> 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.
> 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.
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.