The issue is that you are being asked to estimate something that has never been done before. Even houses always go over time and money and that is fairly straight forward.
These days, I only give estimates in terms of units but without numbers. Hours, days, weeks, months, quarters or years. Some relatively small number of those units. If you want a quote it will take an extra 1/4 of the estimate worth of time for an exact timeline. I really wish we would treat sales people the same way. "How much money is this contract for? What date will it be signed?"
> Even houses always go over time and money and that is fairly straight forward.
This is an incredibly important point. I was "raised" in commercial software at a time when there was a lot of condescension internally towards ourselves as an industry because we couldn't do estimation and planning, and building was the favorite comparison. A $100 million building couldn't run late or over budget. That would be unimaginable, and it doesn't happen because those people are too serious and professional to let it happen, not like us unserious, immature software doofuses. Turns out that was a complete lie, but at one time it warped the profession, because it made people believe the answers already existed, right around the corner, something you would figure out pretty soon just like last year you didn't know regular expressions and now you did.
The problem with that was that when somebody walked in with a button-down shirt, oozing confidence and saying they knew exactly how to consistently deliver software on time and bug-free, those people weren't laughed out of the room. Elaborate heavyweight processes, and their "lightweight" (hah!) cousins, could sell themselves as proven, established solutions. We could believe that bullshit because we had been fed the lie that other industries had conquered these problems.
I've seen a lot of industries compared to programming, like construction and manufacturing. For example, people trying to apply lessons from the Toyota Production System to programming.
This doesn't make sense, because we have systematized the construction of executable programs with extremely high reliability and predictability: we call it "Copy File"
It's the design that is the hard part, and the process of coding is the process of iterating on the design. Even turning the design into an executable is extremely reliable, either running via a VM or scripting engine, or compiling. Those are all very repeatable and reliable.
There are other disciplines that focus on creating and improving designs (like writing, painting, architecture, 3D modeling), but it's not like they're reliable or predictable either, unless you're designing very similar things over and over again. That's true of coding as well, but you don't really end up doing that, because once you've done it 3 times you should make a library and then never do that part again, just the unique bits.
In short, yeah, coding is its own thing, and I doubt it'll ever be predictable unless you're wasting a lot of time and effort doing very similar things over and over.
This point was recognized quite early. there is an influential article by Jack W. Reeves from 1992 [1] that looks at the manufacturing analogy and argues that "the code is the design" whereas the "manufacturing" is just the compilation and packaging (that is, super cheap and automated). I believe it‘s this line of thinking that inspired Agile practices, where software developers are seen as engineers rather than code monkeys.
Design but also requirements. You don't really know what should be built until you have a prototype. And estimating how long it will take to come up with a prototype that does what you think it should do, in other words coming up with requirements, is just the snake eating its tail.
I like to compare programming to the marketing industry.
Highly creative work and when deadlines are involved the work becomes spurty (sprints) with corner cutting (scope reduction) to meet unrealistic and over committed deadlines.
It doesn’t even have to be a big construction project to hit budget and schedule issues. Rebuilding our house had us going right back to the drawing board having to get new plans drafted and approved. It worked out much better in the end but the unforeseen cost and time overrun was quite anxiety inducing at the time.
But yeah the idea anyone has magically solved accurately predicting the future is completely bonkers.
I like to remember "plans are useless but planning is indispensable". The plan is useless because of the challenge of predicting the future. But the planning is useful because trying to predict the future gets you asking good questions.
What is then terrifying to me then is when I find myself working with people who manage to, by way of treating "estimates" as "quotes", make it so demoralizing to plan anything--as it will be "used against you" later (which they do even if they were adamant they wouldn't)--that everyone does everything they can to discourage and sabotage any attempt at planning, because planning is valuable :(.
Also because planning gets you to make your desires explicit and to put them in a useful framework. Unexpected problems, disruptive as they may be, don't usually derail the whole plan. Some parts may need to be rethought, but others are still valid, and the whole thing keeps you focused.
There was a submission on this (in the annals of HN) where someone made the point that, more often than not and under normal project scenarios, unexpected problems usually do derail the entire software engineering plan.
The gist being: estimates are given with zero as a lower bound, and some upper bound. In reality, there is no upper bound. Software engineering can and does involve unexpected problems that would take infinite time to solve.
Ergo, project timelines are more accurately averaged between {min_time} and {infinite}, and, given that, remaining risk is the only true metric that should be reported. I.e. how far are we along in terms of project completed, such that we can say only x% of the project remains, and therefore that 1-x% did not explode.
The fundamental problem with estimates is that the recipient believes that the estimate will always turn out to be true, which is obviously not correct.
So, why can't we express the upper bound in combination with uncertainty?
Example: "There is a 50% chance that the feature will be delivered within 1 month."
As time progresses confidence starts increasing and we get closer and closer to how much time it actually takes (be that 5 days, 5 months or 5 years). On the day the feature is completed, confidence is 100% because the real delivery date has become known.
Programming is isomorphic to theorem proving (according to Curry-Howard).
Therefore trying to estimate a software project is a bit like trying to estimate how long it will take to prove a new theorem in mathematics, assuming you would know which exact theorem you want to prove.
In a way I think yes but just getting the type-check right would be like proving ANY mathematical theorem. It is very easy to prove mathematical theorems if you don't care what those theorems are.
The challenge in mathematics, and programming, I believe, is what ("lemmas") to prove so that you can then prove more things that are useful for engineering, science, etc. . What functions to write in your program so that you can get its "main function" to do something useful.
Add to that the fact that much of the "type-checking" with current practical programming languages still has to be done informally, to describe what we expect of the result and then prove (to yourself and the client) that the program does that.
A lot of the thought-process that goes on in programmers' heads is informal reasoning proving things to yourself, "If I make this change here then that thing there must have a correct value, and then ..."
its more than that. there is a loose correspondence between plan and work. so changes in plans can often be projected onto changes in work. the same goes for expectations and dependencies.
the other thing about the plan is that it attempts to capture what completion might look like. where i come from, the things software developers do right before releasing code look very different than the things they do when they are starting a new project. the plan can allow you to try to do some orchestration, ensure minimum quality bars are met, etc.
having a fuzzy map of the future that you're constantly having to correct sucks. having no map at all leads to the kind of carpe diem development organizations that never seem to finish anything.
More than that we need to be flexible to adjust a plan. You’d be amazed at how many people who quote that aphorism aren’t actually flexible. At least with a building they are also motivated by not leaving a physical monument to their failure.
I'll raise (shrink) you an estimated-at-1-week landscaping project for my house that ended up taking just over 2. Wasn't particularly anxiety inducing, though, as we expected some overrun and both parties (re)negotiated in good faith.
I used to lead a software department in a small company that sold software to, mainly, the construction industry, so the go to comparison was building houses, which according to my boss, were always on time and on budget, unlike software.
The funniest thing about it was that our software was used by huge projects: Hinkley Points C, HS2, etc ... which obviously have an great track record of being on time and on budget ಠ_ಠ
There's also the problem of of a company working on multiple construction sites in parallel.
In software engineering, this also happens of course, especially if you develop in house. And you also need to factor in the maintenance, as it's usually performed by the same team.
'I really wish we would treat sales people the same way. "How much money is this contract for? What date will it be signed?"'.
In well-run sales teams, that is exactly what happens. There is a constant move towards more accuracy and tightness in forecasting.
In poorly run sales teams, the reps basically set their owns quotas (padded, of course, to mitigate against massive uncertainty) and then are very imprecise at managing the WIP. Which sounds like a poorly run engineering team too. In sales, though, at least there is a very objective measure ($$$ closed) at the end of the period. Also, the period is fixed typically (months, quarters, etc).
Engineering is obviously different... what's the measure? LOCs? Obviously not...
Edit: just to be clear, I'm saying that well-run sales teams and well-run engineering teams probably have a lot in common, not that they are exactly the same.
I think you're talking about goals, which isn't the same as estimates.
A well run sales team, like a well run dev team do benefit from goals. Like increase X by Y. That's because it can guide your decision process of what you'll spend your time on and what you won't. It can also push for focused innovation around a particular area.
But I think OP meant what if you asked the sales team: How much time will it take you to close the deal with X? Would they be able to estimate that? Which is different from asking them: "Try and close X Y% faster than it took us to close Z last time." The former would be asking for an estimate, the latter would be setting a goal.
Sales team certainly understand the sales cycle and different velocities involved.
Eg - two jobs we ago sold to finance playera from small hedge funds to huge asset managers to central banks and finance ministries. You could sell more small hedge funds by knocking on more doors but you understood that the big players took months and years to decide. And of course we always tried to hone the sales org and process to arm the sales people with tools and data to move faster. We certainly held them much more accountable than devs.
It's actually not a fair comparison - software development is often like golf - the only limit to your velocity is you while sales can't really move faster than customer's process in many cases.
(Yes I obviously know dev processes can have external dependencies too)
I have never seen this to be the case outside small, self-contained projects. Even with a fixed scope (its own can of worms), major slow-downs often clearly come from outside the team—unexpected or unreasonable infrastructure limitations, problems with the products of other teams, shortcomings of internal or external tools and libraries, unclear or inconsistent evaluation of the work by its eventual users... etc.
Moreover, in cultures tied to estimates-as-quotes (or estimates-as-deadlines), there is often significant pressure for "product" teams not to try to fix these problems, even for themselves. It would be net faster for us to write our own version of X than to try to integrate the work of team Y? But they've already done the work, why would you want to do something redundant?
In a world where technical teams have clear ownership, this is less of a problem. Team Y giving you problems? Work around it the best way you can. Infrastructure not supporting your needs? Hack together your own on top of lower-level pieces until it's ready. But organizations with cultures that give technical teams the space to do this also have far less issues with estimates—both in having better estimates and being able to handle estimate uncertainty gracefully.
Moving faster and increasing impact of deliveries, those are goals you can work towards, that do not involve needing to estimate anything.
The question is: do you for every sale provide an ETA of when you think the sale will close, with projected key milestones along the way and their dates, all before even beginning engaging the would be customer?
// do you for every sale provide an ETA of when you think the sale will close, with projected key milestones along the way and their dates, all before even beginning engaging the would be customer?
No because that's kind of useless.
With software, the estimate is (or should be) part of the go-no-go decision for the project. "Oh, it's gonna take us 10 years to build this? Maybe we should reconsider"
Yes, it's like that. You have to move deals through many stages. There's expectations of timing into each stage in addition to quota. Most places will fire even senior sales people if they don't perform for a few quarters.
"$$$ closed at the end of the period" causes negative externalities at the expense of value delivered in the long run (overpromising, misleading, mispricing). This isn't unique to sales/engineering, I've heard of it playing out the same way in "factory" law firms where sales-lawyers and delivery-lawyers are separate.
> at least there is a very objective measure ($$$ closed) at the end of the period.
That is far from an objective measure standing alone, unless every salesperson generates all their own leads and the distribution of potential leads is random.
But generally your more experienced members will get the bigger potential customers.
So now you're back at square one trying to judge their success in relation to the anticipated likelihood of their leads.
I used to work for a company that sold custom business systems. When the customers did their parts, i.e., signed of specifications and did their acceptance testing within schedule, we usually delivered within estimate and in time. This was of course applications built with boring technology where 80% was simple CRUD. But the market for this should not be underestimated.
Sales teams do EXACTLY that. Go into salesforce and you’ll see the estimates.
Potential deal with client Foo will be for $X, to be signed on Y day, with Z% chance of closing.
On an individual level, it may be more precise than it is accurate, but it’s a fairly standard and important part of sales operations. And yes, the estimate dates are often just ways to express orders of magnitude (put next Friday as estimate dates not because it’ll definitely close next Friday, but bc it’ll probably take about 2 weeks). The % chance of closing are typically pre determined by what stage of the deal you’re in.
However, when applied across dozens, hundreds, thousands of potential deals, it allows the organization to understand their sales pipeline and sales velocity fairly accurately.
Of course the numbers are gamed a bit. And some sales people are much worse at estimating than others, or less consistent about keeping the numbers up to date. But the benefit of these practices are massive.
Houses have been done before. Enough time that we are good at those estimates. Once you have built the same house a dozen times you can estimate to within a couple hundred dollars. Contractors do this all the time for spec houses. Spec meaning that they are building it and the planning to sell it once it is complete. I know several contractors who do this all the time. They have never had someone order a spec house and come in anywhere close to the estimates. Everyone goes over the light fixture budget ($600) by at least $3000. Similar for the kitchen and bath fixtures. It isn't unheard of to double the cost of the house on seemingly minor upgrades.
Probably more to do with personality mix than circumstance. I've had bosses where I could say things like that and get away with it. I've also had bosses where if I said something like that, I'd be packing up my desk.
If you give a bonus for getting done on time/early, construction will finish pretty darn close to the estimates. Construction is underbid at least partly because the incentives are setup for underbidding.
A lot of the rest is Planning fallacy[1], particularly with individual contractors, but larger contracting businesses can absolutely come up with realistic estimates based upon past experience.
Estimating in terms of units is mostly for internal teams with a fixed payroll. It can work really great in that context. But imagine that you are asking for project funding. The person across the table logically wonders: how much do you need? You yourself logically wonder: how much do I ask for? In that environment, can either party really accept “who knows” or “5.5 units” as the answer unless money is not a concern for anybody?
In my opinion, the estimate gives them a sense of scale. If some small number of months would cost too much, then you know and can start to have an investigation project of a week to better help define what should be in and what shouldn't.
At least for government projects the 'wrong' estimates are intentional. Admins always take the cheapest quote, so to earn money everything happening during construction has to be 'out of scope'. Like winter, or different soil layer than specified, or whatever.
These days, I only give estimates in terms of units but without numbers. Hours, days, weeks, months, quarters or years. Some relatively small number of those units. If you want a quote it will take an extra 1/4 of the estimate worth of time for an exact timeline. I really wish we would treat sales people the same way. "How much money is this contract for? What date will it be signed?"