"No, it's less effort than that"

https://smartguess.is/blog/your-estimate-is-less-than-that/

by replyifuagree • 3 years ago

388 362 3 years ago

scotty79• 3 years ago

Pushing estimates is silly. If you have another estimate than your developer you have every right to have it and make decisions based on it. But the reality of how much it will actually take is the future. It is unknown and will probably worse than both your estimate and the one of your developer you don't agree with.

avereveard• 3 years ago

Pushing estimated is wrong but solutions exists in a spread of quality, completeness and efficiency, you can definitely find a balance where the time to release is shorter, if you are prepared to give up something else

Often the issue is that programmer are unaware of the exact quality and sophistication expectations and estimate the perfect solution with the most efficient algorithmic complexity whether it makes sense or not for the business scale and the other constraints at hand.

Then management ask shorter deadlines, programmers find different solutions that may or may not be appropriate, and it gives the illusory appearance that managing is working, while the underneath visibility/communication issue remains unaddressed while creating potential technical debt.

zeroCalories6• 3 years ago

Management has to push for lower estimates because developers have an incentive to overestimate to make life easier. The only situation where this isn't a problem is with eager junior devs, and devs that have direct skin in the game, such as at startups or a department about to be cut for being unprofitable.

phanimahesh• 3 years ago

Also any estimate providedwill be pushed downwards, not to mention unforeseen curveballs, so there is an incentive to estimate higher to preserve your own sanity. Some don't learn to estimate higher until they get burnt.

Another common pitfall is to estimate each task in isolation, and the people receiving the estimates considering them timelines. Effort estimates and delivery timelines are wildly different beasts and great care has to be taken to avoid miscommunications.

ejb9992• 3 years ago

>Management has to push for lower estimates because developers have an incentive to overestimate to make life easier.

Bingo, having just left a mega-corp this is the status-quo of a lot of projects I had visibility into - take a trivial task, estimate it at 8-13 story points (i.e. the whole 2 week sprint), have nobody question the estimates, complete the story in 1-2 days and then chill for the other 8-9 days left in the sprint. It was pretty much an open secret.

...and nobody gets faulted by management, because they completed the story in the time they committed to.

On the other hand, if you had estimated the task at 3 days, and it ends up taking 5, you would get dinged for it. Estimate the same task at 13 story points, even if it was really only a 3, you were rewarded for meeting estimates - its a very perverse incentive structure.

rightbyte• 3 years ago

Ye. If the estimates are accurate they will be overrun about 50% of the time. Punishing "late" tickets is what leads to the outcome of having to pad the estimates as much as possible.

DiskoHexyl• 3 years ago

Predictability is arguably more important than speed, especially when you have a lot of moving parts. When you have a developer that is slow, but constantly delivers on his estimates, you have a reliable IC that you can count on not failing to develop an API for some other team to integrate with. Fast and ambitious guys, who frequently fall behind their own estimates, are a pain in the ass to manage in large teams/companies.

Sure, with startups on the bleeding edge and with RnD it's different, but most of devs aren't doing that

ResearchCode12• 3 years ago

How about getting rid of the "stories", "points" and "sprints" altogether? Not only is the nomenclature abhorrent, the best software projects don't use enterprise agile methodology.

Buttons840• 3 years ago

Management has to push for lower estimates because developers have an incentive to overestimate to make life easier.

Developers have to push for higher estimates because management has an incentive to underestimate to make life easier.

See what I did there? There's a fallacy in both statements: one side's actions are portrayed as greedy pursuit of "incentives" while the other side's actions are portrayed as a natural and logical counter to those incentives.

zeroCalories6• 3 years ago

You're reading too much into the morallity. Furthermore how is it a fallacy?

throwawaysleep2• 3 years ago

You punish us for being ambitious and failing and give us nothing for being ambitious and succeeding.

As a developer, I endorse doing as little as possible as a result.

zeroCalories6• 3 years ago

This is a very childish way of viewing the situation. Of cousd you should look out for yourself, but your reward is not fixed, so you should not look to minimize your work at all costs

nonameiguess• 3 years ago

Estimate high is the mathematically most valid thing to do in the face of uncertainty. This is more or less the fundamental theorem of finance. Expected rate of return increases with risk as compensation for the risk. Project planning should be following the same principle. If you're uncertain of traffic conditions, you leave earlier to be safe. If you're uncertain of future work unknowns, you estimate longer completion time to be safe.

If management is pushing for lower estimates, it's typically going some reason along the lines of:

- Someone higher up gave them a fixed budget or a fixed deadline and they can't exceed that.

- They're expecting market conditions to reward earlier delivery more than higher quality.

- They don't understand the problem domain.

- They do understand the problem domain but don't understand limiting factors like tech debt or organizational process hurdles the developers face that preven them from hitting timelines they would hit under ideal conditions.

If it's one of the latter two, they need to have a come to Jesus moment with themselves because you can't run a team if you don't understand what they do, how they do it, and what obstacles they face.

If it's one of the former two, great, communicate that, but then whoever is ultimately accepting or using your product needs to understand the basic release models that you can either get a complete set of well-defined features or you can get a specific release date but you can't get both, except by luck. And you need to have an organizational culture that isn't going to punish developers if they don't get lucky and meet only one of those goals.

Companies purchasing labor output don't get to violate the basic constraints of being a consumer. If you've got a fixed budget, fine, but you get what you pay for.

marcosdumay3• 3 years ago

developers have an incentive to overestimate to make life easier

Have you ever seen developers overestimate their tasks? On what kind of alternative dimension this happens?

Developers are always deluded optimists that can't get realistic estimates no matter how much they inflate it.

Scarblac2• 3 years ago

It's not quite true. Many features can be in a very bare bones way or in a fully gold plated way, and several shades in between.

Sometimes I see colleague developers estimate two weeks for a feature I consider one day at most, because they assume lots of extra functionality that wasn't actually asked for, or that I didn't realize would be necessary.

If you are asked to change your estimate, see it as an invitation to discuss the requirements and proposed implementation a bit more. Maybe something much simpler that brings you 90% of the way there is both possible and a acceptable. Meteorologists don't have that option.

anonzzzies• 3 years ago

Often clients don't understand what they want; like you say, the difference between met plonking in a basic combobox/select vs some much nicer, and much more fitting the case, custom ui element doesn't really translate to anything many people outside IT understand. To explain this difference it can be drawn, but stakeholders still don't understand what's going on as they don't see & feel it, so you have to make it work mostly.

I have clients asking 'just do the simplest thing you can do'; we present prototyped gui's then after approval fully designed guis and after that a prototype. They approve the first 2 immediately as they can't even be bothered looking at them; some, when pressed, will try the prototype and often still say 'yes great, let's go'. And then when it works and they can try it on the test server, they say 'no this is really not what we meant'. I have had this with 2 person mom and pop stores (long ago; I don't do those anymore luckily) to fortune 500 companies with the regional directors and global cto present to give their opinion. And this is frontend ... Backend, devops is another thing entirely, but there, is also a large difference between bare bones or gold plated.

I know the game by now, so these days we make a lot of money from this broken process.

Scarblac2• 3 years ago

The other extreme is that management was talking about new functionality and we kept seeing it as just another small feature in our existing product, and kept giving them estimates of a few weeks. Until they ended up setting up a whole new team for it because what they had in mind was a completely new product fully focused on that functionality.

It's all communication, programmers and stakeholders live in different worlds.

IanCal4• 3 years ago

A valuable discussion to have is about how to change the scope so that the cost/return tradeoff is right for your stakeholders.

I've definitely seen devs assume too much needs to be done, just like I've seen non-devs ignore key parts of the problem that push up the time. Sometimes it's trying to make a general solution when actually what's needed is someone to sit down with a spreadsheet for a day.

There is back-and-forth as the estimates are questioned for being too high, almost never for being too low.

I'm sure people will have flashbacks when I say this so sorry to those, but this is the issue addressed with planning poker. The idea being that you all say how hard the task is, without being affected by each other, and discuss when expectations aren't aligned. Someone is probably missing something.

I might think something is simple because I've not realised a complex part of the problem, or because I can see a nicer neater solution.

atoav• 3 years ago

I get that. But as a tech guy I sometimes get itchy when the actual reality of things is ignored. A good example would be when a customer demands something that is mathematically or physically not possible. With wishes like these you could the do the planning poker all day and maybe land at a compromise that is still not possible.

As a former freelancer I am a big fan of just getting a thorough explaination of the problem, maybe with me looking over the shoulder of someone who has to solve it currently. And then I vanish in a hole for a few days and return with the design proposal I think would most elegantly, reliably etc solve the problem.

Unless we are speaking about people who have good experience with complex problems, most people are okay at describing their problems, but suck at proposing solutions (they are always modelled after the limited things they know).

IanCal4• 3 years ago

Always a good time to rewatch the expert: https://youtu.be/BKorP55Aqvg?si=eqw2-mWA1T3FDUtl

most people are okay at describing their problems, but suck at proposing solutions

Yes, it's best to focus on their problems and the consequences of proposed solutions. They shouldn't care about your caching strategy internals but they do care about whether stale info impacts their users or what scale it's reasonable to hit, or how much extra it'll cost to implement.

BlargMcLarg2• 3 years ago

but this is the issue addressed with planning poker.

It isn't. Having a team which is both intimately familiar enough with the set of features as a whole, and understands how to use the system to get around the inevitable 'A does it in X while B does it in X*3', are both prerequisites. Suffice to say, with the amount of discussion based around Scrum being done wrong alone, neither of those are even remotely a given. This also doesn't take into account turnover and new features being able to remove a team from meeting those prerequisites at any point.

Too often it just devolves into people raising eyebrows at one another and either it becomes 'X will do it, so X's estimate becomes the value' (why even bother doing poker then) or 'take the average or minimum' which screws over anyone who estimated higher.

IanCal4• 3 years ago

I mean it is literally the issue that planning poker addresses - identify differing expectations without influencing the initial estimate. People can then totally ignore that, and ignoring something makes it pointless, but that's true of literally anything.

It identifies a lack of a shared understanding of the task. Or framed differently, it identifies when you probably all have the same expectation and you can move on.

someguydave• 3 years ago

If people are unable to solve the problem themselves but instead defer to someone else’s estimate then they should not be participating in planning poker

Tabular-Iceberg• 3 years ago

I've definitely seen devs assume too much needs to be done

Absolutely this, and managers and pseudo-managers like product owners, business analysts and full-time scrum masters do too. I see a lot of weird requirements, often technical in nature, that nobody actually asked for, it was just a long string of people who just assumed. Like an infinitely scalable microservice architecture with a full SPA just to let a dozen internal users download some data as an Excel spreadsheet.

code_biologist• 3 years ago

I'm glad the article gets to talking and haggling with stakeholders. Trying to estimate with different understandings of where complexity lies between stakeholders, product managers, and devs is the biggest source of frustration in my experience.

Lol, long ago I was working with a junior PM who heard what was difficult and what was easy from devs and started to design features around that intuition to make work faster. Too smart for his own good though. Often the proposed features would be more complicated in trying to be easy. Much to his chagrin, our ticket estimation sessions often turned to "wait, what are we trying to do here again?" But often, one week of work turned into a day or two.

The world is complicated and I think a sizable minority of workplaces defy stereotypes.

One hard driving "VP of Operations" type I worked with would push for aggressive estimates, but alongside that suggested every corner that could be cut without hampering the business. In a bizarre way, he was far more agile/MVP/product-validation focused than almost all of the technical staff.

I've seen fast but sloppy developers drive stakeholders crazy. One situation I was in, we needed to culturally back off from way over-spec'ed tickets. The engineers had been focused on closing tickets and "shipping" as fast as possible. If a detail wasn't in the ticket, it wasn't happening, so tickets got bloated and rigid. The rest of the business was ok with slowing down if it meant reliable features, the engineering leadership was the most hesitant.

m0llusk• 3 years ago

This is a bad metaphor. You can't make the sun come out faster by dropping features.

albert_e• 3 years ago

yeah i cannot use this analogy to tell my client to backoff.

they will say: if you guys are only watching the weather and telling me whether it will rain or not -- I dont need you guys then. I will hire someone else - who will build me a working umbrella within my budget before it starts to rain.

or some other imperfect analogy that we cannot question having done the same thing ourselves first

wojciii• 3 years ago

What you can do is release a product faster with less features and continue working on adding the missing features after the initial release.

This happens all the time in embedded systems which can be updated by the customer.

pydry5• 3 years ago

If you're asking for estimates from devs at all you're probably pushing waterfall on them.

If you want to be waterfall, that's fine. If you're forced into doing it by your business context, that's also fine. But, you shouldn't be under any illusions about what you're doing. It's a waterfall behavior that will drive waterfall effects.

maccard5• 3 years ago

That's just not true. It _can_ be waterfall, but story points are everywhere in agile development.

pydry5• 3 years ago

Story points are for relative sizing are not estimates. That's why you use story points and not hours or days. They're for re-arranging the priority of stories and deciding which ones to do or not.

nabla92• 3 years ago

My estimate math:

R = t × [1.1^ln(n+p) + 1.3^X]

R - time it really takes.

t - shortest possible time it would take without need to communicate.

n - number of people working and involved during the process, both customers and developing organization.

p - longest communication distance network involved in the project (typically from the lowest level developer to the end user)

X - number of new tools, libraries, techniques, used in the process.

Example. Project involving one developing writing code. Project would take 2 weeks (t=2), but it has 5 people (n=5) involved total, only 1 new tool (X=1) and longest communication distance is 4.

2×(1.1^ln(5+4) + 1.3^1) = 4.5 weeks.

luibelgo• 3 years ago

Out of curiosity, how did you came out with this formula? What’s the math behind it?

dsomers• 3 years ago

It’s from his butt. Which makes it just as valid as how everyone else does estimates.

nabla92• 3 years ago

Crude estimate based on some self evident truths:

Logarithms for number of people and communication chain come from network theory because network size and network distances slow down information flow.

New technologies bring in unexpected delays and problems that rapidly accumulate in nonlinear ways. If bring in 20 people to work with new programming language, new library stack, etc. everything slows down to crawl.

crispyambulance• 3 years ago

It's a bullshit formula that can be used to justify "padding" to people that think software development (or any kind of work) is like digging a ditch or like an assembly line.

In real world projects you don't actually know "t", nor do you know how "p" and "n" are conditioned by other factors, nor is there any basis (IMHO) in reality to that "1.3" factor in front of "number of new <whatever's> being used."

It's a pity that in so many orgs people can't just be adults, trust each other, and recognize that work often takes unexpected turns.

rgblambda• 3 years ago

X - number of new tools, libraries, techniques, used in the process

How would you know this before starting dev work?

djtango• 3 years ago

new to the team, I suppose. Everyone on the team has shipped a rails heroku PG app? Then you have a low number of shinies.

Shipping a Vaticle + Haskell on nixOS in your own server farm?

Maybe that's more new tools for the team...

sokoloff3• 3 years ago

Why does zero new tools (X) add time?

Alternatively, why does one new tool add so little time?

gherkinnn• 3 years ago

The following point has stuck with me for half a year now.

What they actually want is "the earliest date you cannot currently prove to be infeasible"

https://news.ycombinator.com/item?id=35318124

regularfry7• 3 years ago

That echoes the book Waltzing With Bears, if I'm remembering it right.

fasteo• 3 years ago

1975: Fred Brook's wrote[1]:

“The bearing of a child takes nine months, no matter how many women are assigned.”

Can't get better than this

[1] https://en.wikipedia.org/wiki/The_Mythical_Man-Month

stavros• 3 years ago

I don't know, I've seen some 10x women do it in seven months, though the deliverable did suffer.

weinzierl• 3 years ago

But more and more women are working faster. Later preterm rates are on the rise for quite some time.

"The late preterm singleton rate rose at an average annual rate of 2% each year from 2014 to 2019 (from 5.67% to 6.32%). The decline in the late preterm rate between 2019 and 2020 (6.32% to 6.30%) was not significant."

https://www.cdc.gov/nchs/data/databriefs/db430.pdf

bgribble2• 3 years ago

I have even smart managers look me in the eye and say things like "can we parallelize parts of this? let's map out the dependencies."

EVERY EXTRA PERSON YOU ADD MAKES IT TAKE LONGER. The fastest delivery is a solo developer that you get out of their f**ing way and let them work.

datadrivenangel• 3 years ago

If you want to go fast, go alone.

If you want to go far, go with people.

paulsutter• 3 years ago

The only magic wand in software development is to simplify requirements. The requirements are always wrong: too broad, too vague, based on invalid assumptions

The real genius is to propose a simplified solution, by discarding some assumptions. This is the best and only way to shrink the schedule

bsenftner4• 3 years ago

This is why Professional Communications is so critical for software developers, and exactly why your manager absolutely does not want you to have such skills: you'll be able to explain why their requests are manipulative, unrealistic, and frankly pointy haired wishful nonsense.

geraldwhen• 3 years ago

Your workplace may be toxic. My manager celebrates simplification and cost reduction when it solves business problems.

masklinn• 3 years ago

The only magic wand in software development is to simplify requirements. The requirements are always wrong: too broad, too vague, based on invalid assumptions

I think it's less simplification and more precision and completeness. Obviously if you have simpler requirements they more complete and precise, but the requirement might not actually be simplifiable. In which case what you want is better specification.

"They write the right stuff" about the shuttle software group is basically a story about doing that: https://www.fastcompany.com/28121/they-write-right-stuff

bgribble2• 3 years ago

As a developer I hate "precise" and "complete" requirements. Usually these extremely detailed roadmaps are just fairy tales. They indicate a management and product mindset that thinks you can pre-chew a developer's food for them and make things more predictable.

In fact, what you are doing is tying the developer's hands and making it less possible for them to nimbly work around unforeseen obstacles or repurpose existing solutions without raising a "process exception" to reopen the spec or sizing of a work item.

Be clear about the goals but let the developer(s) who have their hands in the code make the decisions about how to implement it. That means you can't really roadmap a big project down to the minute, but those roadmaps were always lies so there is literally nothing lost except for some fantasy Gantt charts.

dsego2• 3 years ago

Oh, but we need the full search functionality right now, yes there are only tens of entries now but in a few years there will be thousands. And the designer will design all the search flows based on our twenty page product requirements doc, and we will include engineering to write stories and estimate the works once it's all planned and prepared.

crucialfelix• 3 years ago

Also some designers throw in too many features because they want to fill space in the design.

mmcnl6• 3 years ago

And devs are in the perfect position to take on this responsibility. They usually have sufficient domain knowledge and know what it takes to build stuff in this context.

marginalia_nu• 3 years ago

Yes. I very much agree. Not only are most software bugs actually requirements bugs, the speed you can build software with good requirements is absolutely bonkers.

I've seen a project go from an empty repo to production in two months with a set of requirements that were completely unambiguous and rock solid. I've also seen ambiguous and vacillating requirements drag out the implementation a ~30 LOC feature for months.

JoeAltmaier• 3 years ago

Contractor I know, always answers "Can you do it quicker and cheaper?" with "Yes. What do you want me to leave out?"

bdcravens2• 3 years ago

This assumes a developer whose workflow is more or less optimized.

jongjong2• 3 years ago

Unlike the meteorologist, the developer has the ability to bend reality a bit when it comes to estimates, but they can never bend reality in a way which makes it worthwhile. Cutting corners is almost always a mistake. It's a very short term move which may only make sense if the business is collapsing and looking for a quick exit.

smolder• 3 years ago

You could spend 15 years cutting every corner imaginable as a self-professed genius 1-man engineering team until everything becomes unsustainable, feature work is impossible due to frequent fires, the business is faltering, and you can't even understand your own code any longer. Then, quit as soon as a new hire comes in so you can't be held accountable for your quagmire by other engineers. I don't really understand why someone would do this, but I recently got to see it first hand. ;)

jongjong2• 3 years ago

Damn 15 years is a long time. I think the oldest ball of unmaintainable spaghetti code I saw was 3 years old and it was almost impossible to add or change anything. None of the developers who worked on it and had the most knowledge of it could explain how it worked, not even at a high level. Like they barely understood it better than non-tech end users.

jdlyga• 3 years ago

At least you get to estimate.

mattchamb• 3 years ago

We have a deadline and estimates, now all we need are the requirements...

zubairq• 3 years ago

I love these types of posts. Most of my career as a developer felt like being in a bazaar, where the buyer (manager) would constantly be trying to get the price of a carpet down (my work) without ever knowing exactly what type of carpet they wanted, but having a vague idea of a "quality" carpet in their head.

beardyw• 3 years ago

Never reduced an estimate (without change of scope) in my whole career. Didn't do me any harm.

praptak• 3 years ago

TBH missing estimates also didn't do me any harm. That's why I'm always tempted to agree... and then ignore all pressure to deliver.

"Your estimate, your problem"

ThinkBeat• 3 years ago

If developers did not approach projects with the goal of adding acronyms to their resumes and infuse every project with the latest cargo cult du jour it would improve the ability to predict timelines.

Pick boring technology, that the team is already comfortable with, when possible. Keep the teams as similar as possible, Keep running projects the same way, when possible

I am not saying it will get things perfect, but it will be an improvement.

GoToRO5• 3 years ago

Developers do not choose the tools. Not in agile/scrum companies. Heck, they are not even allowed to choose the variable names by themselves.

kaashif• 3 years ago

What? That seems like it would vary from company to company. My company does scrum and developers choose which technologies to use, which seems like it's probably common...

cityofdelusion• 3 years ago

The problem is that developers have a very strong incentive to add new technology to their resume, as their job is not guaranteed. I think most junior devs have seen some old hat at their first real job who codes in one, ancient tech stack; someone that they perceive as un-hirable if the economy takes a turn.

We all see the job listings out there and the tech they desire. It is self-preservation, and it is in direct conflict with what is best for the company itself. To use myself as an example: I have zero regrets with pushing for JavaScript over VBScript many years back, for moving from Microsoft HTA to React, or for moving from Yahoo's YUI to jQuery. Being infused with old tech can very severely limit your ability to survive. Most of my interviews after my first job were simply explaining/defending the ancient tech I had specialized in. It is all risk, no reward at the employee level.

Havoc• 3 years ago

Except the meteorologist has no inherent incentive to predict a specific outcome. A dev who will need to deliver against the resulting target deadline has a powerful incentive to overstate. Even more so if they think they’ll subsequently be pushed to revise downwards

Rubbish metaphor

throwaway091ba• 3 years ago

Whenever this estimation question comes up, developers rarely put themselves in the shoes of the business side, and try to understand why there needs to be an estimate, and why shorter is always better than longer. What they do instead, is try to protect their holy land of software development, and exacerbate the differences between engineers and "the others" - sarcasm and cynisism usually shine through at this time, and that's how you end up with unrealistic estimations.

I've been a developer, PO, manager, director, CTO, the whole thing. I'm still shocked by how most (not all, but most) developers are simply too disconnected from the reality that, yes, they do need to provide value, and yes, that value does have a time factor. Lucky are we as developers, that people actually ASK us how long it will take, and give us the opportunity to explain it, push back, and actually defend your estimates. The sad reality (at least from 90% of my career), is that developers are rarely able to actually engage in business-level conversations, and actually express their thoughts/ideas/concerns/proposals, in a way that it drives the conversation forward. In a way that helps PMs and managers actually see the complexities of the work, and engage in healthy cost/benefit discussions.

dlahoda• 3 years ago

why shorter is always better than longer?

egwor• 3 years ago

I came here to ask this too. I've had recent examples where the business has explicitly said the opposite (but we're long term greedy). I'm sure there are businesses on the verge of collapse where staying alive is the objective function. I'd be interested if there are other more common/healthy situations?

dubcanada• 3 years ago

The OP is talking about business, so having something done in 2 days versus 4 days is always better. Ignoring everything else, less time is less money.

sokoloff3• 3 years ago

Unless you’re in the business of “selling hours”, why wouldn’t having something valuable done more quickly (and thus at a lower expense) be better, all else being equal?

Sure, if you’re a contract dev shop who is marking up hours, then longer is better.

taneq2• 3 years ago

The missing link here is to separate the estimate from the quote. Don’t try and make devs estimate lower to win a job, have them estimate honestly and then if there’s a business motive to bid higher or lower, record that separately.

verve_rat4• 3 years ago

I agree with all the points you've made, but I would add that the PMs and managers and directors and whatnot are never that keen to help engineers out on this front.

It is a rare person indeed that can do software development and think (and talk) in business terms. As a dev, being able to talk in business terms about the problems you face in creating software is really, really handy.

But I can count on one hand the number of POs, directors, managers that want to engage in that conversation with developers. Most of the time a solution is thrown over the wall and developers are told to build a thing.

An actual conversation about a business problem between the people that actually have the problem and the people that will build the software that (hopefully) solves it happens way, way less often than it should.

WJW2• 3 years ago

In addition, any actual conversation wouldn't just require devs that can talk in business terms but also business people that can talk in development terms. Otherwise the only territory that can be usefully covered by both parties are the business requirements and the outcome will almost always be biased towards that.

GoToRO5• 3 years ago

Well then bussiness people are also disconnected from reality. If a developer can write code and estimate and deliver in time for bussiness, then he is not an employee. He is a founder. What you want is people that deliver like a founder but that don't get any share of the profits. You want gullible people.

mmcnl6• 3 years ago

Honestly, I think you are an unwilling prime example of a disconnected developer. Why don't you instead try to found common ground and work from there? Who says "business people" aren't capable of dealing with uncertainty? You are making a caricature of a very simple, reasonable request. We're all just people with the same goals. Stop trying to enlarge differences.

throwaway98797• 3 years ago

i envy you that you managed to live your life with this kind of belief

that’s like a sales guy closing a deal…

you did one piece of the puzzle and dealt with one type of headache

you clearly have no clue what founders actually do

bdcravens2• 3 years ago

The word you're looking for is stakeholder, not founder.

Nonetheless, do you believe the opposite is true? If a developer doesn't feel like they are adopting the perspective of the business, are they a disposable resource?

paulddraper4• 3 years ago

A founder is someone who starts a business.

It's not whatever you mentioned here.

b20000• 3 years ago

do developers own the business and will benefit the most of the upside?

Aeolun4• 3 years ago

What a weird thing to say. If you ask me how long it takes to grow a baby, and I say, 9 months. Am I not cooperating with the business when you want it in 6?

No amount of effort on either your or my part is going to make the baby appear faster.

diarrhea• 3 years ago

What if you push really hard though

e1g• 3 years ago

In that analogy, a far more common situation is the developer saying “I don’t know”, “depends on what kind of baby you want”, and “5 years and you’ll have a 1st grader”.

mmcnl6• 3 years ago

That's a bad analogy. Managing expectations is very rarely absolute or binary thing.

rrr_oh_man8• 3 years ago

Why do you need a baby?
Do you need to grow your own, or could you adopt?
Is it about birth itself? Does it have to be a human baby?
Does the baby need to be related to you?
What if we hire a baby actor?

…

lmm9• 3 years ago

developers rarely put themselves in the shoes of the business side, and try to understand why there needs to be an estimate

I put plenty of effort into trying to understand. 95% of the time there's no business reason. Most of the time someone just wants to put a number on their powerpoint for some organisational politics nonsense. Sometimes the business wants to decide whether to do thing A or thing B (in which case they have a legitimate need for a relative estimate, but not an absolute one). Occasionally there's a real deadline, in which case again they don't actually need an estimate, they need a "can we hit this date y/n" (or, more usefully, "what do we need to do to make this date").

I'm very happy to work as closely as possible with the business. The reason I'm writing software at all is usually to solve business needs, after all. But when it comes to estimation it really is a case of them being wrong and us being right. (The best businesspeople don't work in terms of estimates in the first place; I don't know if estimates used to work at some point in the past and have been cargo culted since, or what)

why shorter is always better than longer

If shorter is always better than longer then all my estimates are now 1 day. Does that makes things better?

23B115• 3 years ago

Most of the time someone just wants to put a number on their powerpoint for some organisational politics nonsense.

Yes. Thats how coalition-building, budgeting, and reporting works in business. Not saying it should dominate your schedule, but it's just how organizations work. Engineers/Developers are part of the org – not some special snowflakes that are above or beyond politics.

beremaki• 3 years ago

Most the time the only thing devs are allowed to interact with on the business side is a product/feature proposal with all assumptions already made.

If devs do not know the customers/users nor interact with them then they can't really argue about the proposal's assumptions, it defacto becomes a demand.

With experience devs see such proposals with skepticism. A significant amount of our output ends up being useless, no matter how fast or well it was built.

If you want devs to focus on value creation you have to make it their job, they have to take ownership of the whole thing. When a dev can help a user or a customer they tend to feel fantastic about it.

But truth is business people think devs are inept at doing that so most companies are structured in a way where the only agency devs have is how much time they have to do something.

gedy• 3 years ago

Whenever this estimation question comes up, developers rarely put themselves in the shoes of the business side

A big issue is that "business side", including UX, mostly have zero scrutiny of what they spent their time on or when important work will be completed. Whereas engineers get scrutinized about tasks by non-engineers who can't and won't understand.

And frankly, many times this hand-wringing about estimates is because product and UX took way too long to "plan" the work to begin with. So there's some natural resentment from engineers about this.

roenxi• 3 years ago

Everyone understands that why the business needs to an estimate and that shorter is better than longer. There is no ambiguity there at all. The complaint is the phrasing like the developer can know when it'll be finished. Someone's ability to deliver value quickly is unrelated to their ability to estimate how long it will take. They can get their estimate completely wrong and deliver huge value. And we all know if there was some way of estimating how long software tasks would take, software companies would hire a professional estimators for the same reason that software companies often develop product teams to negotiate what features a product should support. There is no point asking devs to do it. Oh course, no-one else can either and the devs will at least get the lower bound right so people bother them but the process is transparently stupid.

To know how long something will take it is necessary to list all the steps taken to do the thing. That just isn't possible in software development. Developers can come up with a lower bound for a given set of requirements. And I think everyone agrees that they could do an accurate estimate assuming nothing unexpected happens. Then, in 95-98% of projects, the estimate turns out to be under-calling how long a project will take. The "developer estimates" becomes a measure of how much fat the developer feels like putting in the system this project.

Asking for estimates completely misframes the conversation. The question is what problems does the business have now, what problems are likely to develop in 6 months, and some input from the developer on the cost-benefit of trying to solve those problems. Then people make some qualitative decisions with an eye on minimising risk. The best outcome after giving software estimates is that everyone ignores and forgets them - anything else destroys business value.

replyifuagree21• 3 years ago

if there was some way of estimating how long software tasks would take, software companies would hire a professional estimators

That's awesome. In my feistier days I would have used that at work!

mmcnl6• 3 years ago

I agree 100%. Too many software developers feel entitled and think they do all the hard work and everyone else should just try to understand their domain or get lost. This attitude will get you nowhere.

ResearchCode12• 3 years ago

That attitude works well in other professions. If you want to become a managing partner at a law form you are expected to have chops. Why should software engineers accept micromanagement by laymen?

CipherThrowaway4• 3 years ago

FWIW, some version of your rant occurs in almost every industry. Even doctors have hospital administrators complaining about how arrogant and non-business minded they are, how they are opportunistically defending their turf and so on. What you're talking about is not specific to devs but a general symptom of politics and friction between the different layers of an organization.

Devs always lean more cynical than the rest of the org, but the "prima donna devs refusing to acknowledge the need to deliver" schema only emerges in poorly managed organizations and teams. There is always some push and pull, but usually it's within a healthy balance.

makeitdouble3• 3 years ago

developers rarely put themselves in the shoes of the business side

The simplest solution to this is to make them an actual part of your business. Do your lead devs assist business meetings ? do the dev team get the numbers, get a look at the budget, work with you on the roadmap, look at the user research and brainstorm the features with the business and UX people ?

If not, why would you expect them to understand the business ?

The other side of that dev/business separation: as you put it, that creates a holy land of software development, as everyone has their own silo while expecting other specialists to be well versed into their own problematics.

I think many businesses are working dispite extremely siloed roles for their team members, and people tend to think that's an OK way of doing things as money keeps flowing in.

badwolf• 3 years ago

Bridging that gap can be difficult. I always try to include leads in business meetings, provide weekly reports on how their work is performing (do users actually like the feature that was built? Is it generating revenue for the company, etc...) I've found teams generally are excited at first, but then immediately start complaining about "more meetings," getting told "You're the PM, why are you asking me, you write the specs"

It definitely needs to be a 2-way bridge, and when both sides can and do come together, great things can happen!

replyifuagree21• 3 years ago

Meteorologists also don't put themselves in my shoes when I ask for sunshine.

And you'll be happy to know that these days I suss out the estimate the business team wants and give that estimate. Then carve out more time via scope exceptions. Then, because I can't carve out enough time to actually finish, deliver a release that looks finished to a QA team, but is actually riddled with customer operation interrupting performance problems, intermittent crashes, memory leaks and bugs.

Here is the very best part, the business team blames QA for not finding the problems.

kjkjadksj2• 3 years ago

Its also a little perverse how the solution is never “hey this estimate is too long, lets hire more staff so we can do the job well and finish on time.” Its always about squeezing more blood from the stone, burning out your employees and increasing your turnover rate.

RugnirViking• 3 years ago

"rarely able to actually engage"

I've always hated this sort of talk. The myth that some people are inherently creative, or inherently logic brained, or inherently buisness brained, or whatever, and never the twain shall meet.

I've seen a spectrum in most dev teams I've worked in. Those with good communication, those without. However, I've also spoken to sales, HR, etc people who paint the whole team with one brush and are afraid to come and speak to the scary code people. This, I'm afraid to say, is often because those people were also bad communicators.

I agree there needs to be more awareness of the buisness realities among developers (personally I think it leads to more fulfilled and happy developers, among other things), but I think that can't be placed entirely on developer's heads. They can't know how the sales team's meeting in morocco next week's call might affect things if they have no idea that the meeting is happening, who the client is, what that client means in terms of the industry, the likely things that client might value. They are adults. A couple of onboarding meetings, occasional cross-training does wonders.

And if they did know that? They might be able to quickly throw something together that has a good chance of really impressing that client. Or provide certain insight into what the company's solution actually does for the client.

GoToRO5• 3 years ago

If you ask for a lower estimate it means that you are providing an estimate. Why people that are not qualified to estimate, scum masters, team leads, product owners, provide estimates? The whole management structure is upside-down and then we wonder why software is crap and people quit.

tyingq2• 3 years ago

Dev teams have choices though. They can choose to use existing 3rd party code, services, etc, to accelerate development or not. They can choose some amount of non-functional requirements. They can choose the amount of "future proofing", abstraction, etc. And on and on...many choices that would drive timelines, trade speed for quality, longevity, maintainability, or cost, and so on.

danaris• 3 years ago

But unless that 3rd party code, and those services, have already been discovered, evaluated, and learned by that particular dev team, integrating them might take more time than building something from scratch that meets the specific requirements at hand.

And if it's built in-house, that means that in addition to being much more tailored to the organization's needs, it can be much more easily changed as those needs evolve.

This doesn't mean that I think it's always better to roll your own, of course; there are lots of instances where that counts as "reinventing the wheel." But it's absolutely not as simple as "just use something that's already out there and it will be faster and work just as well."

tyingq2• 3 years ago

I wasn't suggesting that example was a magic bullet. Just that it is one of many choices that drive an estimate...down OR up. I agree there are cases where 3rd party software doesn't help. I think it would be pretty rare for a team to have zero choices in their control that would change an estimate.

jeltz3• 3 years ago

Quite often using third party tools take longer time but still are worth it in the long term due yo lower maintaisnce and generally simpler tech stack.

nmstoker3• 3 years ago

I get the point, and with irresponsible parties (as is fairly widespread in most companies) there's a real risk here.

However the analogy of a meteorologist seems poor as that job is focused on predicting the weather - the typical dev is focused on operating in that weather and comparatively inexperienced in predicting with great accuracy.

What's frustrating as a stakeholder is ludicrous estimates, which don't even start with the work time, let alone end up with a realistic duration. This is particularly true (and frustrating) at the micro task level, an area I'm often requiring items that take at most 30 minute to complete and are usually things I could do in less time if only I had access... You get a weeks long estimate back, even when it's incurring a serious cost in production and falls in the drop everything category (which obviously one wants to avoid but does come up). I get that none of those 30 minute tasks will take 30 minute alone as there's testing and documentation to add but the more bs level the estimate, the more it damages the trust relationship.

Aeolun4• 3 years ago

To some extend, but there’s tasks that I could do in 30m in a company with 15 employees that I have still not accomplished after 2 months in our 15k employee enterprise.

wkat42423• 3 years ago

This so so much.

Some tasks take me 10 minutes but it takes me half a day to jump through all the hoops that our colleagues have thrown up. Excel approval sheets, annoying proxies with SSL inspection (try configuring all that in multiple docker containers), having no access to actually configure what I need to do so I constantly have to put in tickets to other teams..

The worst thing is when they then outsource the work and ask us why they can do it so much faster.... :X

briHass2• 3 years ago

Large orgs almost become like a bloated government in that way: groups start to construct little fiefdoms with rules and policies that are ostensibly constructed to improve quality. However, those rules end up becoming bludgeoning tools used by nefarious actors in those groups.

The real problem is that nobody ever steps back and asks: are all these rules actually helping to improve quality of the software. Is the cost of the reduced velocity and overhead actually worth it in the end.

Then, the org does layoffs and all that policy is still in place without the necessary people to supported the bloated workflow.

Veuxdo• 3 years ago

Linear scaling is more the exception than the rule, no? And it not just for "tech" either: it's unlikely you could learn the names of 15k employees in 2 months, for instance.

regularfry7• 3 years ago

I think there's an important detail you might have left out of your 30 minute example: are you asking for how long the effort on the specific task will take, or what the time gap will be between right now and the moment it's delivered? Because in almost all teams both are dominated by the task waiting for something, but in the latter case it's especially true. Actual hands-on-keyboard time is usually a rounding error compared to coordination and scheduling. Unless a team has put hard work into unintuitive ways of working, the average ticket will spend grossly more time waiting than actually being worked on. Not only that, but the team will be completely blind to the imbalance, and won't realise it matters.

rrr_oh_man8• 3 years ago

Unless a team has put hard work into unintuitive ways of working, the average ticket will spend grossly more time waiting than actually being worked on.

What do you mean by "unintuitive ways of working"?

Groxx• 3 years ago

Yeah, the 30 minute tasks would more frequently be quick if there was room for them.

You can have agile flexibility or you can have lists of tasks that you have attempted to minmax that people are tracked to finish. Not both. Flexibility costs significant down time, if you're not being given it then you're not being allowed to be flexible.

mannykannot2• 3 years ago

I have never had the misfortune to work in a place even remotely that dysfunctional, and I feel that there must be a considerable history behind it becoming that way.

orwin3• 3 years ago

Don't ask for 30 minutes tasks unless you have to (it's breaking the prod or something), it's inefficient for everyone involved.

I'm in a team with a lot of leeway. No one is counting my hours, no one external look at our productivity, but when we're needed, we don't have time to polish our code. When i have a '30 minute' task identified, I put it in our morning review, and ask if something adjacent should be done while I'm on the subject. If there is nothing, I'll still take the full day (except if it's a project I know really well, in that case I take half), and take half a day to skim the code, and another half to update it (small comment, version upgrade, code improvement, renaming variables).

Push your IC to do the same. Imo it's more time efficient, the new-ish IC use that time to learn the older code, and in the end you will have less legacy issues (unless you make a big change).

rrr_oh_man8• 3 years ago

Any downsides to this approach, from your experience?

nmstoker3• 3 years ago

Understood. I never do unless it were breaking prod or breaking major business processes.

Regular approaches, avoiding firefighting are essential to steady, stable states.

makeitdouble3• 3 years ago

Ludricrous estimates are usually a symptom of other organizational quirks.

I'd compare it to the military's $435 hammer [0], from the outside you'd think it makes no sense, but that's the logical end of a series of processes that all somehwat made sense on their own.

A common issue I've seen is devs having to put their head on the chopping block when making estimates. After the second or third time they get seriously punished for blowing pat deadlines, they'll happily go with around 10 times their own estimate. But there's so many other incentives where going with a "done in 2h" estimate is just a bad decision.

[0] https://www.washingtonpost.com/blogs/wonkblog/post/the-penta...

dahart2• 3 years ago

Oh wow, I had no idea the story of the $600 hammer was still around. This has been a talking point for like 40 years now, and it was a different number when I was a little kid. Turns out the story had been debunked at least 13 years before the article you posted was written, and is 25 years old now. The military never paid hundreds of dollars for a hammer, someone just averaged a bunch of financial R&D overhead and then someone else took the numbers out of context and spread it around. https://www.govexec.com/federal-news/1998/12/the-myth-of-the...

xorcist2• 3 years ago

30 minute to complete and are usually things I could do in less time

Why don't you? Surely there are ways of granting the required access in your organization?

If the answer is something akin to "not my job", then you have an organization that values intercommunicating pieces each with strict responsibilities. It should be expected that communication completely dominates output performance.

If properly tuned, such organizations can achieve good quality, and if the duties are well specified, also great throughput. But they will never have low latency, as turnaround time is sacrificed for other tings.

The example of a week long estimation for a trivial task is pretty much expected then. In a fully booked schedule, any new task is not likely to be scheduled for weeks. If that task then requires the attention of more than one person, because of the above fine grained responsibilities, those turnaround times really start to add up.

If that's not a good fit for the job at hand, the organization is just not suited for the task.

kayodelycaon2• 3 years ago

I feel this pain, I really do. I want to turn around to fix quickly.

The problem is unless you have fully-automated continuous deployment, 30 minutes is not 30 minutes. That 30 minute task needs to be vetted to ensure it doesn’t affect other departments, then it needs to be scheduled, announced, and deployed, which may involve 2 to 3 other people. As a scheduled task it’s closer to 2 hours across multiple people. As a hotfix or support ticket, it which becomes 4~6 hours of lost productivity for a hotfix if there is any kind of QA process beyond automated tests.

Add in six other people asking for “30 minute tasks” that have unknown impact on other people in the company and nothing will ever get done.

My team has workflows for hotfix changes, but it truly needs to be a drop-everything emergency that stops the company from operating. For all but the blindingly obvious, a department, head or higher, must make the request.

Not being able to turn around every urgent ticket is far less damaging than having a fix for one person cause problems for several other people or not delivering on large strategically-critical projects.

iimblack• 3 years ago

This is way too true. So many quick changes or fixes at my company have caused incidents, confusion, and more. That 30 minute fix quickly balloons into days of work and unhappy clients.

Even things that don’t blow up on those have so many hidden costs people don’t think about.

replyifuagree21• 3 years ago

Yep, these days I tend suss out the estimate the person is looking for because the relationship is actually more important to my career longevity. I mean, the estimate is very likely wrong anyway, so they might as well be happy for a bit!

This works because almost never is the true scope of the work known when the ask is made, so it is usually pretty easy to say later "hey, blah blah blah wasn't taken into account for the estimate." Having a good relationship from step one makes it pretty easy to carve out the extra time.

There are some more lizard brained people who play hardball, but as long as I was nice in step 1, my VP handles them. Not sure what I would do if I didn't have a decent VP!

c0pium6• 3 years ago

Not sure what I would do if I didn't have a decent VP!

Learn how to actually do your job?

It’s always interesting to see toxic positivity painted in such a favorable light. Very glad I don’t work with you.

replyifuagree21• 3 years ago

I promise you what you are experiencing is a management problem, not a dev problem. Devs absolutely love executing on creating easy to code software solutions to well defined problems. Many of us will work the weekend on that kind of work just to get the dopamine rush.

smcleod• 3 years ago

Estimates are just that - estimates.

More importantly they’re estimates of effort - not of time. If you estimate in time you’re tracking time over time and as such not your ability to estimate time.

Estimating within the team should be for the team, not for the business (directly).

dbalatero• 3 years ago

I think the biggest challenge I have is that people will immediately ask for estimates when the project is barely a paragraph description. On top of that, my feeling is always "it depends on how much tech debt is in the code after I look in there."

The only reasonable response I've had is "I need 1-2 days to both push you on solidifying these requirements, and stop & audit the codebase to look for any risks before starting".

Is there anything I could be doing better here?

coldtea• 3 years ago

Is there anything I could be doing better here?

Yes. Not give a fuck about the code debt and quality, and just rush out something that barely works. That will keep them satisfied.

paulryanrogers• 3 years ago

Having built a few of these and inherited a few, please don't. They become brittle and future changes become increasingly difficult, until velocity grinds to a halt. Then you're just firefighting constantly.

My guess is there is a happy medium between never changing and staying on the cutting edge. A place where you can ride the current of tech, FOSS, dev communities and talent pools.

If course what this looks like day to day and in pointing poker will vary. Ideally there is a seasoned architect on every team who can steer the biggest decisions away from the hazards.

gemstones• 3 years ago

I have found success with having a session with the PM where the goal is not to have complete, perfect cards, but at least one ticket for every thing you can think you will need to do on the project.

So you’ll have a bunch of one liner cards, but at smaller fidelity, like

- Make a bulk create API endpoint - Migrate data from old to new table

Then, if there are 5 or more cards there, make your estimate

((number_of_cards / number_of_devs) * est_business_days_per_card) + est_pto_days

It will not be accurate - but it will leave the PM and their boss feeling like the estimate was thought out and reasonable at the time, and any necessary delays will go over easier (“we estimated assuming every card was about the same number of days, but these two cards were large outliers that took longer than expected.”)

Much like the normal sprint process, but without the need to keep a track of sprint velocity beyond a gut feel.

VonGallifrey• 3 years ago

This is the problem I have at the moment as well:

Company Leadership asks for estimate with barely any information, I will then say that I need to learn more about the project and look into the codebase, leadership then says that they "just" need to have an estimate to approve this work and if they want to do this project at all. Around and around it goes until I give them a large estimate (which is large because of all the unknowns including the unknown scope) which is then too much and too expensive for leadership.

taneq2• 3 years ago

Reminds me of the time an estimator asked me how much it costs “to program a PLC.” I asked what the PLC had to do and they said “just a normal one.” Pretty sure I answered “probably between $5 and $100k.”

NegativeK3• 3 years ago

I was interviewing a CISO for a prior job. We asked how they would expand our team, given what we have and what we do. The candidate said that a typical team needs X, Y, and Z, but they really couldn't make an informed decision like that without being in the environment for at least a few months and seeing the way that things actually work.

My peers and I, who would report directly to the CISO, loved the answer. One of the CISO's potential peers on the interview panel thought that the candidate bombed the question, because "shouldn't they just know what's needed?"

gen220• 3 years ago

You’re doing the right thing, but you need to speak their language.

In Agile speak, that’s a 3 point spike ticket, for which the deliverable is a detailed set of requirements and deliverables with estimates with considered trade-offs. It’s a totally normal thing to do.

You can give an estimate before doing the spike, but maximally caveat it. Like “60% confidence it’ll take fewer than 3 weeks, 80% 5 weeks, 90% 6”.

I’d generally recommend refusing to give deadline estimates beyond a week or two (unless it’s absolutely necessary as it sometimes is), preferring piecemeal estimates (i.e. this project is composed of 7 deliverables each taking 1-2 days of work). Reason is that it might take 10 days of engineering work to do something, but due to shifting priorities etc., the calculus of computing a deadline is basically pointless.

If the “managers” don’t understand any of this, it’s never going to be peaceful unfortunately.

gregoriol• 3 years ago

This metaphor is wrong: meteorologists don't have any impact on the sunshine, whereas devs have direct impact on estimates.

In both cases, wrong estimates will generate problems for the stakeholders, but devs can make choices during the implementation that will influence the outcome and may in some ways mitigate the lower estimates, but meteorologists won't ever have any influence on the weather.

chiefalchemist• 3 years ago

I wish we could somehow get away from estimates where the expectation is precision and instead talk about a spectrum of possibilities (i.e., best case, worst case, and points in between). As the journey to the destination gets longer and more complex the range of possibilities increases. Why do we continue to pretend otherwise?

That aside, more accurate running scoring (if you will) would also help. Engineering is asked for an estimate but engineering knows that they don't have absolute complete control end to end of everything. Someone else somewhere along the line is going to cause delays, but the estimate stays fixed and engineering remains accountable. That's not helpful in the short term or long.

hoosieree2• 3 years ago

Typical action movie hacking scene:

    Leader: How long until you can hack the mainframe?
    Techie: The other hacker is really good; at least 2 hours.
    Leader: You have 1. Get it done!
    [commence flying around the 3d filesystem]

Whenever I watch a scene like this, I mentally add a voiceover for the techie:

    [Techie thinks]: My actual estimate was 20 minutes. I can probably get it done in about 50, then I need to fly in the 3d filesystem for 10 more minutes looking busy so Leader doesn't get any big ideas.

zargon• 3 years ago

https://wiki.c2.com/?ScottyFactor

hoosieree2• 3 years ago

C2 has an article for everything!

BurningFrog• 3 years ago

So happy to work without estimates for decades.

We just work on our tasks until they're done.

ResearchCode12• 3 years ago

Why are you pushing software engineers for "estimates"? You don't ask mathematicians how long that conjecture will take to prove. It's done when it's done.

andyjohnson02• 3 years ago

Because developing software is almost always an economic activity, and proving maths conjectures almost always isn't.

ResearchCode12• 3 years ago

There is no evidence that you get better economic outcomes from micromanaging software engineers, and not for the lack of trying.

kjkjadksj2• 3 years ago

While thats true, business leaders still need to realize developing software is not the same sort of economic activity as running a horseshoe press or something. Machine can’t just be ran faster. You can’t also just plug another machine in the wall and expect it to know exactly what to do and double your output. Roadblocks often emerge that cannot be foreseen at all short of taking even more time to speculate on these potential blocks down the road.

Certain jobs do have these estimates better managed. For example, tunnel construction often hits unknown things underground that delays the project substantially in time and money. However this is par for the course with tunnel construction and such delays are even expected at this point.

gardenhedge2• 3 years ago

Estimates help planning. The problem is that they often travel through a company and become immovable deadlines.

ResearchCode12• 3 years ago

Planning too often is also a problem. You should not do it more often than every three to six months.

latency-guy22• 3 years ago

Probably because software engineers are not mathematicians. Also, you're not doing foundational research or breaking away at the edge of human knowledge either. Similarly, mathematicians are not immune to deadlines either.

ResearchCode12• 3 years ago

Software engineers are not assembly line laborers developing x cogs per hour either. There is no evidence that micromanaging software projects works.

Tenured mathematicians are immune to deadlines, and non-tenured ones don't "story point" conjectures. Your PI does not usually make you submit daily status reports. Targeting a submission date three to six months ahead and trying again if it doesn't work out is a framework that would work in software engineering too.

dtgriscom• 3 years ago

My manager once gave me a succinct method for accurately estimating project times:

1. List all the necessary tasks

2. Estimate the time for each task

3. Add up all the times

4. Multiply by π

If using unknown technology, that last step should be "multiple by π^2".

jvans• 3 years ago

The problem is not with estimates themselves, but on giving point estimates. A better way of saying something will take 2 weeks, is that there's a 80% chance this takes less than weeks, 15% chance it takes 2-4 weeks and 5% chance 4+. But people have a hard time wrestling with uncertainty so they'd rather a point estimate that's wrong but makes them feel like they understand the situation

steveBK123• 3 years ago

The correct conversation is "what can we remove / what can I do / what can we re-prioritized / what else is in the way" to get some version of this ask earlier.

Simply bullying for a lower estimate, which is what I see 90% of the time is idiotic. Basically demanding to be negatively surprised later when the estimate slips rather than positive surprised when the dev is able to beat their initial estimate.

The first conversation requires empathy while the second conversation is a pure power flex. So it is unsurprising which we get more of.

zoomablemind• 3 years ago

Pushing for lower estimates is generally a sign of dysfunctional project manager.

This is when the PM does not have practical knowledge of existing obstacles to the project flow or the implications of external dependencies (intra team included).

This is a set up for throwing the team under the bus in case the schedule derails.

PM is supposed to harmonize the objectives and abilities, not manufacture the curves.

jalapenos2• 3 years ago

It's more Machiavellian than that. What the middleman wants is a heads I win, tails you lose deal.

He wants to present a low number, to encourage whoever he's dealing with on his end to do what he wants, gaining the benefit from that.

So he'll use every technique under the sun to encourage devs to give him a number he likes more, while never making it look like an order or coercion (which would make it his number - spoiling the whole play).

But when it inevitably takes much longer, he can point at the numbers the devs provided and say he was just communicating what they told him, so he's not responsible.

The only language these types understand is for requests for estimates to be "reviewed" to result in them always going up, to send a message.

epolanski• 3 years ago

I swear I hate this estimates thing so hard.

For many reasons:

1) Estimations should be useful so business can adapt. In reality there's no adaptation of any sort, your PM will get the stick from its own boss that stuff needs to be ready by this or that more-or-less vague deadline. Thus, what am I estimating for if you don't care about my estimation anyway?

2) There are no incentives for teams ultimately to estimate anything realistically. What do you get for being accurate? A medal? In fact, all incentives go towards inflating the amount of work through estimates.

3) Ultimately all this dancing of estimates and rituals is nothing else but stuff that management embraces to appear more effectful and impactful than it really is.

jalapenos2• 3 years ago

Most impressive statement I ever heard said in a meeting between management and engineers about a project's progress was a long-tenured dev saying "it'll be done when it's done", followed by silence, and then they let it be.

To this day I still don't know how this event came to pass.

replyifuagree21• 3 years ago

Yeah if you estimate realistically many companies have a culture that will punish you for not being a team player.

2devnull• 3 years ago

But it’s easy working for such people once you identify them. They are “goes to 11” people. Like that amp in spinal tap you just make your regular output max level be a 9, then you have room to go 1 more when they want you to. Of course that means working slower than you otherwise would. But if they want a dev that “goes to 11” it’s pretty obvious to some of us that there’s only one way that works.

nine_zeros7• 3 years ago

This is very true. And this is exactly my manager and the skip - pushing arbitrary deadlines, not because some customer is waiting for it, but because they want to look good to their own bosses. When the estimate inevitably fails, they all raise their hands and start pipping people for their own poor estimation.

As an engineer, imagine living under this constant stress, missing time with your family and friends, and for what? Just to make your own manager's incompetent estimation look good?

jghn2• 3 years ago

Sometimes, but not always.

I've been on both sides of this situation. As an engineer I'm always adamant - yep, no way this could be done any faster and please stop pressuring me to just get the number you want to hear. It'll be done when it's done, and it'll be robust and good. Now please go away and let me cook.

But when I've been the manager pushing for smaller estimates, it's been because the business realities were that delivering *something* in a given time frame is critical. And if it requires making a house of cards and cutting corners, well at least we'll have survived long enough to deal with that problem later. And when I've been in that situation I received the usual pushback from engineering - the same pushback I would give in their shoes - that this is a terrible idea, will doom us to fail in the future, and we need to put in the leg work now to avoid future pain.

I've gone back to being an engineer but that experience as a manager has helped me quite a bit when dealing with this sort of divide.

marcosdumay3• 3 years ago

If you need a stable software released by Christmas, you go to your developers and say "people, we need to release a stable version of this by Christmas".

You don't say "hey, how long do you need to do X, Y, and Z? Oh, no, that's too much time, how can you shorten it?"

ghusto2• 3 years ago

It is entirely reasonable for the business to say "we need X in Y weeks" — it still might not be possible, most of the time engineers can make _something_.

What's unreasonable is saying "we need X in Y weeks, and it needs to be done properly". It will take a certain amount of time to do anything properly, and that doesn't change with pressure.

verve_rat4• 3 years ago

What you are describing is shit managers.

If corners need to be cut for valid business reasons then there shouldn't be any real push back from the devs, because they have the business context laid out for them.

Every dev I've ever worked with will say "yup, I understand. I might not like it, but I understand" when given the context of pushes for quicker delivery.

But that requires understanding on both side that you are sacrificing quality to hit a date, and that has its own costs.

Mostly this all boils down to: talk to people like they are you colleagues, don't order them around, find a solution together.

replyifuagree21• 3 years ago

Your are correct in the majority of places where developers work. And this is simply because most developers work under legacy management where they are siloed off from the business - so typical Machiavellian silo on silo violence is employed to get one silo to commit to the desires of another silo.

It's crazy because the customer gets totally hosed by bad software implementations, and if good working software is actually important to the future of the business, a slow march towards bankruptcy happens.

P_I_Staker2• 3 years ago

Yeah, this part is getting lost and there's a lot of apologists here. One of the oldest tricks in the book is to create a vision, make a promise, and then say "I did my job, now engineering just has to do theirs"

I'm reminded of a manager that would add features as I was finalizing a release, sometimes hours before without telling me. He would even add features to releases that already happened. In his mind, he seemed to think that he could just attach the features to a release, and bam. it's done!

fuzzfactor• 3 years ago

More like a clueless "leader" demanding an earlier sunrise.

If he's going to want an earlier sunrise, he's going to need to shave off a good portion of the still-dark Earth that's standing in the way and he's going to need to get it done before dawn.

The team can do their part after that.

corry• 3 years ago

“Pushing sales people to increase their amount of sales/quota is like asking meteorologists for sunshine”.

Hmmm it doesn’t seem unreasonable in that context? You’re really asking people to work more effectively, to accomplish the same amount of work more quickly.

It’s like asking sales people what their quota should be. They pick a number that is no-brainer hittable, because there is a lot of complexity and many unknown variables in getting deals signed, so to prevent looking bad they’ll pad their number. But their no-brainer number is below what the business needs.

So you tell them their quota is going to be a bit higher. They’ll have to stretch to hit it.

And it’s even MORE important since their comp is DIRECTLY tied to hitting that number.

And yet sales people aren’t writing article after article about how self-set quotas are sacrosanct, should only settable by sales people themselves, and how clueless management is to try to get more performance above the no-brainer target.

lukevp• 3 years ago

Isn’t sales a numbers game for the most part? Like you can convert 10% of leads, so if I need 5 conversions instead of 4, I need to call ~10 more people?

A better comparison to software I think would be construction of a novel building. Try constructing a geodesic dome house with no experience, and little knowledge of the issues you might run into, but then you’re asked for accurate estimates and then pressured to shorten them.

paulddraper4• 3 years ago

I need to call ~10 more people?

I need to write 10 more lines, code for 10 for minutes, etc.

ghaff2• 3 years ago

Isn’t sales a numbers game for the most part?

At some level. But numbers aren't created equal and sales reps aren't usually supposed to be calling numbers out of a telephone book. Depending on the type of sales rep, they're hopefully reaching out to people who have been qualified to some degree. The email I got from a sales rep at my own company on Friday afternoon asking for a call about my requirements? That wasn't a well-qualified lead for whatever reason. (Not their fault; I'm sure they're just working from a list.)

paulcole4• 3 years ago

There’s a consistent belief here that Programming Isn’t Like Other Work™ and that you can’t estimate it, it’s so mentally taxing that you can’t do it for more than a few minutes at a time in complete silence, and that it’s closer to Da Vinci sculpting the Sistine Chapel than kludging together a few APIs.

It’s fun to think you’re special and easy to do when you’re paid a shitload of money.

replyifuagree21• 3 years ago

Programming is like some kinds of work.

It is very much unlike operating an established manufacturing facility. But, about two thirds of dev work has a lot of parallels with creating a new manufacturing facility that manufactures a new kind of thing using new materials and techniques. The primary parallel is that a new facility requires a lot of discovery. Whereas if operating an existing facility constantly required a lot of discovery that disrupted operations it is likely the business team would pivot to something more lucrative.

Sadly most developers work in companies that have a manufacturing management system, which is inappropriate for managing development work, primarily because of pressure+timeline patterns typically applied via silo on silo kingdom building.

happytoexplain• 3 years ago

This is a bitter exaggeration. Programming is indeed distinctly unlike almost all other work that we have built experience managing as a society. It might be more accurate to say that it combines properties from other existing types of work that are not seen combined in any other type of work.

paulddraper4• 3 years ago

There's some truth to what you say.

The problem is that sales can be objectively measured by management. In units.

How does management measure development output?

It can be done, but it take an experienced eng leader to do it.

mjfisher• 3 years ago

The difference is that lowering the estimate for a given amount of work doesn't actually get it done quicker - it just means you have a more unrealistic understanding of the timelines.

You can absolutely work to find other creative solutions to the same problems, or understand what scope is acceptable to cut to meet some goal. That's very different from "I want you to do exactly the same work but just do it faster".

thfuran3• 3 years ago

How is that different from arbitrarily raising quotas?

camhart2• 3 years ago

If your stories are so well defined the dev doesn't have any decisions to make in the process of coding, then they're more of a glorified type writer than a dev.

There's plenty of decisions devs make that impact how quickly they deliver a solution.

jnovek• 3 years ago

It’s not at all like sales quotas. The salesperson’s upside is directly linked to their quota, they are incentivized to fudge it as much as they can.

What’s the incentive for a developer to inflate their estimate? The only reason I have to inflate an estimate is if I know some non-engineer boss-type is going to swoop in and try to convince me to lower it.

bloopernova• 3 years ago

Incentive to increase estimate might be:

Deliver under estimate and get a bonus, raise, influence, or just plain old "well done"

Be lazy and only work half the time while delivering "on time".

Only work on the project half the time, spending the other half on something more worthy/interesting.

ghaff2• 3 years ago

What’s the incentive for a developer to inflate their estimate?

Under-promise. Over-deliver. I'm not doing software development most of the time but it absolutely works out better for everyone concerned if I get things done on or ahead of schedule without mostly having to resort to a lot of unnatural acts to do so. If there's a real need for something faster, I'll tell people I'll do my best and (usually) I can get there absent blockers from dependencies. But I try to manage things so that I can meet/beat estimates sanely. It probably helps that people think I work quickly even given some sandbagging.

k1t• 3 years ago

I feel the sales analogy is quite general (hit a quarterly/annual quota) but the engineering example is talking about a specific piece of functionality.

If you asked the sales team about a specific deal and they said "We estimate a 70% chance of closing the deal. It'll bring in about $5m in ARR."

If management responded "Could you make that 80% and $7m ARR?" I think that would be a closer analogy.

Sure it might be possible to improve the odds of closing and jack the price up at the same time - just like it might be possible to complete that feature in half the time - but somebody will have to make some major changes or concessions somewhere to make it happen.

dappermanneke• 3 years ago

great analogy but why doesn’t anyone pay me more for crunching out more tickets?

replyifuagree21• 3 years ago

Because you'll figure out how to crunch enough tickets for a minivan!

https://devhumor.com/media/dilbert-s-team-writes-a-minivan

ATMLOTTOBEER• 3 years ago

Good take. We don’t get any % of our marginal profit

watwut• 3 years ago

“Pushing sales people to increase their amount of sales/quota is like asking meteorologists for sunshine”.

Not really, because those are not estimates. Also, consequences are different. With programmers, consequence is typically very buggy and hard to maintain software.

With sales, the consequence is a lot of fraud, followed by firing of every who is not comiting fraud and then even more fraud.

replyifuagree21• 3 years ago

You forgot elk dinners at nice restaurants! I'll never forget when CA threw everyone parties to celebrate the sale of software the company couldn't use.

P.S. Not really, you covered it nicely under fraud

ajb• 3 years ago

The difference is that on average devs already underestimate, even when they try not to.

ballenf• 3 years ago

It's totally valid to push devs to get a ticket done faster when there's real pressure. It's much better to finish a ticket under estimate than turn estimates into aspirations.

The best case is to:

- line up the work in order of priority, taking into account prerequisites

- have sufficient stories in a ready for dev state

- during crunch time, be strategic about ticket assignment (you pay for this in the long term with a less-well-rounded team, so be careful)

- make sure to evaluate every feature to ensure that there are no "nice to haves" mixed in (when under time pressure), or move them to bottom of backlog

- selectively consider consulting with other teams, outside experts (but be sure to really time box this tightly and cut it off once work is under way)

- remove extraneous meetings & distractions; empower devs to decline meetings / block calendars

- borrow from the future by raising the bar on refactoring (ie, only when cost-benefit clearly pays for itself before deadline)

- be very careful that you don't make this approach the standard way of working

replyifuagree21• 3 years ago

be very careful that you don't make this approach the standard way of working

Legacy management steeped in manufacturing has entered the chat!

mannykannot2• 3 years ago

Hmmm it doesn’t seem unreasonable in that context?

Asking meteorologists for sunshine is unequivocally unreasonable, so what you are saying here, I believe, is that the analogy does not apply to sales people, and arguably not in the case of devs either - which I agree with, up to an ill-defined point where wishes lose any contact with reality in any circumstance.

marcosdumay3• 3 years ago

“Pushing sales people to increase their amount of sales/quota is like asking meteorologists for sunshine”.

This would be perfectly true if you replace it for a sales estimate, instead of quota.

The problem here is incompetent managers lying to inexperienced developers to get them into an expensive contractual obligation. It's borderline fraud, and yes, that means working with that manager is something to be avoided.

But going to a developer and plainly demanding him to finish the work on some time can be as perfectly fine as doing the same with sales people.

lamontcg2• 3 years ago

“Pushing sales people to increase their amount of sales/quota is like asking meteorologists for sunshine”.

Depending on the economic climate and the situation of the company in the marketplace this may be accurate.

If you've got good sales people that are already selling as hard as they can't you won't be able to squeeze much more out of them if the economy tanks and nobody wants your product.

I'm sure there are sales people who have quit due to "the beatings will continue until the morale improves" situations where their quotas keep going up, which cuts their bonuses, effectively acting like a salary cut, in a bad company.

pixl972• 3 years ago

Heh, have we already forgot what happened with Wells Fargo? We need to upsale 10 accounts a day? Random accounts it is!

https://www.justice.gov/opa/pr/wells-fargo-agrees-pay-3-bill...

hyperpape• 3 years ago

I'm tempted to be sarcastic about it, but it's surprising to me that no has mentioned sales quotas being connected to bad behavior. The most important kind is deceptive behavior to customers, and not just the "ordinary, good for the company kind". I mean making promises the company can't keep, or selling future features that require a deathmarch, with the attendant loss of quality/sustainability, even if the C-level doesn't see it.

This isn't to argue that we should just believe developer estimates unconditionally. That's a bigger rabbit hole that I'm too tired to go down right now.

rukuu001• 3 years ago

Yeah I think of sales people like farmers - there’s a lot they have to get right to get a good crop, but if conditions are poor, nobody gets anything.

yihtserns• 3 years ago

“Pushing sales people to increase their amount of sales/quota is like asking meteorologists for sunshine”. Hmmm it doesn’t seem unreasonable in that context? You’re really asking people to work more effectively, to accomplish the same amount of work more quickly.

Sales quota is a target, estimate is not a target.

And yet sales people aren’t writing article after article about how self-set quotas are sacrosanct, should only settable by sales people themselves, and how clueless management is to try to get more performance above the no-brainer target.

You mean you've never came across any post where people complain about unreasonable/unrealistic sales quota?

Spooky23• 3 years ago

This isn’t going to be a popular take, but this is just wrong.

Developers will often plan out a cathedral when what’s needed is a garage. Usually this is due to a misunderstanding of the requirements, or an inability of the requestor to formulate or express them. Also, developers are notoriously bad at forecasting work product and the numbers they deliver usually have a tenuous link to reality.

The conversation that starts with “We don’t have 6 months, how do we deliver this by 12/31?” is ultimately a hashing out of what the requirements are. When it’s a cool tech driven story, we call it “an MVP”. When it’s driven by the business, the author considers it yelling at the weatherman.

charles_f3• 3 years ago

Sorry to be a stickler but this is a heavy editorialization of the title.

The original title is "Someone saying 'No, it's less effort than that!'?".

The current HN title isn't even a proper quote of the article, the quote is

Pushing for a lower estimate is like negotiating better weather with the meteorologist!

riazrizvi• 3 years ago

Sometimes. Or the estimator is fixated on an extent of scope/depth that is not intended by the stakeholders at the initial stage. Or sometimes the estimator is baking in extra time that will get filled whether or not it’s necessary.

23B115• 3 years ago

My favorite bit of this argument is the presumption of honesty, accuracy, or transparency on the part of developers. Someone in the estimation process is always protecting themselves, packing on a little margin, or fudging the numbers. It's nothing to get upset about, it's just normal human behavior, happens in all industries.

For this reason alone, I always kick estimates back down and amazingly they almost always come back better-optimized – usually because some trusted graybeard engineer, who has been on both 'sides' of the business, steps in and cleans it up based on his experience.

justin_oaks• 3 years ago

Estimates aren't deadlines. If we're talking estimates then we should also talk about accuracy and precision.

I can give a low estimate if you're ok understanding that it's not a deadline and that is has astonishing low accuracy.

Estimates indicate that there's a probability that the time required could be more OR less. Choosing the deadline to be exactly the same as the estimate is ignoring the probability that the the task will take longer.

camhart2• 3 years ago

I disagree. Engineers have a habit of over engineering. Businesses have a habit of introducing too much process, too many meetings, too many layers between the end user and the engineer building.

A lot can be done most of the time to help devs optimize to deliver quickly. However, most businesses get stuck in their ways, struggle to give sufficient autonomy, and... sometimes get burned by giving too much to a dev when they aren't yet ready for it.

In short, getting efficiency "right" is a balancing act, and each "story" could be unique which makes it difficult to balance well consistently.

In my experience, don't get too caught up with estimates. Devs do need goals (even artificial ones) to help focus effort and prevent too much "bad" distraction (sometimes distraction is exactly what they need though--stepping away from the problem for some amount of time can help them look at it differently).

Give estimates. Motivate with goals. Build a real team environment where delivering is contagious. Its actually much harder to do than say, and I'd guess many devs have never experienced this before.

charles_f3• 3 years ago

Engineers have a habit of over engineering

Developers have one. It's in most academic definition of engineering that the job is to produce the cheapest design that will do the job safely.

Devs also have a habit of underestimating, which puts them under pressure once the date has came and gone.

charles_f3• 3 years ago

I link with the article, I usually call predictions a forecast, and not estimates, because you don't get angry at a meteorologist.

I have produced estimates for almost 20y now, and boy do I hate that. There's multiple layers to it.

This post touches the nefarious one. Sometimes yes, someone wishes something would come sooner and will shake the tree to see what happens. Sometimes there's actually a reason for it - be it budget, customer related, event related, etc. Sometimes someone knows better, because the feature or project is similar to another that was shorter.

When someone discusses estimates with an underlying motive other than their experience and surprise at the cost, I usually enter a discussion where I produce the evidence for our numbers and justify what we are telling.

It highly depends on why we produce estimates in the first place. If it's for budget or planning, I couldn't care less to reduce estimate, since these exercises are pointless in nature in my experience (the budget or planning is usually rendered moot within weeks of being approved).

If its to predict delivery dates, I'm usually very conservative, note that I am not in the art of divination, and that reducing estimates is a risk in itself if anything bad happens. When people are acting on bad faith, documenting stuff usually tames things a little. Unless things are very simple and predictable, I also usually provide several dates with confidence indices. This is a framework that's much harder to negotiate, and give some information to whomever "needs" those dates. It helps reducing the pressure a bit while being non committal and leaving room for error (and I never give a 100% confidence).

TBH, I don't think I've ever been in trouble for "being late", especially because I have always been able to explain that we weren't late, we just gave an incorrect date in the first place.

piinbinary• 3 years ago

I agree: https://jeremymikkola.com/posts/2021_10_11_weather_and_estim...

dasil003• 3 years ago

This article is extremely weak, pandering to engineers beset by clueless pointy-hair antics, without acknowledging that engineers can suffer from their own blind spots, regardless of whether stakeholders have the technical background to understand it or not.

The elephant in the room is this: a team can not produce good work without both competence and trust in equal measure. An immature engineer may assume a business stakeholder is dumb because they don't understand or engage on technical details, an immature business stakeholder may assume that pressure and threats can yield quality work. In both cases, the immature individuals are putting their energy into counter-productive hand-wringing.

But now here's where it gets hard: trust can't be blind and incompetence exists. The straw man analogy that content of estimates are somehow immutable and unavoidable facts like the weather demonstrates an incredible lack of agency and resourcefulness. We are talking about humans working together to solve problems and build things, we have incredible latitude on how we want to approach things. This viewpoint reeks of learned helplessness. Look at the proposed solutions:

In these cases, discuss with your stakeholders: why the estimated effort is this much? what part of the story takes the most time? where are the biggest unknowns? In addition, discuss ways to: slice up the story and deliver it in multiple parts, validate each part early, preferably using prototypes

Do you see the assumed constraint? There is no discussion of the problem to be solved or job to be done. Often in these cases you have a non-technical person prescribing a solution that doesn't make sense. If that's the case, it can only be solved by an engineer who has communication skills and credibility to discuss a better approach to the problem. Assuming that a user story passed down to the team is somehow sacrosanct is the type of process-oriented dysfunction that tanks morale and leads to impotent teams.

mardifoufs• 3 years ago

Oh my god thank you. Software engineering seems to be the only field where it seems like these types of super weird arguments about being too special or unique to follow or apply any business process are common, coupled with a vibe of "we are way smarter than everyone else".

Why are these people surprised that other stakeholders won't just accept a "trust me bro, it's ready when it's ready you just have to go with it" when nothing else works like that in the business world.

smokel• 3 years ago

I'm sometimes a bit ashamed of the IT sector as a whole. I have been programming professionally for more than 20 years, but I have not seen much improvement in time to delivery. For each step forward, we seem to be taking two steps back. I can't blame the developers, but I wonder who to blame instead.

The first suspect is: the internet. It may seem like a great invention, but having machines connected at all times, without formal restrictions, results in terrible security problems. Which have to be fixed. Which takes enormous amounts of time.

The second one is related to that, and that is the idea that we have to continuously upgrade everything to the latest fad. As one consequence, we are somehow stuck with a weird common ground for user interfaces defined by web browsers, which leads to overly complex software.

What most people often want is just a push button to send a message to some other system. Both companies and governments alike seem to be paying billions of dollars for that. Because it is all so extremely complex, and people are somehow buying that.

My understanding is that the industry is happy making a lot of money, so there could be limited incentive to change things for the better. However, for some other odd reason, most ordinary people try to avoid technology like the plague, and pride themselves in not understanding how computers work, yet unknowingly spend a big percentage of their tax money on exactly that lack of understanding.

I am still extremely thankful for the likes of Richard Stallman for starting the free software movement. Unfortunately, delivering software is only one (small) part of the problem. Embedding computers in human processes is a whole different ballgame. Can we perhaps have some kind of "free management foundation" as well?

I actually reread the above rant, and I fear for the downvotes, but perhaps someone understands what I am on about and has a good tip to ease my mind.

alanfranz• 3 years ago

but I have not seen much improvement in time to delivery.

Is this true, by the way, or it’s just our hedonistic treadmill?

Nowadays it’s extra fast to deliver and serve a lot of functionalities worldwide. Thing that would require a dev team are handled by a free saas out of the box.

But our implied non-functional requirements have grown exponentially. Twenty years ago, if a business critical software was offline for one day a month, it wasn’t a big issue. Today, if Facebook is offline for an hour it’ll make headlines on major newspapers.

Expectations just evolved. And writing working software over multiple layers of mess is as difficult as ever. “Precise estimation” is just a misnomer.

verve_rat4• 3 years ago

And the expectation that every business should act like they are facebook.

No, if your system goes off line for 20 hours a year barely anyone will notice, it will have way, way less impact to your business than spending the money to make sure that doesn't happen.

Arcanum-XIII• 3 years ago

Honestly, the complexity of most systems I've worked on those last 15 years has only grown. Everything require umpteen libraries to show a char on screen (and be inefficient at that). We're still blocked in the 80's for a lot of protocols because of backward compatibility with a ton of hack on top of it. We have built tool on top of other tool to manage the mess we've created, that no one understand at the end.

That's where we're losing time. Dealing with an inherited mess.

mumblemumble• 3 years ago

I think that it might even be worse than asking a meteorologist for sunshine. Because asking a meteorologist for sunshine has no conceivable influence on the weather, but putting a thumb on the estimation process can absolutely alter the design of the system. And that, in turn, can alter the overall effort and delivery date.

Whether the influence is positive or negative seems to depend a lot on the details of how you do it. I think, though, that the Extreme Programming community was on to something when they suggested that demanding more meticulous up-front technical design invites overengineering and ultimately makes things take longer. Unfortunately, that's often what happens when managers directly push back on estimates.

I would advocate for something more like a feedback cycle: at the end of every milestone or iteration, the team should compare how long work actually took to their estimates, and discuss the factors that may (or may not!) have contributed to any severe under- or overestimate. That process should improve the quality of estimates over time, and help the team to get better at focusing on the important factors in producing a quality estimate. And it will improve trust, too - I've noticed that it's common for teams that don't do something like this to bicker over estimates rather than collaborating on them.

And then, with all that established, it finally becomes possible for the team to reliably focus attention on the only way to actually reduce development costs without cutting corners: scope management and negotiation.

theptip• 3 years ago

I dislike the framing here, it disempowers the team and sets up a hostile lens towards stakeholders.

As the product team, you are in general optimizing between quality, scope, and timeline. Pick values for two, the other one will be determined. So if a stakeholder communicates a timeline constraint, you can work with them to achieve it by cutting quality or scope. For example if the urgency is that they need to give a customer demo, maybe a moving skeleton prototype, or at least delivering an iteration without all the integration tests would be appropriate (quality). Or maybe you can chop the deliverable into two milestones and ship the features they urgently need sooner (scope).

I acknowledge that in some cases there is just an asshole who doesn’t know what they are talking about, trying to inject urgency. But in many cases, if you actually empathize with the stakeholder and try to figure out what they are really communicating, you can find the underlying issue and modify your deliverables accordingly. This is what it looks like to be a high-performing team.

The idea that the timeline is out of your control is asinine, and will make stakeholders distrustful, since the idea is obviously nonsense (or if it’s true, the team is adrift). I strongly advise you to never use this language or philosophy in your stakeholder interactions.

pfsalter• 3 years ago

Completely agree, the article reads more like someone who thinks they are doing research rather than development. There's no esoteric perfect form for software that needs to be discovered, there's a set of patterns and structures that can be learned before the project starts.

Analogies are often unhelpful because people argue about the analogies instead of the actual problem at hand. If you can't communicate why these things are hard, and why 'do it faster' won't always get results, you need to get better at dev management.

Too• 3 years ago

Did anyone ever get asked to simply make the estimate lower? Without any other context? That never happened to me, it sounds extremely immature.

Feedback that you don’t agree with the estimate on the other hand, happens all the time. This is a completely different thing than a hollow request for “lower plx”.

Good stakeholders often do have a good idea of how long time things take. Maybe they worked as dev before, or with other clients. Leaving the estimation exclusively for the well oiled hero-team with perfectly calibrated velocity and ponies coming out of their retrospectives, as the article portrays it, isn’t always ideal either. Some tasks are new and unknown to them too, and honestly not all teams are that perfect. There needs to be a two-way dialogue about scope contra timing.

pc86• 3 years ago

TLDR - Yes, but from a crazy person.

Yes, in the most toxic place I ever worked. Gee, those are probably related, huh? The owner of the company was crazy. Not in a hyperbolic "oh yeah she's nuts" way but in a "she's either taken too much medication or not enough because she's unstable." Some of my favorite anecdotes, starting with one relevant to your comment:

1. After I provided an estimate of N weeks for a project, her response was "no it needs to be done faster than that." Okay, what features do you want to remove? What can be added after launch? "Everything is critically important and has to be available at launch, I thought it would take a day or two not weeks!" Finally she just wrote something about 80% of my original estimate and moved on. It took a week or two longer than I had originally estimated and it was fine.

2. Insisted on charging $10 instead of $9.99 because "the taxes get too complicated." Turns out rather than just using billing software like any sane person ca. 2010, she was using a calculator on her desk to figure out what clients owed and just typing that into an invoice and sending it. I bet 90% of our clients either overpaid or underpaid basically every bill by 1 cent due to her rounding in her head.

3. My favorite one ever was she was out on vacation one week, and while she was out we had some production issue over the course of a day and a half or so that was eventually resolved but she was cc'd on everything as she insisted. She pops into my office her first day back at like 8AM and says "I saw $THING wasn't working last week, everything's good now?" Yup. "Okay thanks!" and left. Comes in a few more times asking about $THING over the next hour, kind of weird but not unusual. Runs into my office frantic right before lunch "John Doe just emailed me, $THING is down!" Turns out she was just reading her Outlook top to bottom, so was gradually reading earlier and earlier emails. So in her mind $THING was totally fine and gradually slid into chaos as she read older and older emails.

That was an exciting few years, I have to say.

fjdkfhdjd• 3 years ago

Oh yeah. Sales sets the ship date, which is 'set in stone' because of a trade show. PM makes a schedule that makes the ship date. PM shows the schedule to engineering and is told it's not possible. PM tells management what engineering said, and management tells the PM to make it work, we need to give sales what they need. Oh, and you can't add more engineering resources, the project isn't that important. PM tells engineering to 'make the schedule work' and we add time to some tasks, but then necessarily take time from other tasks. Then engineering starts the death march, with everyone dreading the inevitable escalation of complaints about the project being late. Start slipping schedule? Let's have a bunch of meetings to rearrange the schedule so we can pretend for a week that we're not behind and let the PM feel good when he gives the weekly update to management.

Of course there's blame on the engineering side of the table too. We chronically underestimate effort, not adding enough margin for unknown-unknowns. So we start working late. Sandbagging estimates. Telling the PM whatever he wants to hear just to end the meeting and get back to work.

Impossible schedules are toxic for people that care, and encourage apathy as a coping mechanism. If you put in a Herculean effort and ship on time you did what you said you were going to do, what, do you think you deserve a cookie or something? The other option is failure. Even if the PM or management isn't upset, engineers still feel the failure of not hitting a goal.

Engineers need to feel wins. Always shipping late because of impossible schedules means no project is a win, no matter how good the design is.

At a former job I found out after a couple years that impossible schedules was a business strategy by the c-level execs. It encourages engineers to work as 'efficiently' (i.e. as much) as possible. God forbid we clock out early because we're not stressed out about being behind. Learning that made me shift from caring to apathy. I left shortly after, but I wish I had stayed a bit longer, it might've been nice to have a job that I didn't care about so I could focus on other areas of my life.

ghusto2• 3 years ago

Next time, when someone starts a conversation about your team's estimate, pushing for a lower estimate without any new insights that will lower the effort, ask them: do you ever tell the meteorologist it isn't going to be this bad weather tomorrow?

I'm more direct. I ask them why. As in "why do you think it's less work / time / effort?". Every single time they've realised it's not less, they just _want_ it to be less.

tasuki• 3 years ago

I don't get the meteorologist analogy: The meteorologist does not create the weather. The software development team does create the software.

Also weather is (somewhat) possible to predict. In software, the unknown unknowns are a problem, so all estimates are basically bullshit.

deanCommie• 3 years ago

Engineers have been burnt by too many ex-engineer PM's who haven't coded in 20 years, but push back against estimates by claiming "I could've implemented this in Perl in 2 hours. How can it be 2 weeks!?!"

So it depends on who's saying "no, it's less effort than that".

Often I come to my engineers and say "No, it's less effort than that" because I know "You've never done this before, and you're buffering for the unknown. But actually one part of this can be reused from <module> and you can get this other part from <existing service>". I share the context, the engineers go "oh cool", and update the estimate.

And just as often I come to my managers (people and product) and say the opposite - "No, it's more effort than that" because I know what other things the devs are working on that are not visible to the PMs, what scaling cliff they're stopping us from going over, or that the PM's t-shirt size is not including automation, testing, infrastructure, scaling, etc.

"No, it's less effort than that"

Related Stories