9 ms·

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 e

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.

verve_rat 3y 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.
- WJW 3y 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.
dlahoda 3y ago
why shorter is always better than longer?
- egwor 3y 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 3y 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.
  - onionisafruit 3y ago
    And on the other end, that’s two more days that the company gets the benefit of your new software.
  - gnulinux 3y ago
    > 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.
- sokoloff 3y 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.
  - jeltz 3y ago
    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.
taneq 3y 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.
GoToRO 3y 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.
- mmcnl 3y 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.
  - CipherThrowaway 3y ago
    >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?
    - mmcnl 3y ago
      It totally depends on how you communicate the uncertainty.
  - GoToRO 3y ago
    >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.
- throwaway98797 3y 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
b20000 3y ago
do developers own the business and will benefit the most of the upside?
Aeolun 3y 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 3y ago
  What if you push really hard though
- e1g 3y 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”.
- mmcnl 3y ago
  That's a bad analogy. Managing expectations is very rarely absolute or binary thing.
  - Aeolun 3y ago
    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.
- rrr_oh_man 3y 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? …
  - 3y ago
lmm 3y 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?
- 23B1 3y 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.
  - nine_zeros 3y 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. 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.
beremaki 3y 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 3y 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 3y 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.
- replyifuagree 3y 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!
mmcnl 3y 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.
- ResearchCode 3y 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?
CipherThrowaway 3y 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.
makeitdouble 3y 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 3y 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!
replyifuagree 3y 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.
kjkjadksj 3y 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 3y 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.

verve_rat 3y 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.

WJW 3y 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.

dlahoda 3y ago

why shorter is always better than longer?

egwor 3y 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 3y 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.
- onionisafruit 3y ago
  And on the other end, that’s two more days that the company gets the benefit of your new software.
- gnulinux 3y ago
  > 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.
sokoloff 3y 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.
- jeltz 3y ago
  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.

taneq 3y 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.

GoToRO 3y 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.

mmcnl 3y 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.
- CipherThrowaway 3y ago
  >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?
  - mmcnl 3y ago
    It totally depends on how you communicate the uncertainty.
- GoToRO 3y ago
  >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.
throwaway98797 3y 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

b20000 3y ago

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

Aeolun 3y 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 3y ago
What if you push really hard though
e1g 3y 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”.
mmcnl 3y ago
That's a bad analogy. Managing expectations is very rarely absolute or binary thing.
- Aeolun 3y ago
  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.
rrr_oh_man 3y 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? …
- 3y ago

lmm 3y 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?

23B1 3y 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.
- nine_zeros 3y 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. 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.

beremaki 3y 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 3y 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 3y 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.

replyifuagree 3y 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!

mmcnl 3y 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.

ResearchCode 3y 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?

CipherThrowaway 3y 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.

makeitdouble 3y 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 3y 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!

replyifuagree 3y 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.

kjkjadksj 3y 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 3y 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.