Hacker News Reader

Comment by throwaway091ba | Hacker News Reader

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.

View on HN

> 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.

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!

> 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?

> 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.

> 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.

And yet, none of the politicians are going to toil to make the deadline work. There is no gain to be had for the actual engineers or the actual business.

How about this, tie a deadline to a well-defined bonus that only the engineers would receive and staff the project with ALL the engineers you can get. This will allow political heads to keep doing their coalition-building while engineers also receive some benefit for their toil.

If you are unwilling to share the rewards of the toil, it is no surprise that the actual people doing the toil don't care about your coalition-building nonsense that doesn't even help the business in anyway. Your coalition-building vs their own time with family/friends, not a difficult choice to make.

Wrong. Organizations don’t exist without administration, as a necessary requirement for doing business. Part of your time, as part of that org, will contribute to that if for nothing else because a company is required to comply with baseline regulatory compliance (accounting, taxes, investor relations, etc.).

Happy to share in the spoils and many companies do this with stock/options of course - but don’t think for a minute you live in a walled garden. I mean, you can, but then you get zero input into things like deadlines; you’ll simply be ignored or moved out of the org.

Your comment is essentially “I want all of the responsibility and none of the accountability”

> Wrong. Organizations don’t exist without administration, as a necessary requirement for doing business. Part of your time, as part of that org, will contribute to that if for nothing else because a company is required to comply with baseline regulatory compliance (accounting, taxes, investor relations, etc.).

Where exactly did I say that organizations exist without administration. All I pointed out was that if the rewards are not shared with people, people will not do the work.

But since you are writing this from a org structure perspective, I can alsosay that administrative work can be done by HR. Eng management can be left to handle engineering direction and task. Specifically, the political org structure is not a necessity - it is only something that low IQ can understand. A smarter structure is technical leadership all the way up to VP + HR that manages pay and promos.

Nothing personal but I’m guessing you are either relatively inexperienced or maybe in a market that is different than the U.S.

The reward is your salary/bonus/stock, and it obviously works… because work gets done and tech talent is well-remunerated for it. The technical leadership structure you seem to be recommending already exists; plenty of ELTs have or are comprised of experienced people with deep technical roots.

> Nothing personal but I’m guessing you are either relatively inexperienced or maybe in a market that is different than the U.S.

No offense taken. I am in the US and worked for 2 of the FAANGs and 2 FAANG-adjacent startups. The work culture in each of these companies is so terrible that even $400k/year is not enough renumeration for that kind of pressure and political nonsense.

What I learned by working at startups after FAANG is that FAANGs are able to have such poor management practices (e.g. fiefdoms, politics, perf reviews) only because they can hide behind infinite revenue. Startups (<1000 employees) that copied FAANG practices crashed quickly because guess what, those practices are actually harmful to the producers of services (engineers, product) and that leads to a quick drop in revenue.

>$400k/year is not enough

Except to many it is - and I’m perfectly happy arguing from the majority in this case, because the failure rate for companies that do not adopt many of the best practices you rail against is extremely high.

You also seem to be making arguments for things that already exist and are universal, like performance-based comp, etc.

> You also seem to be making arguments for things that already exist and are universal, like performance-based comp, etc.

This appears to be a form of projection because that is not what I was arguing for. And things that "already exist" don't always exist. They especially don't exist in the form they are in FAANGs.

In fact, in my experience, the companies that copied FAANG style are the ones that suffered more than other companies that did not adopt those practices. Having worked at pre IPO companies that succeeded and that failed, FAANG-style heavy management is the single biggest reason for company failures because every IC matters in these companies, and poor management practices affect actual product outcomes a lot more in smaller companies.

If you’re not getting well-remunerated for your work at at FAANG or a startup that IPOs… you probably need to get some help finding or negotiating on your next job my dude.

> If you’re not getting well-remunerated for your work at at FAANG or a startup that IPOs… you probably need to get some help finding or negotiating on your next job my dude.

Once again, you are missing the point of the last post which makes me suspect you are exactly the mediocre manager who gets complained about a lot. Let me guess, you hold weird ideas such as "If they don't do XX, YY, I will fire them" - never once blaming yourself for hiring them in the first place.

Let me know if I can advise you on how to score comp you’re happy with on your next role!

> Let me know if I can advise you on how to score comp you’re happy with on your next role!

I have already made my millions by working with sane ipo companies. At this point, I would much rather take advice from folks who prefer a good management structure. Please continue with your TC grind. Thanks for the offer though!

Sure dude!

> The reward is your salary/bonus/stock, and it obviously works… because work gets done and tech talent is well-remunerated for it.

By that logic, responding to requests for estimates with sarcasm and cynicism also works, because work gets done and tech talent is well-remunerated for it.

The dudes who respond to requests for estimates with sarcasm and cynicism get fired. I’ve fired them.

Maybe in some businesses. I suspect those business do less well than the ones that fire people like you instead.

I keep forgetting that HN skews more and more young every day.

> Thats how coalition-building, budgeting, and reporting works in business. Not saying it should dominate your schedule, but it's just how organizations work.

Nah. Internal competition is a negative for the business. Selfish individuals do it so that they can get better results for themselves. Refusing to take part is the right thing for the business.

I never said it had to be competitive nor is my comment recommending that.

You don’t own 100% of your time when participating in group activities.

> I never said it had to be competitive nor is my comment recommending that.

You said "Thats how coalition-building, budgeting, and reporting works in business." In my experience that's only true in the bad kind of business where there's too much internal competition.

> You don’t own 100% of your time when participating in group activities.

You're responsible for your time. You should share it generously with people who want to put it towards something productive, but you should also push back when people want to waste it.

Internal competition can be good and bad, just like any other management principle. But at the end of the day, an organization needs consensus or it’ll implode, and some people are required to help build that consensus, amongst other duties that extend well beyond product. This is as true for business as it is in any other group dynamic.

You need consensus, sure. You don't time estimates from engineering estimates for it, and even if you did, badgering engineers to make their numbers smaller wouldn't make getting consensus any easier.

You do need estimates to unlock capital, plan budgets, plan for staffing. And badgering engineers to make their numbers smaller is often the result of engineers bullshitting their numbers, as I mentioned before. Engineering departments aren’t free from the same errors or fallacies or biases or mistakes that other humans make.

This is business 101 stuff.

> You do need estimates to unlock capital, plan budgets, plan for staffing.

You might need some amount of estimation. You don't need a full schedule of every task, and producing one just in case is immensely wasteful. In my experience engineers are very happy to help answer questions like "should we be hiring more people for this project" when there is a real need and businesspeople trust enough to share that context.

> badgering engineers to make their numbers smaller is often the result of engineers bullshitting their numbers, as I mentioned before

Pretty sure the causation goes in the opposite direction. Most engineers are honest to a fault; the ones who pad their estimates are the ones who've spent too long working with crappy business people who do things like cutting time off estimates.

> Most engineers are honest to a fault

This is not something I'd bet millions of my own or investor's money on. The sooner engineers realize this – that their honesty simply isn't germane to the discussion at hand – the sooner this endless argument ends.

There's plenty of grown-up engineers who get this by the way.

> The sooner engineers realize this – that their honesty simply isn't germane to the discussion at hand – the sooner this endless argument ends.

Yeah, no. The sooner business people realise that honesty matters and deceit is deceit no matter how much sophistry you surround it with, the sooner the argument ends. There are plenty of grown-up businesspeople who get this.

Right, the business people are dishonest and the engineers are honest. Cringeworthy naïveté.

> Right, the business people are dishonest and the engineers are honest.

On the whole, yes. You get what you incentivise.

> Cringeworthy naïveté.

Yeah that's exactly what dishonest people tend to call it when they're called out.

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.

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?

You don't have to ask me, the latest layoffs prove that they are disposable even if the company has record profits.

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

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.

>Who says "business people" aren't capable of dealing with uncertainty?

Not defending the parent comment because it's way off base. But come on. You've never seen non-development stakeholders struggle to accept devs communicating uncertainty?

It totally depends on how you communicate the uncertainty.

>Who says "business people" aren't capable of dealing with uncertainty?

Well not me if you read my comment.

Also given that you don't know me but you immediately made a personal attack based on your own misunderstanding... you kind of proved yourself wrong. That's why people don't talk to you.

A founder is someone who starts a business.

It's not whatever you mentioned here.

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.

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”.

> 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?

…

Honestly, asking these kinds of business level questions as a dev is a great way to be seen as stubborn and uncooperative in businesses where the mindset of the OP comment has taken root.

The managers who complain about their devs not thinking at the business level are usually the ones shooting them down when they do. Why are the coders questioning why we need the baby?

It might be, if it’s directionless pushback instead of genuine curiosity to understand the need of the internal customer.

From my personal experience, people are often positively delighted when you make an effort to try to understand them and their needs.

Not shooting down your experience, but from my perspective it could be seen as a straw man argument in favour of never trying in the first place.

I'm not saying "don't try." And I'm also not disagreeing that people, on the whole, respond well to attempts to understand them and communicate with them.

My observation is that it is ultimately organizational culture that frames the way people communicate and how they understand each other. Individuals can move the needle a bit depending on the size of the company and their position in it. But largely they are powerless against the prevailing culture.

In a healthy organization, your efforts to understand the rest of the business and its needs will be accepted as you intend and will benefit yourself, your team and the business. In the average toxic organization, your good intentions won't matter and your questions won't be received the way you intend. Staying upbeat and helpful in these environments might even result in you being punished.

Thanks for the clarification!

That's the best reply to the baby analogy i saw.

Thanks.

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

If you can start asking questions like “do we actually need a baby”, “what are the specifications for hair color and nose length”, “does it need to be a human baby”, “how about we start at an embryo instead” etc. the whole equation changes. But most people asking for the estimate aren’t actually interested in providing any of that information.

They want to give you a vaguely defined blob of half finished specifications, and expect a perfectly accurate assessment of the time it will take, and also to be able to change the vaguely defined blob as they go along without effect on the given estimate.

What if you push really hard though

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.

>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!

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.

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.

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.

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.

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.

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.

> 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.

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.

> "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.

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

why shorter is always better than longer?

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.

From my experience this is simply not true because all else is never equal. Employee burnout, technical debt, risks taken due to rushing, people not doing the right tradeoffs, etc.

Nobody cares about doing things right anymore. They just want quick wins. Meanwhile all the tech debt piles up.

Seeing as there's tech debt from 40 years ago people like me are still paying, seems like devs don't know how to do things right at all.

Well yes and no.

That tech debt from 40 years ago was usually perfectly adequate back then. It's only tech debt now because it's become unmanageable due to changing environments, programming languages, APIs, security concerns etc.

> Employee burnout, technical debt, risks taken due to rushing, people not doing the right tradeoffs, etc.

I've never seen a set of business people in a software company that cares about any of these things.

Some PMs will say they care about tech debt which excites me but of course in 6 months you'll see they actually cannot give a shit but just use it as a tool to lower the estimates. If X takes 5 days but they want 3 they'll tell you "let's just add some tech debt" to convince you to promise 3, but they don't actually ever intend to work on that tech debt.

When it comes to burnout, I've literally never seen any person who doesn't consider this the fault of the employee.

I've seen VP level people who did things that are so absolutely insane that it resulted the project to be late with 100% probably from 6 months before, then when the day of launch comes it is indeed late, fire alarms are pulled, tons of people give on-call attention to our project, we hack something. Then VP says "whoopies sorry about the fire alarm, will never happen again". Lmao next thing that happens is that this person is promoted to SVP and does it again and again. "Rushing" is a good thing, if anything. Business is all about creating an artificial sense of urgency that could be trivially averted, but it was chosen not to.

People not doing right trade offs. Well again, it's on you if you do the wrong trade off. People will point at you and say this decision was wrong. That I had so little information and time to make that decision is very brought up.

A lot of the time getting things done more quickly equates to creating a mess that will cost you more in the long run.

That's why it's called tech debt, it accrues interest.

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.

> Ignoring everything else

This is the problem with these kind of discussions. You cannot ignore everything else because everything else depends on 2 versus 4 days as well. Something that's done in 2 days can be exponentially worse than something done in 4 days such that in 6 months you can look back and rationally determine it was better to do it in 4 days.

And on the other end, that’s two more days that the company gets the benefit of your new software.

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?

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.

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?

Reply on news.ycombinator.com