Many (most?) software projects exist in environments that demand predictability. Businesses need to be able to make promises to clients and potential customers in order to make sales and garner trust. In any remotely competitive industry these are two absolutely essential ingredients to success.
I mean, think about the software you use. Of all the shops that produce that software, which ones do you trust more than others? I'd be willing to be it's the ones that delivery predictably. At the very least the ones that deliver updates reliably - as in they do what they say.
Granted, every industry is different and some rely on trust and predictability more than others. Building an organization that is good at that is very difficult - and that cost has to come from somewhere doesn't it? In my experience it's at the cost of time spent building the product. A tradeoff between reliability and quality, if you will.
> I mean, think about the software you use. Of all the shops that produce that software, which ones do you trust more than others? I'd be willing to be it's the ones that delivery predictably. At the very least the ones that deliver updates reliably - as in they do what they say.
Of the software I use (slack, cloud infra, vim, Jira) exactly none of them tell me precisely when a feature will be delivered. They work hard on it and release it when it's ready.
A deadline like "in a few weeks" is acceptable. A deadline like "in 17 days" is asking to be missed.
Communicating hard targets to customer is always a mistake, because software is hard. For that matter, many other industries similarly try to avoid communicating hard targets, and for similar reasons.
Internally, though, Slack et al have targets and expect to deliver feature X by the end of sprint Y. They just don't tell you in case it slides by a sprint, and to avoid laying out a product roadmap for fast-moving competitors.
Most good software that I can think of has the luxury of being delivered whenever it’s ready. It’s not estimation that improves the quality of the product but good cost/benefit analysis, although you can get one from the other.
There is nothing unique about software - building almost anything has a certain amount of inherent unpredictabilities - would you hire someone to build your house with no commitment of when it would be done, what it might cost or what it might look like before it is completed? I doubt it.
If you give 2 builders a set of blueprints for a house, they will build essentially the same house.
If you give 2 software developers the same software spec they will give you 2 completely different pieces of software.
The code is the blueprints.
If you’re building a new innovative house that is different than what currently exists, the design phase is very similar to software development, and is likely to take an amount of time that is unknown at the beginning.
That's fair. A builder could build a terrible house from the same blueprints as another built a great house.
However that's not really what I'm talking about. Assuming some minimum level of quality, 2 houses built from the same blueprints with the same materials and finishes, in similar locations, and by similarly skilled craftsman will be pretty much indistinguishable from each other to the end user.
More analogous to software development is the design of the house with the blueprints as output, and regulations, client review, and architect creative inspiration as the software specs. Nobody complains about blueprints being delivered too slowly. They just happen on a competitive landscape where two people are racing to deliver to the client so the slowest person loses.
I like kanban, a stack of tasks with predefined dependencies determining if a card can be picked up, and sorted in priority order once they can be picked up. When something critical goes wrong, the entire team stops and works the problem individually, competitively , until the problem is solved, and the team then resumes their prior work. CI/CD delivers to production, features are enabled when they are ready and the customer is ready. Feedback goes immediately back into the stack and delivery leads constantly manage the feature flags, the stack priority, and inter team communication. The devs just dev and stop the line. The team tech lead, product lead, delivery lead, architect, and program/product lead do all the negotiations and priority setting. There are no estimates. You deliver constantly. You need strong leads and architects to run this way, and you should probably coach your client to expect slow change at first, and rapid change after the first release.
Done this at several clients, for several different domains, with lots of interdependent teams as a consultant, and it is highly productive. The one time it failed, we didn't get buy-in on feature flags in production and the client insisted on batched release branches and long-term maintenance branches for those cut releases.
The other, minor failure, is that it is very prone to momentum. That's when teams get overconfident that they can fix problems in-band with tasks (because they've been successful for so long), and are resistant to stopping the line. This can be spotted by a person not delivering a pr for more than two weeks, or not transitioning a card to done for more than two weeks. Tech lead calls a meeting, determines the issue, decides on stop the line or not.
It works. It's iterative. It keeps the number of communications channels and decision stakeholders low. It cross-polinates through linked dependencies. It ensures product cohesion thru feature flags. It evades critical missteps and bugs via stop the line. And it works well with our modern SSO dev/platform ops and integrated toolsets (Atlassian/clickup + ci pipeline of choice where docs, features, delivery can all talk to each other and reports can be generated for leads that pull from the integrated tools). It doesn't fix Conway's law, but I am not sure that actually needs fixing in truly large development houses.
Yes all large projects have risks, however it's ridiculous to say there's nothing unique about software. How often does a nail in one corner of a building become a dependency for a bunch of elements clear on the other side? How often does a dog house have to scale to a skyscraper because more people suddenly want to use it? How often do materials and laws of physics change in the real world? How often can you not get a clear answer on whether a specific requirement is necessary?
Software is arbitrary logic which many stakeholders expect to be magic. It's not the same as any kind of construction project.
>>How often does a nail in one corner of a building become a dependency for a bunch of elements clear on the other side?
Thats like asking 'how does naming my local variable X instead of Y have any dependency on code in other functions? and assuming that summarizes the complexity of writing code.
I take it you have never built a large custom house from scratch.
Seriously? Is this the nit you're going to pick on to argue my thesis?
Yes, I have been privy to the pain of custom home builds and remodels. The difference is, when someone says "oh damn the plumbing isn't working as well as we would like", when the contractor says that's not feasible to fix without gutting the house back to studs at the cost of hundreds of thousands, people understand that intuitively. They don't say "can't you just drill some holes and run some new pipes diagonally through the living space".
Software is malleable, opaque, and ever-changing. Construction and maintenance costs of physical infrastructure can be explained in a way that a reasonable lay person can understand. That is not true of software at scale.
And with the same result, you can't expect someone building your house to finish it on time, on budget, the same way you expected it to be built going in to it. Construction projects in the real world end up the same way software projects end up -- with ~ ~ unforeseen ~ ~ delays and complications.
> Nothing about building software, especially innovative software is predictable.
This is basically exactly the point. It's incredibly difficult to predict building 'large software'. So, lets try a few things to help make it a little bit more predictable by trying to predict smaller increments.
> Why do we need predictable deliveries?
Say I'm building a piece of software - maybe an app the audience would use - for the Superbowl. It's very handy to be able to estimate our progress to see if we'll actually land that date. The Superbowl isn't going to move because of our app, and our app isn't very useful the month after the Superbowl.
This argument comes up a lot but this is a very narrow case. Neither you nor I are building software for the super bowl, and if we were building something with such high stakes we should start way, way early and concentrate on core functionality first. There's no real deadline for the feature we decided we needed last week.
It's not the Superbowl, but I built software for a national sporting event during my time working on VOD for a broadcaster in Australia.
I think this sort of thing - where what you're building has external hard-to-move dependencies - comes up more often than you think. Those election visualisations on NYT didn't build themselves. There's often a bunch of less-hard-but-still-inconvenient dependencies as well - you're building software for hardware, or there's advertising campaigns in planning/motion.
If you’re post-launch, you need predictability so that you can ship the new code often. Otherwise your HEAD might be unshippable for weeks, which would be bad from
the “written but unshipped code is a waste like excess inventory” standpoint.
Apple comes out tomorrow and announces the new iPhone 15. "We do not know when it will be ready. It might be tomorrow, or just as likely it will be in a hundred years."
Who will hold their breath? Who would invest in this? Software needs to be used by people. Software deliveries that cannot be estimated cannot be relied upon for planning. It may as well never be announced!
Apple doesn't come out and announce a new iPhone 15 until it's already 90%+ done and working, and therefore can accurately predict some kind of reasonable release window.
And software that can't be estimated is still useful, even if you can't plan releases around it yet. "Apple has been unable to accurately estimate any release window for the Apple Car or Apple VR. Therefore no one should invest in it." would be a pretty silly statement, right?
> "Apple has been unable to accurately estimate any release window for the Apple Car or Apple VR. Therefore no one should invest in it." would be a pretty silly statement, right?
That's exactly how it works though. Imagine Apple's stock price if they announce the Apple Car, without a release window. Now imagine that they come back the next day and say "oh by the way, we're aiming to release it in 2086." What happens to the price? It goes down. There was an implicit estimate used to judge the value of Apple.
Likewise, all software has an implicit estimate. There has to be! Without one, it's worthless.
OP doesn't care about building software (innovative or otherwise). He cares about getting his quarterly bonus, which is based off of meeting deadlines, because that's what can be easily measured. Delivering a quality product is much harder to measure.
Actually it is predictable, the majority of software engineers predict it at work every day (or every 2 weeks in sprint planning).
Why do we need predictable deliveries? Because if Bobby from accounting doesn't have your piece of software ready by the 31st of November the company will be slapped by a fine from the IRS so large that you'll need to update your CV alongside all your colleagues from the now bankrupt company you used to work for.
> Why do we need predictable deliveries? Because if Bobby from accounting doesn't have your piece of software ready by the 31st of November the company will be slapped by a fine from the IRS so large that you'll need to update your CV alongside all your colleagues from the now bankrupt company you used to work for.
Yep, at the end of the day, the whole world can't run if everyone is a professor emeritus just freely exploring random possibilities, even if it would be hundred times more efficient to just "get out of the way".
In what company is accounting moving to software which isn't ready, and where they will experience a large fine if it's not, guaranteed by a 2 week promise? Rational people just don't do this. Especially considering how often we're wrong even when we define sprint boundaries and point all the stories.
> In what company is accounting moving to software which isn't ready, and where they will experience a large fine if it's not, guaranteed by a 2 week promise? Rational people just don't do this.
You just have to sign a standard contract for building a project in 24 months, and wait 23 and a half to be in that situation.
Managers need a tool to avoid reaching that situation and renegotiating the terms in advance.
Let’s boil this down to first principles. Nothing about building software, especially innovative software is predictable.