There are some very rare cases where delivery date is more important than what you are delivering, but modern management seems to delight in generalizing this unusual occurrence to every situation. People do get promoted for having been able to deliver completely broken, useless and damaging solutions on time. If that’s the measure of project success you can expect dates to rule (even when they continuously slide). After all, if you are not a trained surgeon, and the only thing you are told is that a given surgery should last no more than X hours, guess what will be the one criterium for all your actions during the operation.
Where I work, we deliver on time. Customers schedule upgrades many months in advance, and in series or sync with other upgrades. They are on maintenance contracts to get the latest version.
If we deliver a broken product, than that is a failure to cut scope adequately. Do that once or twice and suffer through the consequences and you will learn not to let it happen again.
Moving a feature into the next release cycle is equivalent to extending the deadline for that feature. You're right, though -- management does seem to have a strong preference for one terminology over the other.
That’s true, but if the product is big enough, with enough varying constituencies, then delivering something to a large chunk of those people on time is a lot better than delivering nothing to everybody on time.
I think there is a lot of "it depends" in here. If deployment is zero friction to the customer then maybe this applies. If deployment by customer is disrupting then forcing them to go through multiple release cycles due to bugs or lack of required features can be worse for them.
I just lived with a half-broken product for a year rather than deploy the more final full featured but less stable version multiple times from a vendor due to such deployment difficulty. I want quality and completeness over speed in that case.
That doesn't apply to software development unless you're a startup with limited funding and no positive cash flow. In the vast majority of cases, the software is already released and making money. Whether you finish the next release in 1 month or 2 is of no practical importance, except that it makes the manager look good. He can report a larger profit margin because the cost that went into that release is roughly half if it was released in 1 month rather than 2.
And therein lies the conflict that this post doesn't really address or resolve: there's rarely a discernible difference in revenue between a high quality release and a buggy, low quality release, but the profit margin of the former can be (and often is) much lower. A great real world example of this is PUBG.
Since you picked a gaming example, I would like to present the idea that in gaming the opposite is true.
If you have a live game that you intend to last a long time, it’s extremely important to establish a reliable release cadence that the players can depend on.
Our company first released our game in 2012. After release we didn’t know how important this is. We just kinda made updates and released them when we finished them.
The player numbers never went above what we had at release. For a few years our numbers were pretty flat. We would have up releases and down releases but we never broke our initial numbers.
Then we changed to a cycle of having a release every 3 months.
This was a massive improvement. Most players won’t keep playing your game continuously forever, but if they always know that there will be a thing to come back for, and when that will be, they will stop playing before they are burned out with a plan to come back.
Suddenly our numbers grew with every release. Each 3 month cycle saw a large percentage increase over the previous one.
After a few years of that our game is massively larger than it was at release, and it’s still growing with each subsequent release.
I’m not saying that it’s okay to release a buggy game, you have to scope each release so that you can do it on time without being too buggy. What I am saying is that the release schedule is actually really really important.
For context to other readers, Negitivefrags is talking about Path of Exile[0] and seems to be downplaying the success GGG has achieved in the last few years. The regular release of compelling content has driven PoE into a great position as the market leader for ARPGs.
One thing they didn't mention is that the regular release cycle lets you mess up and recover. For example, the Essence league(a 3 month batch of content) was underwhelming for most players. However, the Breach league following that regrew any goodwill that might've been lost.
> there's rarely a discernible difference in revenue between a high quality release and a buggy, low quality release, but the profit margin of the former can be (and often is) much lower.
A wonderful insight, thanks.
I guess that hints in a direction where "both are Right". For the technical teams, it's self-explanatory that "one does not simply push out crap". On the other hand, the MBAs and finance hear engineering say the same thing about mostly everything, and double profit margin is double profit margin, so the incentive structures that encourage faster releases probably seem completely plausible to them.
Not that things are that clear and clean in real life. But having drifted from pure engineering to engineering management during the years, I feel more and more sympathy towards some of the challenges of the "ugly and evil business side" by the year. Also, nothing is as hard as communication. Except trying to communicate goals with broad incentive structures, I guess.
> it also increases value to the customer, and therefore price
Not always. Look at the most recent OS releases. Windows 8 and 10 had terrible adoption rates because they actually deliver a negative value for most users compared to what they already own (windows 7).
> It also helps you stay ahead of the competition, also increasing price.
Again, not always, for the same reasons mentioned above.
> Can you elaborate on PUBG?
From a technical point of view, PUBG is a train wreck. They had budgeted a 1 year development cycle, which for an online 3d FPS is ridiculously short. I think they initially launched it after a year and a half of development. But, from a sales point of view, PUBG has been very profitable. People are playing it despite the networking problems and relatively bad graphics because it fills a niche that hasn't been addressed by other game companies in years. But, there was no guarantee it would have been a hit. The condensed timeline and less than stellar graphics was their way of keeping development costs low. If the game hadn't been an instant hit, they could have still made a profit.
PUBG is an example of how low quality releases can be profitable, not how "there's rarely a discernible difference in revenue between a high quality release and a buggy, low quality release"
Go back and read the sentence you quoted, in it's entirety.
> there's rarely a discernible difference in revenue between a high quality release and a buggy, low quality release, but the profit margin of the former can be (and often is) much lower.
No, I don't. I don't believe there's rarely a difference in revenue between a low quality release and a high quality release. Further, PUBG, at least as presented, doesn't support this assetion, since it doesn't show revenue failing to increase after a higher quality release.
You mean, the bug-laden beta build they pushed out before Christmas and are selling for full price? Yes, I'm sure they made plenty of money, but they also hurt their reputation.
All projects have tech debt and bug fixes. If there was a surefire way of obliterating both of those things consistently, it would be an easy sell to management. But, because there isn't, they fall back on what they can measure: costs vs revenue.
Speed never matters more than the quality of the surgery. You're conflating constraints and criteria. Speed is sometimes a constraint, but never a criteria.
But speed is a self-imposed constraint on most projects rather than a physical law, meaning it might be violated. Furthermore, there might be a smooth relationship between speed of execution and value returned (even outside of cost of production). So when evaluating how successful a project was (software, surgery, or otherwise), you often do want to use speed as a criterion, even if you initially thought of it as a sort of constraint for the sake of simplifying planning.
No they aren't. Constraints are necessary but not sufficient. Criteria are necessary and sufficient. In other words, necessity is a lower bound and sufficiency is an upper bound. Criteria is the upper bound, constraints are the lower bound.
Patton's strategy was borrowed from his inspiration...Sherman. The goal was to make war intensely in order to end it quickly and let his soldiers return to their lives. Software development is not war.
Deadlines do matter in many situations. Like, for example, being able to announce a new product or feature at a conference with a fixed date. Or before a sales meeting with a new client, or before a yearly allocated budget expires, etc.
I have, however, also encountered arbitrary deadlines that people hang onto for no good reason.
I love that metaphor.