Comment by 7532yahoogmail | Hacker News Reader

Comment by 7532yahoogmail | Hacker News Reader

Parent Full thread

Software dev 20+ years: management is right to ask for estimates. It's ok for engineers to write a throwaway design paper to "get into" the problem before turning to jira epics and stories. It's also right for engineers to reject arbitrary dates, pressure to cut corners and so on. But this or the ops story absolutely don't get anybody anywhere.

You wanna move beyond anecdotes and nice sounding business arguments? Read FIRO by Dr. Schutz prob out of print or "Human element" by same. His son Ethan has updated these books.

Look, in normal high functioning groups conflict is normal. What confers distinction there is two things:

- no individual on team is ridgid and unchanging

- conflict is resolved with 100pct buy-in ie not cause the boss yelled, or you were out gamed, politics, favourites. IOW there is trust in the team (together with self awareness, competence etc which the book hits on)

When human factors burn down projects down the issues are quite a bit more about trust, individual self awareness, defensive behaviors, and not resolving the problem in a group way. Trying to eliminate conflict with rules of thumbs is a fool's errand. Conflict itself is not a sign of badness.

References to organizational modalities (the strong boss, the clear vision, and similar sounding approaches) help at the margins only and then only randomly.

As someone going through this right now, here's some things I do to make the process easier.

1. Put together a ~medium detailed listing of what work needs to be done, broken down into sub-tasks.

2. Include estimates for how long each sub-task will take.

3. Roll that up into a gantt chart with dependencies reflected.

4. Identify opportunities for parallelization so you can answer the question of "will adding more folks make things go faster?"

5. Identify and be prepared to speak to which portions of the schedule represent padding, and explain why it was padded in that way. Share your thinking in the trade-off you made and be open to adjusting -- and de-risking the schedule in other ways.

6. Realize this is a bit of a negotiation, not necessarily you vs. them but more you and them vs. what you can deliver. In a negotiation it's important to not appear intractable. Have things you can give away.

7. At the end of the day the engineers are writing the software. If you're not actively dragging your feet, what you say does go, so it's a question of where you're spending your time, and on what. With that in mind, your boss has a job to do too, so help give them the tools they need to do so.

8. Don't burn bridges, y'all have to work together.

I think another rule of thumb I would add, which other commenters have mentioned in passing, is to negotiate scope, quality, and likelihood of success, not estimates. Negotiating estimates is where people start questioning each others’ expert judgment, which leads to a breakdown in trust.

I haven't found gantt chats very useful in software. I've never been found a project that was delayed due to a critical path error.

I'm sure it's happened but I've seen far more delays due to gold plating, over-architecting , or bad estimates.

How does a "bad estimate" cause a project to be delayed?

I think this type of wording is part of what causes animosity in the industry about this topic. Estimates are not called "promises" for a reason, and any attempt at treating them that way will result in failure.

Software estimates are notoriously hard to get right and it's not uncommon for them to be wrong by several orders of magnitude, and this effect is magnified for bigger estimates/work. Any decent project plan needs to assume this is the case, and it needs to be continually refined as work progresses and the accuracy of "estimated remaining work" gets higher as the problem is better understood.

The worst project plans are the ones that take the initial estimates and use those as delivery dates, but I'd classify that as a "bad plan", not "bad estimate".

A bad estimate causes a delay to the project schedule (in the sense the schedule is delayed, not in the sense the software takes longer to write) . It's not the same kind of delay, but to many stakeholders it's perceived as the same kind of delay.

> Estimates are not called "promises" for a reason, and any attempt at treating them that way will result in failure.

So management 95% of the time treats estimates as commitments. What they are going to do with the numbers you give them is promise upper management or clients "feature x will be done by y". As engineers we have two options, scream until we're blue in the face "that was an estimate not a commitment" or just give them a commitment and call it an estimate.

You're right software estimation is hard, but the really bad estimates I've seen (> 100% over) were due to a combination of dysfunctional organizations, lack of estimating skill, and an organization that didn't put effort into making sure it's estimates were right.

> Software estimates are notoriously hard to get right and it's not uncommon for them to be wrong by several orders of magnitude

OK now hold on there just a sec... I've seen estimates off by 20%, 50%, even 100%. I'm sure there are estimates that have been off by 500% (I'd hate to dig into why). But "several orders of magnitude" is something like 10,000x -100,000x. Hopefully that is just extreme hyperbole, but honestly in the context of discussing estimates, it seems particularly out of place.

Bad estimates can cause shipping delays when cross-functional or inter-dependent work ends up in day-for-day slip because not all work is parallizable. The only time a bad estimate doesn't cause a delay is when it's "single-threaded" and the long pole.

Gantt charts are incompatible with software development

I've had a lot of success with Asana's timeline and also with TeamGantt. It's my go-to for project management, and for what it's worth, I and by extension my teams are known for nailing our deadlines come hell or high water (without burning out my team). It's a tool in the chest, it's not for everyone, but it's by no means incompatible. Depends how you slice your work to be done :)

I find them useful for large projects with multiple teams with inter dependencies.

> management is right to ask for estimates

Why? They are always wrong. Asking for a plan? Sure, because planning makes you think through things. Planning good, plans bad, to paraphrase. But estimates are always wrong and always useless, dev with 30+ years experience and I've never met anyone that can actually estimate software except in the trivial sense.

The error bar on software estimates, like solving a math problem (because they are the same thing! If you don't think so, you don't understand software), is infinite.

Although I like your quote that "conflict itself is not a sign of badness".

Why? Because there are often other dependencies going on. Most software in this paradigm is at a company. When companies roll out new things, change management has to happen. Marketing needs to make a splash (they want at least 6-12 weeks lead time). Sales starts making promises. Account managers and support need to be trained. Change management has to to happen. So then missing a date by weeks/months screws up the business. Most companies aren't writing software for fun.

Sorry, buy have to disagree. Management broadly (program or business managers and related workers) are not always wrong or wrong to ask. Nor is it waste to try. It's exactly this kind of fixed belief which drives behavior that ultimately runs the big risks. Not sure deeper meaning buy seeing this kind of interaction is a game, stupid game, or good idea by innocent if stupid people is exactly the kinds of things that work against team cohesiveness. Software isn't 6-sigma manufacturing so the best kind of predictive work that applies there doesn't work for us, but even they know good cross functional coordination is about a whole lot more than error bars. The book will give clarity and depth this forum won't permit. The inability to perfectly plan does not advocate for the "trust me model" from programmers.

While the worst case might be infinite, the average case is a lot less bad than that, and knowing whether something will take 2 hours, 2 days, or 2 weeks is important for prioritizing work. Maybe that one new column in the query isn't so important if it'll take 2 weeks, but if it's only 2 hours then let's get it now.

The error bars on solving a math problem (or writing a program, or anything else) are not infinite unless you make the mistake of stretching them to the point of encompassing absolute certainty that a solution is found.

Almost no software development task is like proving or disproving P=NP: often, they are like homework problems. And, like uninspired homework problems, it is often a matter of grinding through a process with all due attention to the details.

> management is right to ask for estimates.

True, but there needs to be common understanding that they are estimates, and if the projects take consistently longer, it means the dev is bad at estimating, not bad at writing software[0]. Also, if you get a median time, you'll have, by definition, half the projects taking longer than that; a mean, mode, or 90th estimate will still have plenty of high points; and if you want 100th percentile, you don't even need to ask the developer: "sometime in the next century, probably".

0: They can be that, too, but that's a independent flaw from being bad at estimating.

Being good at estimating is an important skill for a developer. You are the one with the knowledge of what needs to be done to deliver a project and to be a good engineer you should be able to deliver a reasonable estimate so a decision can be made on what to invest in. If your guidance leads is wrong and leads to a bad investment, then it is not a misplaced judgement for you to bear some of the blame.

"You are the one with the knowledge of what needs to be done to deliver a project"

I think you're missing the point. Nobody has that knowledge prior to the project being complete.

The only exceptions are very small projects or projects that are just rolling out pre-established boiler-plate solutions. Any reasonably complex and reasonably sized software system contains far more uncertainty than humans are capable of thinking through.

On top of that, people assume estimates are normally distributed. In my experience there's much more skew -- surprises are rarely in your favor.

This means any given "good" estimate is either unlikely since it's in the tail of the distribution or overly optimistic if in the bulk.

The issue often is that management will not crush programmers if wrong. Managers aren't stupid. This isn't a competence issue primarily. This is a trust and openness issue mainly. So the estimates were wrong? What do people believe about why they were wrong and how will people react? If that decends into defensive behavior ... Read the book.

The people who call them estimates aren't the problem. The people who substitute the word 'commitment' are.

You promised, and it didn't happen, so you are a bad person.

I would just say that most conflict that people will deal with is unfortunately going to be the bad type. Its not very frequent outside of a few highly productive environments that there is enough active trust communication and self awareness to avoid "territorial" conflicts.

I think this highly depends on the developers and the team. I myself care about my work and this sometimes lead to tensions with management, but because they trusted me, those tensions were productive. When the trust is lacking, those tensions become sour.

One of the big points in the book: at many human organizations trust/openness is the last thing resolved. And most people think openness is scary because it means being yelled at or leaving oneself open to be screwed somehow. There can't be openness unless there is safety ... Hence the ray dalio quote (and this comes many many variations by many people): working is doing dumb ass things you wouldn't be caught dead doing at one's own company. There's tons of ineffective labor -- people know better -- but won't say it because they are afraid about being screwed.

I think we just succinctly summed up why I'm still a freelancer despite missing actual coworkers

I don't know about 100% buy-in. Maybe it is just lacking nuance but being ok with going forward in a direction you don't agree with is important in a team. Disagreement is good, it gets you better results in a healthy environment, and it doesn't have to end to make a decision.

The signs of a good compromise is everybody leaves unhappy about something. Not that products should be built entirely on compromise... that also leads to garbage.

It is difficult to pick the pieces apart, but frequent strong-armed conflict resolution is definitely a sign of a bad environment.

100% buy in is right.

See https://en.wikipedia.org/wiki/Disagree_and_commit for a list of successful organizations that have adopted a principle meaning that and why they did it.

"Disagree and Commit" in a vacuum is just an authoritarian kludge.

The Amazon principle is "Have Backbone; Disagree and Commit". Most leadership principles in Amazon are in conflict with each other, creating a sort of checks-and-balances situation. But "Disagree and Commit" is so powerful that it needs a check in itself. It doesn't work without "Have Backbone" - but most senior leaders I see who love it never mention that part. They always spell it out as a "follow the orders once they're made" sort of thing.

Disagree and Commit is not about 100% buy-in. It is about having the fortitude to disagree, but once a decision is made, 100% committing to and supporting that decision, despite disagreeing.

There's a lot to like in what you write. Back to the book I referenced above ... disagreeing here has several facets. First you have to be aware you can disagree. You have to be aware you have choice and use it. Disagreement is not a firing offense. Bosses are not entitled. Second, how it's done is important: if I disagree through a defensive behavior (again see book) that will go bad ... If at the end a decision is made and feel like I had no choice or my ego won't allow it ... well that's another potential concern. Again disagreement isn't often itself the real problem. The real problems are: what if I know I can disagree but I don't? Lack of courage my side or unsafe environment made by management? If management tells me they've made their decision contradicting my input which applies: I feel listened to and feel like my input was taken seriously? That's good. Or perhaps I'm insecure and can't deal with loosing control. If I don't have self awareness here I might blame, critisize management or play victim. That can be bad. Maybe I just can't admit my assessment was incomplete or wrong. Also likely to hit into problems. And in any of this I refuse to change, I can sink the team in the limit.

I agree commiting to something silly whilst your mind constantly sees a better answer can lead to eventual breakup. Companies dont succeed by getting 100% buy in to bad decisions. People who see the writing on the wall frequently leave, leaving committed people to their Titanic or hindenburg.

Buy in resolves people with wrong ideas trying to steer into the iceberg, and loses the benefit of disagreement overcoming resistance and inertia towards bad goals.

My opinion is that committing is buy-in. You don't have to agree with something to buy into it. You buy into something when you agree to do it, whether or not you are convinced it's the right thing.

so "committing to and supporting that decision" isn't buy-in? Come on. That's spending your capital as an employee on the decision, buying into it and working on it. You're not harboring resentments

I can definitely commit to something that I disagree with. Ask any military person that is responsible for both making and accepting decisions. This may be a nuanced language here, but buy-in for me is the Cambridge definition "the fact of agreeing with and accepting something that someone suggests". For commit and support, I do not have to agree.

Only in an environment where failure is an option and inaccurate or wrong action is preferable to inaction. Disagree and Commit doesn't prevent the Challenger from blowing up.

There is a big difference between "I disagree with { on separate lines" and "this won't work in production".

Reply on news.ycombinator.com