5 ms·

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 turni

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.

colechristensen 6y ago
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.
- btilly 6y ago
  100% buy in is right. See https://en.wikipedia.org/wiki/Disagree_and_commit 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.
  - taurath 6y ago
    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.
    - foobarian 6y ago
      There is a big difference between "I disagree with { on separate lines" and "this won't work in production".
  - WaitWaitWha 6y ago
    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.
    - feteru 6y ago
      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
      - WaitWaitWha 6y ago
        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.
    - kelnos 6y ago
      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.
    - 6y ago
taurath 6y ago
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.
- pmarreck 6y ago
  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.
  - 7532yahoogmail 6y ago
    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.
    - pmarreck 6y ago
      I think we just succinctly summed up why I'm still a freelancer despite missing actual coworkers
arcticbull 6y ago
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.
- suchire 6y ago
  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.
- JamesBarney 6y ago
  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.
  - gregmac 6y ago
    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".
a1369209993 6y ago
> 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.
- 7532yahoogmail 6y ago
  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.
  - hinkley 6y ago
    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.
- beefalo 6y ago
  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.
  - desipis 6y ago
    "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.
gilbetron 6y ago
> 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".
- 7532yahoogmail 6y ago
  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.
- philipov 6y ago
  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.
- outericky 6y ago
  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.

colechristensen 6y ago

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.

btilly 6y ago
100% buy in is right. See https://en.wikipedia.org/wiki/Disagree_and_commit 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.
- taurath 6y ago
  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.
  - foobarian 6y ago
    There is a big difference between "I disagree with { on separate lines" and "this won't work in production".
- WaitWaitWha 6y ago
  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.
  - feteru 6y ago
    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
    - WaitWaitWha 6y ago
      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.
  - kelnos 6y ago
    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.
  - 6y ago

taurath 6y ago

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.

pmarreck 6y ago
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.
- 7532yahoogmail 6y ago
  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.
  - pmarreck 6y ago
    I think we just succinctly summed up why I'm still a freelancer despite missing actual coworkers

arcticbull 6y ago

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.

suchire 6y ago
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.
JamesBarney 6y ago
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.
- gregmac 6y ago
  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".

a1369209993 6y ago

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

7532yahoogmail 6y ago
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.
- hinkley 6y ago
  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.
beefalo 6y ago
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.
- desipis 6y ago
  "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.

gilbetron 6y ago

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

7532yahoogmail 6y ago
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.
philipov 6y ago
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.
outericky 6y ago
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.