"No, it's less effort than that"(smartguess.is)
smartguess.is
"No, it's less effort than that"
https://smartguess.is/blog/your-estimate-is-less-than-that/
382 comments
I feel the sales analogy is quite general (hit a quarterly/annual quota) but the engineering example is talking about a specific piece of functionality.
If you asked the sales team about a specific deal and they said "We estimate a 70% chance of closing the deal. It'll bring in about $5m in ARR."
If management responded "Could you make that 80% and $7m ARR?" I think that would be a closer analogy.
Sure it might be possible to improve the odds of closing and jack the price up at the same time - just like it might be possible to complete that feature in half the time - but somebody will have to make some major changes or concessions somewhere to make it happen.
If you asked the sales team about a specific deal and they said "We estimate a 70% chance of closing the deal. It'll bring in about $5m in ARR."
If management responded "Could you make that 80% and $7m ARR?" I think that would be a closer analogy.
Sure it might be possible to improve the odds of closing and jack the price up at the same time - just like it might be possible to complete that feature in half the time - but somebody will have to make some major changes or concessions somewhere to make it happen.
It's totally valid to push devs to get a ticket done faster when there's real pressure. It's much better to finish a ticket under estimate than turn estimates into aspirations.
The best case is to:
- line up the work in order of priority, taking into account prerequisites
- have sufficient stories in a ready for dev state
- during crunch time, be strategic about ticket assignment (you pay for this in the long term with a less-well-rounded team, so be careful)
- make sure to evaluate every feature to ensure that there are no "nice to haves" mixed in (when under time pressure), or move them to bottom of backlog
- selectively consider consulting with other teams, outside experts (but be sure to really time box this tightly and cut it off once work is under way)
- remove extraneous meetings & distractions; empower devs to decline meetings / block calendars
- borrow from the future by raising the bar on refactoring (ie, only when cost-benefit clearly pays for itself before deadline)
- be very careful that you don't make this approach the standard way of working
The best case is to:
- line up the work in order of priority, taking into account prerequisites
- have sufficient stories in a ready for dev state
- during crunch time, be strategic about ticket assignment (you pay for this in the long term with a less-well-rounded team, so be careful)
- make sure to evaluate every feature to ensure that there are no "nice to haves" mixed in (when under time pressure), or move them to bottom of backlog
- selectively consider consulting with other teams, outside experts (but be sure to really time box this tightly and cut it off once work is under way)
- remove extraneous meetings & distractions; empower devs to decline meetings / block calendars
- borrow from the future by raising the bar on refactoring (ie, only when cost-benefit clearly pays for itself before deadline)
- be very careful that you don't make this approach the standard way of working
>be very careful that you don't make this approach the standard way of working
Legacy management steeped in manufacturing has entered the chat!
Legacy management steeped in manufacturing has entered the chat!
I was going to say something related to car manufacturing as well.
The truth is it really doesn’t matter how many features you deliver, or how many cars you produce.
The real impact is from managerial decisions on customers and products. A car company that does not produce as fast as it could, but produces high-quality, is still going to sell everything that they can make. Same in software. I would argue this is Microsoft and Apple’s model.
If people want it, they can even raise the prices and it won’t make any difference if they make more of them. The same truth exists in software, but everyone wants to talk about productivity because management wants to feel like they’re getting a good deal for the money.
But they’re focused on the wrong aspect of their business. It’s the same as the car business. In software, we say that sometimes you have to slow down to go faster. That’s kind of what Toyota did. Focused on quality, and now they’re making more money than anyone else.
The truth is it really doesn’t matter how many features you deliver, or how many cars you produce.
The real impact is from managerial decisions on customers and products. A car company that does not produce as fast as it could, but produces high-quality, is still going to sell everything that they can make. Same in software. I would argue this is Microsoft and Apple’s model.
If people want it, they can even raise the prices and it won’t make any difference if they make more of them. The same truth exists in software, but everyone wants to talk about productivity because management wants to feel like they’re getting a good deal for the money.
But they’re focused on the wrong aspect of their business. It’s the same as the car business. In software, we say that sometimes you have to slow down to go faster. That’s kind of what Toyota did. Focused on quality, and now they’re making more money than anyone else.
Isn’t sales a numbers game for the most part? Like you can convert 10% of leads, so if I need 5 conversions instead of 4, I need to call ~10 more people?
A better comparison to software I think would be construction of a novel building. Try constructing a geodesic dome house with no experience, and little knowledge of the issues you might run into, but then you’re asked for accurate estimates and then pressured to shorten them.
A better comparison to software I think would be construction of a novel building. Try constructing a geodesic dome house with no experience, and little knowledge of the issues you might run into, but then you’re asked for accurate estimates and then pressured to shorten them.
> I need to call ~10 more people?
I need to write 10 more lines, code for 10 for minutes, etc.
I need to write 10 more lines, code for 10 for minutes, etc.
Maybe bonus developers on lines of code written?
Or my personal favorite, bugs fixed!
https://devhumor.com/media/dilbert-s-team-writes-a-minivan
Or my personal favorite, bugs fixed!
https://devhumor.com/media/dilbert-s-team-writes-a-minivan
Except a sale is a sale; did they buy it or did they not? There's additional nuance for whether they'll buy again or what support they need going forward, but a sale is still a sale.
A program is not just a program. A bug fix is not just a bug fix. They are not fungible, while sales, definitionally due to the exchange of money, are fungible.
A program is not just a program. A bug fix is not just a bug fix. They are not fungible, while sales, definitionally due to the exchange of money, are fungible.
Taking a narrow view, maybe. But a sale in a jurisdiction you don’t currently have other customers in could impose significant regulatory burden for relatively little gain. A single 100x sale is very different than 100 1x sales both in overhead you’ll have and in how much leverage the customer will have in the future, etc
If we consider that Fungibility is on a continuum of very low on the left and very high on the right. Where do you think most sales fall on the continuum?
I'd claim that businesses are biased toward chasing a highly fungible sales model, to the point of eliminating the need for a salesperson altogether, and so naturally sales tends to the right.
I'd claim that businesses are biased toward chasing a highly fungible sales model, to the point of eliminating the need for a salesperson altogether, and so naturally sales tends to the right.
That's definitely the sort of thing I'd expect Generic Tech Startup to do, but it certainly isn't standard in every industry. B2B stuff is often a bit bespoke.
[deleted]
[deleted]
This is ridiculous. The number of LOC doesn’t define whether something is well implemented. You can’t crank out a better design or proper feature implementation by asking developers to write code faster or write more code in a given day.
You’re restating their point, just with more words.
Not really, the shotgun approach actually works with sales - especially if the sales force has been slacking and not chasing leads.
Whereas with code, deleting code and writing less code is very much preferred because each line of code written increases the complexity and risk in the system.
This is why business teams who are shirking discovery and instead focusing on the anti-pattern of trying to increase engineering productivity is such a massive mistake. Not only is the team pooping out code that doesn't fill a need (and hence won't be monetized), but they are also rapidly increasing complexity and opening the business to future liability when the code causes customers to seek remediation.
The quarter driven nature of most companies amplifies this bad behavior. This is why we see this revolving door of executives who come in, drive some bad initiative to incompletion, declare success and move on before their chickens come home to roost.
Whereas with code, deleting code and writing less code is very much preferred because each line of code written increases the complexity and risk in the system.
This is why business teams who are shirking discovery and instead focusing on the anti-pattern of trying to increase engineering productivity is such a massive mistake. Not only is the team pooping out code that doesn't fill a need (and hence won't be monetized), but they are also rapidly increasing complexity and opening the business to future liability when the code causes customers to seek remediation.
The quarter driven nature of most companies amplifies this bad behavior. This is why we see this revolving door of executives who come in, drive some bad initiative to incompletion, declare success and move on before their chickens come home to roost.
None of that is how sales works. “Just try harder” is bad advice in basically any context.
Everyone in this thread is trying to point out to you that your assumptions about sales are the same as the LoC assumption that equivalently clueless people make about software.
Everyone in this thread is trying to point out to you that your assumptions about sales are the same as the LoC assumption that equivalently clueless people make about software.
There is a proven relationship between contacts made and sales made. Which is why sales managers constantly push sales staff to be making calls. Sales has been around for way longer than development, the underlying theory for sales is well known. Just like the underlying theory for manufacturing is well known.
No there isn’t. There’s sometimes a correlation, but only people without knowledge of sales think that’s causal. If you want meaningful sales you have to approach it fundamentally differently than you seem to think. Your universal law of sales only applies to commoditized products, and if you’re selling those you’ve already lost.
> The number of LOC doesn’t define whether something is well implemented.
And a phone call doesn't mean a sale closes.
See conversation upthread.
And a phone call doesn't mean a sale closes.
See conversation upthread.
But 100 phone calls will, there is actually no such relationship in code - in fact deleting code significantly reduces liability, I guarantee reducing sales calls will not have the same effect.
That’s not how sales works. At all.
Yes it is.
Also it how scam works.
Every time the probability is non null. Small, but not zero.
Law of big numbers always help scammers. And mediocre sales.
Every time the probability is non null. Small, but not zero.
Law of big numbers always help scammers. And mediocre sales.
>Isn’t sales a numbers game for the most part?
At some level. But numbers aren't created equal and sales reps aren't usually supposed to be calling numbers out of a telephone book. Depending on the type of sales rep, they're hopefully reaching out to people who have been qualified to some degree. The email I got from a sales rep at my own company on Friday afternoon asking for a call about my requirements? That wasn't a well-qualified lead for whatever reason. (Not their fault; I'm sure they're just working from a list.)
At some level. But numbers aren't created equal and sales reps aren't usually supposed to be calling numbers out of a telephone book. Depending on the type of sales rep, they're hopefully reaching out to people who have been qualified to some degree. The email I got from a sales rep at my own company on Friday afternoon asking for a call about my requirements? That wasn't a well-qualified lead for whatever reason. (Not their fault; I'm sure they're just working from a list.)
I'm tempted to be sarcastic about it, but it's surprising to me that no has mentioned sales quotas being connected to bad behavior. The most important kind is deceptive behavior to customers, and not just the "ordinary, good for the company kind". I mean making promises the company can't keep, or selling future features that require a deathmarch, with the attendant loss of quality/sustainability, even if the C-level doesn't see it.
This isn't to argue that we should just believe developer estimates unconditionally. That's a bigger rabbit hole that I'm too tired to go down right now.
This isn't to argue that we should just believe developer estimates unconditionally. That's a bigger rabbit hole that I'm too tired to go down right now.
The difference is that lowering the estimate for a given amount of work doesn't actually get it done quicker - it just means you have a more unrealistic understanding of the timelines.
You can absolutely work to find other creative solutions to the same problems, or understand what scope is acceptable to cut to meet some goal. That's very different from "I want you to do exactly the same work but just do it faster".
You can absolutely work to find other creative solutions to the same problems, or understand what scope is acceptable to cut to meet some goal. That's very different from "I want you to do exactly the same work but just do it faster".
If your stories are so well defined the dev doesn't have any decisions to make in the process of coding, then they're more of a glorified type writer than a dev.
There's plenty of decisions devs make that impact how quickly they deliver a solution.
There's plenty of decisions devs make that impact how quickly they deliver a solution.
How is that different from arbitrarily raising quotas?
It’s not at all like sales quotas. The salesperson’s upside is directly linked to their quota, they are incentivized to fudge it as much as they can.
What’s the incentive for a developer to inflate their estimate? The only reason I have to inflate an estimate is if I know some non-engineer boss-type is going to swoop in and try to convince me to lower it.
What’s the incentive for a developer to inflate their estimate? The only reason I have to inflate an estimate is if I know some non-engineer boss-type is going to swoop in and try to convince me to lower it.
Incentive to increase estimate might be:
Deliver under estimate and get a bonus, raise, influence, or just plain old "well done"
Be lazy and only work half the time while delivering "on time".
Only work on the project half the time, spending the other half on something more worthy/interesting.
Deliver under estimate and get a bonus, raise, influence, or just plain old "well done"
Be lazy and only work half the time while delivering "on time".
Only work on the project half the time, spending the other half on something more worthy/interesting.
>Only work on the project half the time, spending the other half on something more worthy/interesting.
This is actually a pretty common motivation for devs who work under legacy management.
This is actually a pretty common motivation for devs who work under legacy management.
And those who, thanks to WFH can handle two jobs at once.
>What’s the incentive for a developer to inflate their estimate?
Under-promise. Over-deliver. I'm not doing software development most of the time but it absolutely works out better for everyone concerned if I get things done on or ahead of schedule without mostly having to resort to a lot of unnatural acts to do so. If there's a real need for something faster, I'll tell people I'll do my best and (usually) I can get there absent blockers from dependencies. But I try to manage things so that I can meet/beat estimates sanely. It probably helps that people think I work quickly even given some sandbagging.
Under-promise. Over-deliver. I'm not doing software development most of the time but it absolutely works out better for everyone concerned if I get things done on or ahead of schedule without mostly having to resort to a lot of unnatural acts to do so. If there's a real need for something faster, I'll tell people I'll do my best and (usually) I can get there absent blockers from dependencies. But I try to manage things so that I can meet/beat estimates sanely. It probably helps that people think I work quickly even given some sandbagging.
The difference is that on average devs already underestimate, even when they try not to.
> “Pushing sales people to increase their amount of sales/quota is like asking meteorologists for sunshine”.
Depending on the economic climate and the situation of the company in the marketplace this may be accurate.
If you've got good sales people that are already selling as hard as they can't you won't be able to squeeze much more out of them if the economy tanks and nobody wants your product.
I'm sure there are sales people who have quit due to "the beatings will continue until the morale improves" situations where their quotas keep going up, which cuts their bonuses, effectively acting like a salary cut, in a bad company.
Depending on the economic climate and the situation of the company in the marketplace this may be accurate.
If you've got good sales people that are already selling as hard as they can't you won't be able to squeeze much more out of them if the economy tanks and nobody wants your product.
I'm sure there are sales people who have quit due to "the beatings will continue until the morale improves" situations where their quotas keep going up, which cuts their bonuses, effectively acting like a salary cut, in a bad company.
Heh, have we already forgot what happened with Wells Fargo? We need to upsale 10 accounts a day? Random accounts it is!
https://www.justice.gov/opa/pr/wells-fargo-agrees-pay-3-bill...
https://www.justice.gov/opa/pr/wells-fargo-agrees-pay-3-bill...
I've used a credit union for most of my adult life so don't really pay attention to Wells Fargo headlines. Don't know why anyone uses the major banks.
There’s a consistent belief here that Programming Isn’t Like Other Work™ and that you can’t estimate it, it’s so mentally taxing that you can’t do it for more than a few minutes at a time in complete silence, and that it’s closer to Da Vinci sculpting the Sistine Chapel than kludging together a few APIs.
It’s fun to think you’re special and easy to do when you’re paid a shitload of money.
It’s fun to think you’re special and easy to do when you’re paid a shitload of money.
Programming is like some kinds of work.
It is very much unlike operating an established manufacturing facility. But, about two thirds of dev work has a lot of parallels with creating a new manufacturing facility that manufactures a new kind of thing using new materials and techniques. The primary parallel is that a new facility requires a lot of discovery. Whereas if operating an existing facility constantly required a lot of discovery that disrupted operations it is likely the business team would pivot to something more lucrative.
Sadly most developers work in companies that have a manufacturing management system, which is inappropriate for managing development work, primarily because of pressure+timeline patterns typically applied via silo on silo kingdom building.
It is very much unlike operating an established manufacturing facility. But, about two thirds of dev work has a lot of parallels with creating a new manufacturing facility that manufactures a new kind of thing using new materials and techniques. The primary parallel is that a new facility requires a lot of discovery. Whereas if operating an existing facility constantly required a lot of discovery that disrupted operations it is likely the business team would pivot to something more lucrative.
Sadly most developers work in companies that have a manufacturing management system, which is inappropriate for managing development work, primarily because of pressure+timeline patterns typically applied via silo on silo kingdom building.
paulcole(3)
This is a bitter exaggeration. Programming is indeed distinctly unlike almost all other work that we have built experience managing as a society. It might be more accurate to say that it combines properties from other existing types of work that are not seen combined in any other type of work.
Go to any thread here on HN about WFH, open offices, 8-hour work days, etc. and tell me I’m wrong.
Regarding open offices. The Fed commissioned MIT to do a study on the effect of public observation and found that it significantly reduced people's effectiveness at solving puzzles.
Just proving my point. Significantly reducing some tech bros ability to do puzzles doesn’t mean that private offices are needed to make the 10,000,000th Rails app.
That entirely depends on whether or not the team is making something that is going to fulfill an unmet market need.
If they are in the majority of developers being mismanaged to crank out software that nobody wants, then have them code in an open office space with bullhorn wielding circa 1890s speed bosses yelling at them to type faster. It really makes no difference as most legacy business teams shirk their responsibility to get out of the building and figure out the real needs anyway, so might as well let the devs work on their craft until a real opportunity to make a difference comes along.
If they are in the majority of developers being mismanaged to crank out software that nobody wants, then have them code in an open office space with bullhorn wielding circa 1890s speed bosses yelling at them to type faster. It really makes no difference as most legacy business teams shirk their responsibility to get out of the building and figure out the real needs anyway, so might as well let the devs work on their craft until a real opportunity to make a difference comes along.
Yes, that’s exactly my point.
> “Pushing sales people to increase their amount of sales/quota is like asking meteorologists for sunshine”.
Not really, because those are not estimates. Also, consequences are different. With programmers, consequence is typically very buggy and hard to maintain software.
With sales, the consequence is a lot of fraud, followed by firing of every who is not comiting fraud and then even more fraud.
Not really, because those are not estimates. Also, consequences are different. With programmers, consequence is typically very buggy and hard to maintain software.
With sales, the consequence is a lot of fraud, followed by firing of every who is not comiting fraud and then even more fraud.
You forgot elk dinners at nice restaurants! I'll never forget when CA threw everyone parties to celebrate the sale of software the company couldn't use.
P.S. Not really, you covered it nicely under fraud
P.S. Not really, you covered it nicely under fraud
> “Pushing sales people to increase their amount of sales/quota is like asking meteorologists for sunshine”.
> Hmmm it doesn’t seem unreasonable in that context? You’re really asking people to work more effectively, to accomplish the same amount of work more quickly.
Sales quota is a target, estimate is not a target.
> And yet sales people aren’t writing article after article about how self-set quotas are sacrosanct, should only settable by sales people themselves, and how clueless management is to try to get more performance above the no-brainer target.
You mean you've never came across any post where people complain about unreasonable/unrealistic sales quota?
Sales quota is a target, estimate is not a target.
> And yet sales people aren’t writing article after article about how self-set quotas are sacrosanct, should only settable by sales people themselves, and how clueless management is to try to get more performance above the no-brainer target.
You mean you've never came across any post where people complain about unreasonable/unrealistic sales quota?
great analogy but why doesn’t anyone pay me more for crunching out more tickets?
Because you'll figure out how to crunch enough tickets for a minivan!
https://devhumor.com/media/dilbert-s-team-writes-a-minivan
https://devhumor.com/media/dilbert-s-team-writes-a-minivan
Good take. We don’t get any % of our marginal profit
> “Pushing sales people to increase their amount of sales/quota is like asking meteorologists for sunshine”.
This would be perfectly true if you replace it for a sales estimate, instead of quota.
The problem here is incompetent managers lying to inexperienced developers to get them into an expensive contractual obligation. It's borderline fraud, and yes, that means working with that manager is something to be avoided.
But going to a developer and plainly demanding him to finish the work on some time can be as perfectly fine as doing the same with sales people.
This would be perfectly true if you replace it for a sales estimate, instead of quota.
The problem here is incompetent managers lying to inexperienced developers to get them into an expensive contractual obligation. It's borderline fraud, and yes, that means working with that manager is something to be avoided.
But going to a developer and plainly demanding him to finish the work on some time can be as perfectly fine as doing the same with sales people.
There's some truth to what you say.
The problem is that sales can be objectively measured by management. In units.
How does management measure development output?
It can be done, but it take an experienced eng leader to do it.
The problem is that sales can be objectively measured by management. In units.
How does management measure development output?
It can be done, but it take an experienced eng leader to do it.
> Hmmm it doesn’t seem unreasonable in that context?
Asking meteorologists for sunshine is unequivocally unreasonable, so what you are saying here, I believe, is that the analogy does not apply to sales people, and arguably not in the case of devs either - which I agree with, up to an ill-defined point where wishes lose any contact with reality in any circumstance.
Asking meteorologists for sunshine is unequivocally unreasonable, so what you are saying here, I believe, is that the analogy does not apply to sales people, and arguably not in the case of devs either - which I agree with, up to an ill-defined point where wishes lose any contact with reality in any circumstance.
Yeah I think of sales people like farmers - there’s a lot they have to get right to get a good crop, but if conditions are poor, nobody gets anything.
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.
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.
> 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.
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!
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?
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.
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.
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”
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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?
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
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
[deleted]
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?
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.
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.
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.
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?
…
> 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?
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.
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.
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 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.
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.
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!
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
I get the point, and with irresponsible parties (as is fairly widespread in most companies) there's a real risk here.
However the analogy of a meteorologist seems poor as that job is focused on predicting the weather - the typical dev is focused on operating in that weather and comparatively inexperienced in predicting with great accuracy.
What's frustrating as a stakeholder is ludicrous estimates, which don't even start with the work time, let alone end up with a realistic duration. This is particularly true (and frustrating) at the micro task level, an area I'm often requiring items that take at most 30 minute to complete and are usually things I could do in less time if only I had access... You get a weeks long estimate back, even when it's incurring a serious cost in production and falls in the drop everything category (which obviously one wants to avoid but does come up). I get that none of those 30 minute tasks will take 30 minute alone as there's testing and documentation to add but the more bs level the estimate, the more it damages the trust relationship.
However the analogy of a meteorologist seems poor as that job is focused on predicting the weather - the typical dev is focused on operating in that weather and comparatively inexperienced in predicting with great accuracy.
What's frustrating as a stakeholder is ludicrous estimates, which don't even start with the work time, let alone end up with a realistic duration. This is particularly true (and frustrating) at the micro task level, an area I'm often requiring items that take at most 30 minute to complete and are usually things I could do in less time if only I had access... You get a weeks long estimate back, even when it's incurring a serious cost in production and falls in the drop everything category (which obviously one wants to avoid but does come up). I get that none of those 30 minute tasks will take 30 minute alone as there's testing and documentation to add but the more bs level the estimate, the more it damages the trust relationship.
I think there's an important detail you might have left out of your 30 minute example: are you asking for how long the effort on the specific task will take, or what the time gap will be between right now and the moment it's delivered? Because in almost all teams both are dominated by the task waiting for something, but in the latter case it's especially true. Actual hands-on-keyboard time is usually a rounding error compared to coordination and scheduling. Unless a team has put hard work into unintuitive ways of working, the average ticket will spend grossly more time waiting than actually being worked on. Not only that, but the team will be completely blind to the imbalance, and won't realise it matters.
Yeah, the 30 minute tasks would more frequently be quick if there was room for them.
You can have agile flexibility or you can have lists of tasks that you have attempted to minmax that people are tracked to finish. Not both. Flexibility costs significant down time, if you're not being given it then you're not being allowed to be flexible.
You can have agile flexibility or you can have lists of tasks that you have attempted to minmax that people are tracked to finish. Not both. Flexibility costs significant down time, if you're not being given it then you're not being allowed to be flexible.
This is really a case of over-utilisation. If you want a 30 minute task to be reliably out of the door in a time that's even of the same order of magnitude, the team has to be operating at 80% utilisation or less which, if it's the usual story of The Backlog That Never Ends, happens approximately never.
Correct. If management told our team that our performance was based on getting 2-3 planned features out this quarter, and we've been minmaxed to fill our schedules, and there's a hiring freeze and one team member just left - then we have no room for some "30 minute" (which is much more than 30 minutes for us) request. Also, management has told us that our performance reviews are based on whether we got these 2-3 planned features done within a very aggressive schedule, not your "30 minute" request - so it is management who has said this is of minimal importance, not us.
[deleted]
> Unless a team has put hard work into unintuitive ways of working, the average ticket will spend grossly more time waiting than actually being worked on.
What do you mean by "unintuitive ways of working"?
What do you mean by "unintuitive ways of working"?
Here's a relatively small example: if you want to minimise lead time (which is almost always true) then one thing you don't want is for potentially releasable work to sit waiting for anything. That includes code reviews, if you have them on the route to production. So the right thing to do is usually for a PR being ready for a code review to be a drop-everything event for the person who's going to review it. As in, whatever you're working on right now, context switch out and do whatever is needed to get that code either over the line or bounced back ASAP so the person who wrote it doesn't context switch out.
This idea gets a lot of pushback because we have it ingrained (not unfairly, either) that context switches are expensive for the reviewer. But the safe assumption is that they're less expensive than delaying another piece of work that's already got a lot of embodied but unrealised value.
The intuitive assumption is that person waiting on the code review can pick up another piece of work and make a start on it so they're kept busy, but that falls into the trap of having too much work in progress. The result is then (usually) that the returned code review is now waiting for whatever they picked up. This is one reason why the intuitive way of working tends to having throughput that's barely ok, and latency that borders on ridiculous.
This idea gets a lot of pushback because we have it ingrained (not unfairly, either) that context switches are expensive for the reviewer. But the safe assumption is that they're less expensive than delaying another piece of work that's already got a lot of embodied but unrealised value.
The intuitive assumption is that person waiting on the code review can pick up another piece of work and make a start on it so they're kept busy, but that falls into the trap of having too much work in progress. The result is then (usually) that the returned code review is now waiting for whatever they picked up. This is one reason why the intuitive way of working tends to having throughput that's barely ok, and latency that borders on ridiculous.
That's an interesting take!
I feel this pain,
I really do. I want to turn around to fix quickly.
The problem is unless you have fully-automated continuous deployment, 30 minutes is not 30 minutes. That 30 minute task needs to be vetted to ensure it doesn’t affect other departments, then it needs to be scheduled, announced, and deployed, which may involve 2 to 3 other people. As a scheduled task it’s closer to 2 hours across multiple people. As a hotfix or support ticket, it which becomes 4~6 hours of lost productivity for a hotfix if there is any kind of QA process beyond automated tests.
Add in six other people asking for “30 minute tasks” that have unknown impact on other people in the company and nothing will ever get done.
My team has workflows for hotfix changes, but it truly needs to be a drop-everything emergency that stops the company from operating. For all but the blindingly obvious, a department, head or higher, must make the request.
Not being able to turn around every urgent ticket is far less damaging than having a fix for one person cause problems for several other people or not delivering on large strategically-critical projects.
The problem is unless you have fully-automated continuous deployment, 30 minutes is not 30 minutes. That 30 minute task needs to be vetted to ensure it doesn’t affect other departments, then it needs to be scheduled, announced, and deployed, which may involve 2 to 3 other people. As a scheduled task it’s closer to 2 hours across multiple people. As a hotfix or support ticket, it which becomes 4~6 hours of lost productivity for a hotfix if there is any kind of QA process beyond automated tests.
Add in six other people asking for “30 minute tasks” that have unknown impact on other people in the company and nothing will ever get done.
My team has workflows for hotfix changes, but it truly needs to be a drop-everything emergency that stops the company from operating. For all but the blindingly obvious, a department, head or higher, must make the request.
Not being able to turn around every urgent ticket is far less damaging than having a fix for one person cause problems for several other people or not delivering on large strategically-critical projects.
This is way too true. So many quick changes or fixes at my company have caused incidents, confusion, and more. That 30 minute fix quickly balloons into days of work and unhappy clients.
Even things that don’t blow up on those have so many hidden costs people don’t think about.
Even things that don’t blow up on those have so many hidden costs people don’t think about.
> 30 minute to complete and are usually things I could do in less time
Why don't you? Surely there are ways of granting the required access in your organization?
If the answer is something akin to "not my job", then you have an organization that values intercommunicating pieces each with strict responsibilities. It should be expected that communication completely dominates output performance.
If properly tuned, such organizations can achieve good quality, and if the duties are well specified, also great throughput. But they will never have low latency, as turnaround time is sacrificed for other tings.
The example of a week long estimation for a trivial task is pretty much expected then. In a fully booked schedule, any new task is not likely to be scheduled for weeks. If that task then requires the attention of more than one person, because of the above fine grained responsibilities, those turnaround times really start to add up.
If that's not a good fit for the job at hand, the organization is just not suited for the task.
Why don't you? Surely there are ways of granting the required access in your organization?
If the answer is something akin to "not my job", then you have an organization that values intercommunicating pieces each with strict responsibilities. It should be expected that communication completely dominates output performance.
If properly tuned, such organizations can achieve good quality, and if the duties are well specified, also great throughput. But they will never have low latency, as turnaround time is sacrificed for other tings.
The example of a week long estimation for a trivial task is pretty much expected then. In a fully booked schedule, any new task is not likely to be scheduled for weeks. If that task then requires the attention of more than one person, because of the above fine grained responsibilities, those turnaround times really start to add up.
If that's not a good fit for the job at hand, the organization is just not suited for the task.
To some extend, but there’s tasks that I could do in 30m in a company with 15 employees that I have still not accomplished after 2 months in our 15k employee enterprise.
This so so much.
Some tasks take me 10 minutes but it takes me half a day to jump through all the hoops that our colleagues have thrown up. Excel approval sheets, annoying proxies with SSL inspection (try configuring all that in multiple docker containers), having no access to actually configure what I need to do so I constantly have to put in tickets to other teams..
The worst thing is when they then outsource the work and ask us why they can do it so much faster.... :X
Some tasks take me 10 minutes but it takes me half a day to jump through all the hoops that our colleagues have thrown up. Excel approval sheets, annoying proxies with SSL inspection (try configuring all that in multiple docker containers), having no access to actually configure what I need to do so I constantly have to put in tickets to other teams..
The worst thing is when they then outsource the work and ask us why they can do it so much faster.... :X
Large orgs almost become like a bloated government in that way: groups start to construct little fiefdoms with rules and policies that are ostensibly constructed to improve quality. However, those rules end up becoming bludgeoning tools used by nefarious actors in those groups.
The real problem is that nobody ever steps back and asks: are all these rules actually helping to improve quality of the software. Is the cost of the reduced velocity and overhead actually worth it in the end.
Then, the org does layoffs and all that policy is still in place without the necessary people to supported the bloated workflow.
The real problem is that nobody ever steps back and asks: are all these rules actually helping to improve quality of the software. Is the cost of the reduced velocity and overhead actually worth it in the end.
Then, the org does layoffs and all that policy is still in place without the necessary people to supported the bloated workflow.
Even this isn't really looking at the problem correctly.
If your two man organization if one person steals the source code or slips in some back door into the code, it should be somewhat obvious who did it.
On the other hand in that large enterprise someone doing the same could lead to an international incident. And with that many people you are going to have nefarious actors at some point and you need to think about how to minimize their damage.
It's likely you're falling into the same trap of understanding why Chestertons fence was put up in the first place.
If your two man organization if one person steals the source code or slips in some back door into the code, it should be somewhat obvious who did it.
On the other hand in that large enterprise someone doing the same could lead to an international incident. And with that many people you are going to have nefarious actors at some point and you need to think about how to minimize their damage.
It's likely you're falling into the same trap of understanding why Chestertons fence was put up in the first place.
The problem is, the whole mess becomes so abstracted away from the real goal: shipping software to customers and making money. Government can get away with it, because they're the only game in town, but a company doesn't have the luxury of operating with a crippling level of inefficiency for long.
Whatever 'deal with the devil' that existed when the fence was erected may no longer be relevant or worth the overhead, but the policies live on. There may even now be individuals who's jobs are now directly related to enforcing/implementing the policy, and they have an interest in perpetuating it at any cost.
Whatever 'deal with the devil' that existed when the fence was erected may no longer be relevant or worth the overhead, but the policies live on. There may even now be individuals who's jobs are now directly related to enforcing/implementing the policy, and they have an interest in perpetuating it at any cost.
> are all these rules actually helping to improve quality of the software
While I agree with your sentiment, high quality software (and: what is high quality, anyway?) is not necessary the goal of an enterprise.
While I agree with your sentiment, high quality software (and: what is high quality, anyway?) is not necessary the goal of an enterprise.
Faster development almost invariably is though. Everyone wants to be able to say their project got done on-time and according to spec.
Linear scaling is more the exception than the rule, no? And it not just for "tech" either: it's unlikely you could learn the names of 15k employees in 2 months, for instance.
Don't ask for 30 minutes tasks unless you have to (it's breaking the prod or something), it's inefficient for everyone involved.
I'm in a team with a lot of leeway. No one is counting my hours, no one external look at our productivity, but when we're needed, we don't have time to polish our code. When i have a '30 minute' task identified, I put it in our morning review, and ask if something adjacent should be done while I'm on the subject. If there is nothing, I'll still take the full day (except if it's a project I know really well, in that case I take half), and take half a day to skim the code, and another half to update it (small comment, version upgrade, code improvement, renaming variables).
Push your IC to do the same. Imo it's more time efficient, the new-ish IC use that time to learn the older code, and in the end you will have less legacy issues (unless you make a big change).
I'm in a team with a lot of leeway. No one is counting my hours, no one external look at our productivity, but when we're needed, we don't have time to polish our code. When i have a '30 minute' task identified, I put it in our morning review, and ask if something adjacent should be done while I'm on the subject. If there is nothing, I'll still take the full day (except if it's a project I know really well, in that case I take half), and take half a day to skim the code, and another half to update it (small comment, version upgrade, code improvement, renaming variables).
Push your IC to do the same. Imo it's more time efficient, the new-ish IC use that time to learn the older code, and in the end you will have less legacy issues (unless you make a big change).
Any downsides to this approach, from your experience?
I only have 10 month working like this, but yes. More linked to the code than to the approach, but sometimes I become easy to get lost on the 'I also need to fix this' and deliver the code _really_ late. My way of dealing with it is simple: at 4pm (I usually stop at 6), I take a 15 minutes break, talk with people (remote or not), make some tea and stuff, recenter myself. Then I check what can be merged into master before 6, scrap the commits I won't use, rebase the rest into one or two commits, then push and ask for review (once it was the '30 minute task' that pulled a lot of other shit, in this case I stopped and called the team lead/PM to redefine the card).
Then if I still have time I do reviews, administrative work and probably end the day there. The nature of our team make that time management suitable.
Then if I still have time I do reviews, administrative work and probably end the day there. The nature of our team make that time management suitable.
Ludricrous estimates are usually a symptom of other organizational quirks.
I'd compare it to the military's $435 hammer [0], from the outside you'd think it makes no sense, but that's the logical end of a series of processes that all somehwat made sense on their own.
A common issue I've seen is devs having to put their head on the chopping block when making estimates. After the second or third time they get seriously punished for blowing pat deadlines, they'll happily go with around 10 times their own estimate. But there's so many other incentives where going with a "done in 2h" estimate is just a bad decision.
[0] https://www.washingtonpost.com/blogs/wonkblog/post/the-penta...
I'd compare it to the military's $435 hammer [0], from the outside you'd think it makes no sense, but that's the logical end of a series of processes that all somehwat made sense on their own.
A common issue I've seen is devs having to put their head on the chopping block when making estimates. After the second or third time they get seriously punished for blowing pat deadlines, they'll happily go with around 10 times their own estimate. But there's so many other incentives where going with a "done in 2h" estimate is just a bad decision.
[0] https://www.washingtonpost.com/blogs/wonkblog/post/the-penta...
Oh wow, I had no idea the story of the $600 hammer was still around. This has been a talking point for like 40 years now, and it was a different number when I was a little kid. Turns out the story had been debunked at least 13 years before the article you posted was written, and is 25 years old now. The military never paid hundreds of dollars for a hammer, someone just averaged a bunch of financial R&D overhead and then someone else took the numbers out of context and spread it around. https://www.govexec.com/federal-news/1998/12/the-myth-of-the...
I would not say it has been "debunked".
The stories are real; they're not all "accounting misunderstandings" or what have you.
[1] https://www.airforcetimes.com/news/your-air-force/2018/10/23...
The stories are real; they're not all "accounting misunderstandings" or what have you.
[1] https://www.airforcetimes.com/news/your-air-force/2018/10/23...
The averageing of the numbers is also the take of the article I checked, but to me it stays a good example of the phenomenon: that contract with no itemized prices and a high average price per item fits inside a procedure that probably isn't bad in itself, but gets turned into spicy headlines.
Yep, these days I tend suss out the estimate the person is looking for because the relationship is actually more important to my career longevity. I mean, the estimate is very likely wrong anyway, so they might as well be happy for a bit!
This works because almost never is the true scope of the work known when the ask is made, so it is usually pretty easy to say later "hey, blah blah blah wasn't taken into account for the estimate." Having a good relationship from step one makes it pretty easy to carve out the extra time.
There are some more lizard brained people who play hardball, but as long as I was nice in step 1, my VP handles them. Not sure what I would do if I didn't have a decent VP!
This works because almost never is the true scope of the work known when the ask is made, so it is usually pretty easy to say later "hey, blah blah blah wasn't taken into account for the estimate." Having a good relationship from step one makes it pretty easy to carve out the extra time.
There are some more lizard brained people who play hardball, but as long as I was nice in step 1, my VP handles them. Not sure what I would do if I didn't have a decent VP!
> Not sure what I would do if I didn't have a decent VP!
Learn how to actually do your job?
It’s always interesting to see toxic positivity painted in such a favorable light. Very glad I don’t work with you.
Learn how to actually do your job?
It’s always interesting to see toxic positivity painted in such a favorable light. Very glad I don’t work with you.
If you are like most business people I've worked with, you love my complicity.
I get people like you fired.
I promise you what you are experiencing is a management problem, not a dev problem. Devs absolutely love executing on creating easy to code software solutions to well defined problems. Many of us will work the weekend on that kind of work just to get the dopamine rush.
I have never had the misfortune to work in a place even remotely that dysfunctional, and I feel that there must be a considerable history behind it becoming that way.
The only magic wand in software development is to simplify requirements. The requirements are always wrong: too broad, too vague, based on invalid assumptions
The real genius is to propose a simplified solution, by discarding some assumptions. This is the best and only way to shrink the schedule
The real genius is to propose a simplified solution, by discarding some assumptions. This is the best and only way to shrink the schedule
> The only magic wand in software development is to simplify requirements. The requirements are always wrong: too broad, too vague, based on invalid assumptions
I think it's less simplification and more precision and completeness. Obviously if you have simpler requirements they more complete and precise, but the requirement might not actually be simplifiable. In which case what you want is better specification.
"They write the right stuff" about the shuttle software group is basically a story about doing that: https://www.fastcompany.com/28121/they-write-right-stuff
I think it's less simplification and more precision and completeness. Obviously if you have simpler requirements they more complete and precise, but the requirement might not actually be simplifiable. In which case what you want is better specification.
"They write the right stuff" about the shuttle software group is basically a story about doing that: https://www.fastcompany.com/28121/they-write-right-stuff
As a developer I hate "precise" and "complete" requirements. Usually these extremely detailed roadmaps are just fairy tales. They indicate a management and product mindset that thinks you can pre-chew a developer's food for them and make things more predictable.
In fact, what you are doing is tying the developer's hands and making it less possible for them to nimbly work around unforeseen obstacles or repurpose existing solutions without raising a "process exception" to reopen the spec or sizing of a work item.
Be clear about the goals but let the developer(s) who have their hands in the code make the decisions about how to implement it. That means you can't really roadmap a big project down to the minute, but those roadmaps were always lies so there is literally nothing lost except for some fantasy Gantt charts.
In fact, what you are doing is tying the developer's hands and making it less possible for them to nimbly work around unforeseen obstacles or repurpose existing solutions without raising a "process exception" to reopen the spec or sizing of a work item.
Be clear about the goals but let the developer(s) who have their hands in the code make the decisions about how to implement it. That means you can't really roadmap a big project down to the minute, but those roadmaps were always lies so there is literally nothing lost except for some fantasy Gantt charts.
“Everyone has a plan until they get punched in the mouth.”
The problems with precise specs is that they miss all the dozens of edge cases and gotchas that don't crop up until you actually try to code them. Then you need smart, imaginative devs to ignore the specs and write something that people can actually use.
I've worked with devs who write _only_ to the spec and never diverge at all, regardless of outcome, in order to check off boxes and make their managers happy. Their work sucks.
(this might not apply if you are writing code for moonships)
The problems with precise specs is that they miss all the dozens of edge cases and gotchas that don't crop up until you actually try to code them. Then you need smart, imaginative devs to ignore the specs and write something that people can actually use.
I've worked with devs who write _only_ to the spec and never diverge at all, regardless of outcome, in order to check off boxes and make their managers happy. Their work sucks.
(this might not apply if you are writing code for moonships)
[deleted]
That's why developers should be the ones taking a step forward to make vague requirements "complete" and "precise". They will satisfy the business goals and there won't be fairy tales.
Well, that's the nature of software.
If the requirements were actually precise and concrete, you could commit them to git and that would be the end of it.
The fact that they aren't is a sign of information deficit and this must be understood by all parties if we should have any chance of a productive outcome.
If the requirements were actually precise and concrete, you could commit them to git and that would be the end of it.
The fact that they aren't is a sign of information deficit and this must be understood by all parties if we should have any chance of a productive outcome.
What if one party is incentivized to create said information deficit?
> As a developer I hate "precise" and "complete" requirements. Usually these extremely detailed roadmaps are just fairy tales.
Requirements and roadmaps are very different in my opinion. Requirements say what the product needs to do, scaling and/or response time targets, systems or needs to integrate with, etc. Roadmaps are either a high level plan for where the project goes in the future or a list of seemingly arbitrary deadlines.
Both have their place, but in my experience the right balance has been precise and complete specs with a high level, flexible roadmap.
Requirements and roadmaps are very different in my opinion. Requirements say what the product needs to do, scaling and/or response time targets, systems or needs to integrate with, etc. Roadmaps are either a high level plan for where the project goes in the future or a list of seemingly arbitrary deadlines.
Both have their place, but in my experience the right balance has been precise and complete specs with a high level, flexible roadmap.
Yep it is very unlikely that the business silo has a clue what needs to be built.
Yes. I very much agree. Not only are most software bugs actually requirements bugs, the speed you can build software with good requirements is absolutely bonkers.
I've seen a project go from an empty repo to production in two months with a set of requirements that were completely unambiguous and rock solid. I've also seen ambiguous and vacillating requirements drag out the implementation a ~30 LOC feature for months.
I've seen a project go from an empty repo to production in two months with a set of requirements that were completely unambiguous and rock solid. I've also seen ambiguous and vacillating requirements drag out the implementation a ~30 LOC feature for months.
Oh, but we need the full search functionality right now, yes there are only tens of entries now but in a few years there will be thousands. And the designer will design all the search flows based on our twenty page product requirements doc, and we will include engineering to write stories and estimate the works once it's all planned and prepared.
Also some designers throw in too many features because they want to fill space in the design.
I think they want to be helpful and leave their mark, which sometimes includes trying to reinvent boring CRUD designs and borrowing some cool but more involved ux pattern they saw in a big-money product. Adopting a popular 3rd party component library sometimes helps, but for some reason it's hard to push back on tweaking the behavior of these components all the time, and usually those component libraries are such that they include everything but the kitchen sink, well... except that one thing that the designer is insisting on. And that one is really hard to do with that library and takes way more time than anticipated. The value-add here is in my experience almost always negative. Looking back at delivered projects, I can't shake the feeling that involving designers at a later stage would be beneficial to the project and timelines.
Contractor I know, always answers "Can you do it quicker and cheaper?" with "Yes. What do you want me to leave out?"
And devs are in the perfect position to take on this responsibility. They usually have sufficient domain knowledge and know what it takes to build stuff in this context.
This assumes a developer whose workflow is more or less optimized.
This is why Professional Communications is so critical for software developers, and exactly why your manager absolutely does not want you to have such skills: you'll be able to explain why their requests are manipulative, unrealistic, and frankly pointy haired wishful nonsense.
Your workplace may be toxic. My manager celebrates simplification and cost reduction when it solves business problems.
Completely different topic. I'm not even referencing "my workplace", I'm talking our entire industry.
Then you’re just empirically wrong. I’ve never had managers who didn’t want me to have professional communication skills in the ten years I’ve been in our industry.
You manager wants you to agree to the work they ask you to perform, and they want to load you up with work to maximize your efficiency. How one negotiates when you're reaching capacity is professional communications. If one is unable to attain work/life balance that is due to a lack of communication skills, the lack of the ability to explain you're past ordinary capacity, burning your health. Our industry is over run with members over working - that's due to their inability to communicate the are over capacity.
My current manager asks me to define the work, and has asked me not to do certain things because he feared it would overload me. He values professional communication and endorses people who want to improve them, going so far as to allocate work time and support them financially in their efforts to learn.
I’ve also been a manager at 3 different companies, one of them my own, and my philosophy has not been to push deadlines or work, but to spend more time understanding requirements, and simply try to break down long-running projects into small pieces that can be estimated more accurately. One of the biggest problems I’ve witnessed in software is that estimates in units of years are always very wrong, while estimates in units of days or weeks are pretty good.
I have to agree with the parent; you’re making incorrect assumptions and maybe projecting your own bad experience, and ending up accidentally saying something that isn’t true.
I’ve also been a manager at 3 different companies, one of them my own, and my philosophy has not been to push deadlines or work, but to spend more time understanding requirements, and simply try to break down long-running projects into small pieces that can be estimated more accurately. One of the biggest problems I’ve witnessed in software is that estimates in units of years are always very wrong, while estimates in units of days or weeks are pretty good.
I have to agree with the parent; you’re making incorrect assumptions and maybe projecting your own bad experience, and ending up accidentally saying something that isn’t true.
They're not wrong. Our industry has a burnout problem. Some places are nicer than others to work at, but that doesn't mean the industry as a whole doesn't have problems.
I have met such managers you talk about but from my personal experience they are not a majority. Maybe I have been lucky or you have been unlucky.
Please don't generalise or you wipe out the occasional good that does exist.
Now seriously, my comment is a call for people to acquire professional communication skills, because they are extremely useful when negotiating work in far too many areas to count. Such advice getting down voted indicates how little value quality communications has within the software developer community - to the industry's demise. Communications are everything, and if you don't have good communication skills you get overlooked, abused, and misunderstood... leading to career frustration, stagnation, and burnout.
Tbh, I downvoted you not because I don’t value quality communications, but because negotiating around your capacity is a small slice of professional communication, and your approach is needlessly adversarial. You will experience a lot of useless friction in your life by taking that approach.
Good communication isn’t adversarial: by the time it becomes adversarial, you’ve already lost. It can include solid documentation, taking the time to mentor others, respectful but clear code reviews, helping others argue your case for rescoping, presenting your work at meet-ups or conferences, hallway testing a new feature, listening to teammates explain an approach…
…and yes, sometimes negotiating capacity. If that feels like an adversarial conversation, then your manager sucks, and you should find a new one.
Good communication isn’t adversarial: by the time it becomes adversarial, you’ve already lost. It can include solid documentation, taking the time to mentor others, respectful but clear code reviews, helping others argue your case for rescoping, presenting your work at meet-ups or conferences, hallway testing a new feature, listening to teammates explain an approach…
…and yes, sometimes negotiating capacity. If that feels like an adversarial conversation, then your manager sucks, and you should find a new one.
I don’t think you’re being downvoted because you’re promoting improved communication skills. I think you’re being downvoted because you’re implying that managers “absolutely does not want you to have such skills”.
I’d wager portraying an important work relationship as adverserial and manipulative is why people downvote you. It’s a bit of an overplayed cliché with the bad boss.
Ironically you might be downvoted because of what you’re saying being misunderstood, which I guess is to your point.
I’d wager portraying an important work relationship as adverserial and manipulative is why people downvote you. It’s a bit of an overplayed cliché with the bad boss.
Ironically you might be downvoted because of what you’re saying being misunderstood, which I guess is to your point.
A valuable discussion to have is about how to change the scope so that the cost/return tradeoff is right for your stakeholders.
I've definitely seen devs assume too much needs to be done, just like I've seen non-devs ignore key parts of the problem that push up the time. Sometimes it's trying to make a general solution when actually what's needed is someone to sit down with a spreadsheet for a day.
> There is back-and-forth as the estimates are questioned for being too high, almost never for being too low.
I'm sure people will have flashbacks when I say this so sorry to those, but this is the issue addressed with planning poker. The idea being that you all say how hard the task is, without being affected by each other, and discuss when expectations aren't aligned. Someone is probably missing something.
I might think something is simple because I've not realised a complex part of the problem, or because I can see a nicer neater solution.
I've definitely seen devs assume too much needs to be done, just like I've seen non-devs ignore key parts of the problem that push up the time. Sometimes it's trying to make a general solution when actually what's needed is someone to sit down with a spreadsheet for a day.
> There is back-and-forth as the estimates are questioned for being too high, almost never for being too low.
I'm sure people will have flashbacks when I say this so sorry to those, but this is the issue addressed with planning poker. The idea being that you all say how hard the task is, without being affected by each other, and discuss when expectations aren't aligned. Someone is probably missing something.
I might think something is simple because I've not realised a complex part of the problem, or because I can see a nicer neater solution.
I get that. But as a tech guy I sometimes get itchy when the actual reality of things is ignored. A good example would be when a customer demands something that is mathematically or physically not possible. With wishes like these you could the do the planning poker all day and maybe land at a compromise that is still not possible.
As a former freelancer I am a big fan of just getting a thorough explaination of the problem, maybe with me looking over the shoulder of someone who has to solve it currently. And then I vanish in a hole for a few days and return with the design proposal I think would most elegantly, reliably etc solve the problem.
Unless we are speaking about people who have good experience with complex problems, most people are okay at describing their problems, but suck at proposing solutions (they are always modelled after the limited things they know).
As a former freelancer I am a big fan of just getting a thorough explaination of the problem, maybe with me looking over the shoulder of someone who has to solve it currently. And then I vanish in a hole for a few days and return with the design proposal I think would most elegantly, reliably etc solve the problem.
Unless we are speaking about people who have good experience with complex problems, most people are okay at describing their problems, but suck at proposing solutions (they are always modelled after the limited things they know).
Always a good time to rewatch the expert: https://youtu.be/BKorP55Aqvg?si=eqw2-mWA1T3FDUtl
> most people are okay at describing their problems, but suck at proposing solutions
Yes, it's best to focus on their problems and the consequences of proposed solutions. They shouldn't care about your caching strategy internals but they do care about whether stale info impacts their users or what scale it's reasonable to hit, or how much extra it'll cost to implement.
> most people are okay at describing their problems, but suck at proposing solutions
Yes, it's best to focus on their problems and the consequences of proposed solutions. They shouldn't care about your caching strategy internals but they do care about whether stale info impacts their users or what scale it's reasonable to hit, or how much extra it'll cost to implement.
> I've definitely seen devs assume too much needs to be done
Absolutely this, and managers and pseudo-managers like product owners, business analysts and full-time scrum masters do too. I see a lot of weird requirements, often technical in nature, that nobody actually asked for, it was just a long string of people who just assumed. Like an infinitely scalable microservice architecture with a full SPA just to let a dozen internal users download some data as an Excel spreadsheet.
Absolutely this, and managers and pseudo-managers like product owners, business analysts and full-time scrum masters do too. I see a lot of weird requirements, often technical in nature, that nobody actually asked for, it was just a long string of people who just assumed. Like an infinitely scalable microservice architecture with a full SPA just to let a dozen internal users download some data as an Excel spreadsheet.
>but this is the issue addressed with planning poker.
It isn't. Having a team which is both intimately familiar enough with the set of features as a whole, and understands how to use the system to get around the inevitable 'A does it in X while B does it in X*3', are both prerequisites. Suffice to say, with the amount of discussion based around Scrum being done wrong alone, neither of those are even remotely a given. This also doesn't take into account turnover and new features being able to remove a team from meeting those prerequisites at any point.
Too often it just devolves into people raising eyebrows at one another and either it becomes 'X will do it, so X's estimate becomes the value' (why even bother doing poker then) or 'take the average or minimum' which screws over anyone who estimated higher.
It isn't. Having a team which is both intimately familiar enough with the set of features as a whole, and understands how to use the system to get around the inevitable 'A does it in X while B does it in X*3', are both prerequisites. Suffice to say, with the amount of discussion based around Scrum being done wrong alone, neither of those are even remotely a given. This also doesn't take into account turnover and new features being able to remove a team from meeting those prerequisites at any point.
Too often it just devolves into people raising eyebrows at one another and either it becomes 'X will do it, so X's estimate becomes the value' (why even bother doing poker then) or 'take the average or minimum' which screws over anyone who estimated higher.
I mean it is literally the issue that planning poker addresses - identify differing expectations without influencing the initial estimate. People can then totally ignore that, and ignoring something makes it pointless, but that's true of literally anything.
It identifies a lack of a shared understanding of the task. Or framed differently, it identifies when you probably all have the same expectation and you can move on.
It identifies a lack of a shared understanding of the task. Or framed differently, it identifies when you probably all have the same expectation and you can move on.
That still doesn't solve the prerequisites being exceedingly rare in most teams. A system solving an issue under rare circumstances is barely worth considering, doubly so if it doesn't solve the issue in your specific circumstance. That's, again, disregarding that the modus operandi of most management teams directly interferes with planning poker itself (high turnover, high focus on increasing scope and scope per person).
Or we can dive into technicalities where it technically does solve the issue but does it poorly, and just happens to be better than any other system we know (also questionable).
Or we can dive into technicalities where it technically does solve the issue but does it poorly, and just happens to be better than any other system we know (also questionable).
I honestly do not understand what you're describing as the prerequisites.
You ask people how hard something is to do, make everyone actually answer before hearing others opinions and if people disagree you talk about it to understand why. These are all short term features.
The two things it deals with are:
* get everyone to say how big of a thing it is, find out if there's misunderstandings about what the task involves
* avoid people from being influenced by the fastest to answer person
That's it. It's a very basic communication tool.
You ask people how hard something is to do, make everyone actually answer before hearing others opinions and if people disagree you talk about it to understand why. These are all short term features.
The two things it deals with are:
* get everyone to say how big of a thing it is, find out if there's misunderstandings about what the task involves
* avoid people from being influenced by the fastest to answer person
That's it. It's a very basic communication tool.
I'm sure that's how it was intended but tbh I have only seen it used in settings where the person in charge would still want to assign a value to the ticket "so that we can move on" even if the devs were not at all in agreement about how big something was. Whoever gets the ticket in the end is stuck with the estimate, even if it was shit from the very start.
If people are unable to solve the problem themselves but instead defer to someone else’s estimate then they should not be participating in planning poker
They shouldn’t be bidding, but participating to answer clarifying questions or discuss tradeoffs seems healthy.
It's more Machiavellian than that. What the middleman wants is a heads I win, tails you lose deal.
He wants to present a low number, to encourage whoever he's dealing with on his end to do what he wants, gaining the benefit from that.
So he'll use every technique under the sun to encourage devs to give him a number he likes more, while never making it look like an order or coercion (which would make it his number - spoiling the whole play).
But when it inevitably takes much longer, he can point at the numbers the devs provided and say he was just communicating what they told him, so he's not responsible.
The only language these types understand is for requests for estimates to be "reviewed" to result in them always going up, to send a message.
He wants to present a low number, to encourage whoever he's dealing with on his end to do what he wants, gaining the benefit from that.
So he'll use every technique under the sun to encourage devs to give him a number he likes more, while never making it look like an order or coercion (which would make it his number - spoiling the whole play).
But when it inevitably takes much longer, he can point at the numbers the devs provided and say he was just communicating what they told him, so he's not responsible.
The only language these types understand is for requests for estimates to be "reviewed" to result in them always going up, to send a message.
I swear I hate this estimates thing so hard.
For many reasons:
1) Estimations should be useful so business can adapt. In reality there's no adaptation of any sort, your PM will get the stick from its own boss that stuff needs to be ready by this or that more-or-less vague deadline. Thus, what am I estimating for if you don't care about my estimation anyway?
2) There are no incentives for teams ultimately to estimate anything realistically. What do you get for being accurate? A medal? In fact, all incentives go towards inflating the amount of work through estimates.
3) Ultimately all this dancing of estimates and rituals is nothing else but stuff that management embraces to appear more effectful and impactful than it really is.
For many reasons:
1) Estimations should be useful so business can adapt. In reality there's no adaptation of any sort, your PM will get the stick from its own boss that stuff needs to be ready by this or that more-or-less vague deadline. Thus, what am I estimating for if you don't care about my estimation anyway?
2) There are no incentives for teams ultimately to estimate anything realistically. What do you get for being accurate? A medal? In fact, all incentives go towards inflating the amount of work through estimates.
3) Ultimately all this dancing of estimates and rituals is nothing else but stuff that management embraces to appear more effectful and impactful than it really is.
Most impressive statement I ever heard said in a meeting between management and engineers about a project's progress was a long-tenured dev saying "it'll be done when it's done", followed by silence, and then they let it be.
To this day I still don't know how this event came to pass.
To this day I still don't know how this event came to pass.
Yeah if you estimate realistically many companies have a culture that will punish you for not being a team player.
Sometimes, but not always.
I've been on both sides of this situation. As an engineer I'm always adamant - yep, no way this could be done any faster and please stop pressuring me to just get the number you want to hear. It'll be done when it's done, and it'll be robust and good. Now please go away and let me cook.
But when I've been the manager pushing for smaller estimates, it's been because the business realities were that delivering *something* in a given time frame is critical. And if it requires making a house of cards and cutting corners, well at least we'll have survived long enough to deal with that problem later. And when I've been in that situation I received the usual pushback from engineering - the same pushback I would give in their shoes - that this is a terrible idea, will doom us to fail in the future, and we need to put in the leg work now to avoid future pain.
I've gone back to being an engineer but that experience as a manager has helped me quite a bit when dealing with this sort of divide.
I've been on both sides of this situation. As an engineer I'm always adamant - yep, no way this could be done any faster and please stop pressuring me to just get the number you want to hear. It'll be done when it's done, and it'll be robust and good. Now please go away and let me cook.
But when I've been the manager pushing for smaller estimates, it's been because the business realities were that delivering *something* in a given time frame is critical. And if it requires making a house of cards and cutting corners, well at least we'll have survived long enough to deal with that problem later. And when I've been in that situation I received the usual pushback from engineering - the same pushback I would give in their shoes - that this is a terrible idea, will doom us to fail in the future, and we need to put in the leg work now to avoid future pain.
I've gone back to being an engineer but that experience as a manager has helped me quite a bit when dealing with this sort of divide.
If you need a stable software released by Christmas, you go to your developers and say "people, we need to release a stable version of this by Christmas".
You don't say "hey, how long do you need to do X, Y, and Z? Oh, no, that's too much time, how can you shorten it?"
You don't say "hey, how long do you need to do X, Y, and Z? Oh, no, that's too much time, how can you shorten it?"
I agree with this. Incidentally, some of my most productive periods were when the team was given a real deadline. Often times either the deadline is made up entirely or there’s a generally understood sense that it can easily be pushed back. I find that if I can trust that the constraint is a real one it really helps us to scope things out of necessity.
My theory is a lot of the never ending development cycles is because engineers don’t actually believe the constraints are hard, which leads to scope creep or at least the development getting stretched out.
It is entirely reasonable for the business to say "we need X in Y weeks" — it still might not be possible, most of the time engineers can make _something_.
What's unreasonable is saying "we need X in Y weeks, and it needs to be done properly". It will take a certain amount of time to do anything properly, and that doesn't change with pressure.
What's unreasonable is saying "we need X in Y weeks, and it needs to be done properly". It will take a certain amount of time to do anything properly, and that doesn't change with pressure.
Yes, exactly.
As a manager when I've pushed back on estimates it was because the engineers were pushing for "done properly". Where "done properly" didn't mean more features but building a more solid foundation. And I 100% understood the desire, but at a higher level the long term cost of not having that solid foundation was worth incurring.
Requiring both "fast" and "good" is foolish.
As a manager when I've pushed back on estimates it was because the engineers were pushing for "done properly". Where "done properly" didn't mean more features but building a more solid foundation. And I 100% understood the desire, but at a higher level the long term cost of not having that solid foundation was worth incurring.
Requiring both "fast" and "good" is foolish.
What you are describing is shit managers.
If corners need to be cut for valid business reasons then there shouldn't be any real push back from the devs, because they have the business context laid out for them.
Every dev I've ever worked with will say "yup, I understand. I might not like it, but I understand" when given the context of pushes for quicker delivery.
But that requires understanding on both side that you are sacrificing quality to hit a date, and that has its own costs.
Mostly this all boils down to: talk to people like they are you colleagues, don't order them around, find a solution together.
If corners need to be cut for valid business reasons then there shouldn't be any real push back from the devs, because they have the business context laid out for them.
Every dev I've ever worked with will say "yup, I understand. I might not like it, but I understand" when given the context of pushes for quicker delivery.
But that requires understanding on both side that you are sacrificing quality to hit a date, and that has its own costs.
Mostly this all boils down to: talk to people like they are you colleagues, don't order them around, find a solution together.
But it’s easy working for such people once you identify them. They are “goes to 11” people. Like that amp in spinal tap you just make your regular output max level be a 9, then you have room to go 1 more when they want you to. Of course that means working slower than you otherwise would. But if they want a dev that “goes to 11” it’s pretty obvious to some of us that there’s only one way that works.
This is very true. And this is exactly my manager and the skip - pushing arbitrary deadlines, not because some customer is waiting for it, but because they want to look good to their own bosses. When the estimate inevitably fails, they all raise their hands and start pipping people for their own poor estimation.
As an engineer, imagine living under this constant stress, missing time with your family and friends, and for what? Just to make your own manager's incompetent estimation look good?
As an engineer, imagine living under this constant stress, missing time with your family and friends, and for what? Just to make your own manager's incompetent estimation look good?
Yeah, this part is getting lost and there's a lot of apologists here. One of the oldest tricks in the book is to create a vision, make a promise, and then say "I did my job, now engineering just has to do theirs"
I'm reminded of a manager that would add features as I was finalizing a release, sometimes hours before without telling me. He would even add features to releases that already happened. In his mind, he seemed to think that he could just attach the features to a release, and bam. it's done!
I'm reminded of a manager that would add features as I was finalizing a release, sometimes hours before without telling me. He would even add features to releases that already happened. In his mind, he seemed to think that he could just attach the features to a release, and bam. it's done!
Your are correct in the majority of places where developers work. And this is simply because most developers work under legacy management where they are siloed off from the business - so typical Machiavellian silo on silo violence is employed to get one silo to commit to the desires of another silo.
It's crazy because the customer gets totally hosed by bad software implementations, and if good working software is actually important to the future of the business, a slow march towards bankruptcy happens.
It's crazy because the customer gets totally hosed by bad software implementations, and if good working software is actually important to the future of the business, a slow march towards bankruptcy happens.
I think the biggest challenge I have is that people will immediately ask for estimates when the project is barely a paragraph description. On top of that, my feeling is always "it depends on how much tech debt is in the code after I look in there."
The only reasonable response I've had is "I need 1-2 days to both push you on solidifying these requirements, and stop & audit the codebase to look for any risks before starting".
Is there anything I could be doing better here?
The only reasonable response I've had is "I need 1-2 days to both push you on solidifying these requirements, and stop & audit the codebase to look for any risks before starting".
Is there anything I could be doing better here?
I have found success with having a session with the PM where the goal is not to have complete, perfect cards, but at least one ticket for every thing you can think you will need to do on the project.
So you’ll have a bunch of one liner cards, but at smaller fidelity, like
- Make a bulk create API endpoint - Migrate data from old to new table
Then, if there are 5 or more cards there, make your estimate
((number_of_cards / number_of_devs) * est_business_days_per_card) + est_pto_days
It will not be accurate - but it will leave the PM and their boss feeling like the estimate was thought out and reasonable at the time, and any necessary delays will go over easier (“we estimated assuming every card was about the same number of days, but these two cards were large outliers that took longer than expected.”)
Much like the normal sprint process, but without the need to keep a track of sprint velocity beyond a gut feel.
So you’ll have a bunch of one liner cards, but at smaller fidelity, like
- Make a bulk create API endpoint - Migrate data from old to new table
Then, if there are 5 or more cards there, make your estimate
((number_of_cards / number_of_devs) * est_business_days_per_card) + est_pto_days
It will not be accurate - but it will leave the PM and their boss feeling like the estimate was thought out and reasonable at the time, and any necessary delays will go over easier (“we estimated assuming every card was about the same number of days, but these two cards were large outliers that took longer than expected.”)
Much like the normal sprint process, but without the need to keep a track of sprint velocity beyond a gut feel.
This is the problem I have at the moment as well:
Company Leadership asks for estimate with barely any information, I will then say that I need to learn more about the project and look into the codebase, leadership then says that they "just" need to have an estimate to approve this work and if they want to do this project at all. Around and around it goes until I give them a large estimate (which is large because of all the unknowns including the unknown scope) which is then too much and too expensive for leadership.
Company Leadership asks for estimate with barely any information, I will then say that I need to learn more about the project and look into the codebase, leadership then says that they "just" need to have an estimate to approve this work and if they want to do this project at all. Around and around it goes until I give them a large estimate (which is large because of all the unknowns including the unknown scope) which is then too much and too expensive for leadership.
I was interviewing a CISO for a prior job. We asked how they would expand our team, given what we have and what we do. The candidate said that a typical team needs X, Y, and Z, but they really couldn't make an informed decision like that without being in the environment for at least a few months and seeing the way that things actually work.
My peers and I, who would report directly to the CISO, loved the answer. One of the CISO's potential peers on the interview panel thought that the candidate bombed the question, because "shouldn't they just know what's needed?"
My peers and I, who would report directly to the CISO, loved the answer. One of the CISO's potential peers on the interview panel thought that the candidate bombed the question, because "shouldn't they just know what's needed?"
Reminds me of the time an estimator asked me how much it costs “to program a PLC.” I asked what the PLC had to do and they said “just a normal one.” Pretty sure I answered “probably between $5 and $100k.”
You’re doing the right thing, but you need to speak their language.
In Agile speak, that’s a 3 point spike ticket, for which the deliverable is a detailed set of requirements and deliverables with estimates with considered trade-offs. It’s a totally normal thing to do.
You can give an estimate before doing the spike, but maximally caveat it. Like “60% confidence it’ll take fewer than 3 weeks, 80% 5 weeks, 90% 6”.
I’d generally recommend refusing to give deadline estimates beyond a week or two (unless it’s absolutely necessary as it sometimes is), preferring piecemeal estimates (i.e. this project is composed of 7 deliverables each taking 1-2 days of work). Reason is that it might take 10 days of engineering work to do something, but due to shifting priorities etc., the calculus of computing a deadline is basically pointless.
If the “managers” don’t understand any of this, it’s never going to be peaceful unfortunately.
In Agile speak, that’s a 3 point spike ticket, for which the deliverable is a detailed set of requirements and deliverables with estimates with considered trade-offs. It’s a totally normal thing to do.
You can give an estimate before doing the spike, but maximally caveat it. Like “60% confidence it’ll take fewer than 3 weeks, 80% 5 weeks, 90% 6”.
I’d generally recommend refusing to give deadline estimates beyond a week or two (unless it’s absolutely necessary as it sometimes is), preferring piecemeal estimates (i.e. this project is composed of 7 deliverables each taking 1-2 days of work). Reason is that it might take 10 days of engineering work to do something, but due to shifting priorities etc., the calculus of computing a deadline is basically pointless.
If the “managers” don’t understand any of this, it’s never going to be peaceful unfortunately.
>Is there anything I could be doing better here?
Yes. Not give a fuck about the code debt and quality, and just rush out something that barely works. That will keep them satisfied.
Yes. Not give a fuck about the code debt and quality, and just rush out something that barely works. That will keep them satisfied.
Having built a few of these and inherited a few, please don't. They become brittle and future changes become increasingly difficult, until velocity grinds to a halt. Then you're just firefighting constantly.
My guess is there is a happy medium between never changing and staying on the cutting edge. A place where you can ride the current of tech, FOSS, dev communities and talent pools.
If course what this looks like day to day and in pointing poker will vary. Ideally there is a seasoned architect on every team who can steer the biggest decisions away from the hazards.
My guess is there is a happy medium between never changing and staying on the cutting edge. A place where you can ride the current of tech, FOSS, dev communities and talent pools.
If course what this looks like day to day and in pointing poker will vary. Ideally there is a seasoned architect on every team who can steer the biggest decisions away from the hazards.
The goal is to leave the company before this becomes your problem. ;)
I say this as the person who gets hired to fix things after they left.
I say this as the person who gets hired to fix things after they left.
Typical action movie hacking scene:
Leader: How long until you can hack the mainframe?
Techie: The other hacker is really good; at least 2 hours.
Leader: You have 1. Get it done!
[commence flying around the 3d filesystem]
[Techie thinks]: My actual estimate was 20 minutes. I can probably get it done in about 50, then I need to fly in the 3d filesystem for 10 more minutes looking busy so Leader doesn't get any big ideas.It's not quite true. Many features can be in a very bare bones way or in a fully gold plated way, and several shades in between.
Sometimes I see colleague developers estimate two weeks for a feature I consider one day at most, because they assume lots of extra functionality that wasn't actually asked for, or that I didn't realize would be necessary.
If you are asked to change your estimate, see it as an invitation to discuss the requirements and proposed implementation a bit more. Maybe something much simpler that brings you 90% of the way there is both possible and a acceptable. Meteorologists don't have that option.
Sometimes I see colleague developers estimate two weeks for a feature I consider one day at most, because they assume lots of extra functionality that wasn't actually asked for, or that I didn't realize would be necessary.
If you are asked to change your estimate, see it as an invitation to discuss the requirements and proposed implementation a bit more. Maybe something much simpler that brings you 90% of the way there is both possible and a acceptable. Meteorologists don't have that option.
Often clients don't understand what they want; like you say, the difference between met plonking in a basic combobox/select vs some much nicer, and much more fitting the case, custom ui element doesn't really translate to anything many people outside IT understand. To explain this difference it can be drawn, but stakeholders still don't understand what's going on as they don't see & feel it, so you have to make it work mostly.
I have clients asking 'just do the simplest thing you can do'; we present prototyped gui's then after approval fully designed guis and after that a prototype. They approve the first 2 immediately as they can't even be bothered looking at them; some, when pressed, will try the prototype and often still say 'yes great, let's go'. And then when it works and they can try it on the test server, they say 'no this is really not what we meant'. I have had this with 2 person mom and pop stores (long ago; I don't do those anymore luckily) to fortune 500 companies with the regional directors and global cto present to give their opinion. And this is frontend ... Backend, devops is another thing entirely, but there, is also a large difference between bare bones or gold plated.
I know the game by now, so these days we make a lot of money from this broken process.
I have clients asking 'just do the simplest thing you can do'; we present prototyped gui's then after approval fully designed guis and after that a prototype. They approve the first 2 immediately as they can't even be bothered looking at them; some, when pressed, will try the prototype and often still say 'yes great, let's go'. And then when it works and they can try it on the test server, they say 'no this is really not what we meant'. I have had this with 2 person mom and pop stores (long ago; I don't do those anymore luckily) to fortune 500 companies with the regional directors and global cto present to give their opinion. And this is frontend ... Backend, devops is another thing entirely, but there, is also a large difference between bare bones or gold plated.
I know the game by now, so these days we make a lot of money from this broken process.
The other extreme is that management was talking about new functionality and we kept seeing it as just another small feature in our existing product, and kept giving them estimates of a few weeks. Until they ended up setting up a whole new team for it because what they had in mind was a completely new product fully focused on that functionality.
It's all communication, programmers and stakeholders live in different worlds.
It's all communication, programmers and stakeholders live in different worlds.
1975: Fred Brook's wrote[1]:
“The bearing of a child takes nine months, no matter how many women are assigned.”
Can't get better than this
[1] https://en.wikipedia.org/wiki/The_Mythical_Man-Month
“The bearing of a child takes nine months, no matter how many women are assigned.”
Can't get better than this
[1] https://en.wikipedia.org/wiki/The_Mythical_Man-Month
I don't know, I've seen some 10x women do it in seven months, though the deliverable did suffer.
I have even smart managers look me in the eye and say things like "can we parallelize parts of this? let's map out the dependencies."
EVERY EXTRA PERSON YOU ADD MAKES IT TAKE LONGER. The fastest delivery is a solo developer that you get out of their f**ing way and let them work.
EVERY EXTRA PERSON YOU ADD MAKES IT TAKE LONGER. The fastest delivery is a solo developer that you get out of their f**ing way and let them work.
[deleted]
If you want to go fast, go alone.
If you want to go far, go with people.
If you want to go far, go with people.
But more and more women are working faster. Later preterm rates are on the rise for quite some time.
"The late preterm singleton rate rose at an average annual rate of 2% each year from 2014 to 2019 (from 5.67% to 6.32%). The decline in the late preterm rate between 2019 and 2020 (6.32% to 6.30%) was not significant."
https://www.cdc.gov/nchs/data/databriefs/db430.pdf
"The late preterm singleton rate rose at an average annual rate of 2% each year from 2014 to 2019 (from 5.67% to 6.32%). The decline in the late preterm rate between 2019 and 2020 (6.32% to 6.30%) was not significant."
https://www.cdc.gov/nchs/data/databriefs/db430.pdf
I love these types of posts. Most of my career as a developer felt like being in a bazaar, where the buyer (manager) would constantly be trying to get the price of a carpet down (my work) without ever knowing exactly what type of carpet they wanted, but having a vague idea of a "quality" carpet in their head.
Management has to push for lower estimates because developers have an incentive to overestimate to make life easier. The only situation where this isn't a problem is with eager junior devs, and devs that have direct skin in the game, such as at startups or a department about to be cut for being unprofitable.
> Management has to push for lower estimates because developers have an incentive to overestimate to make life easier.
Developers have to push for higher estimates because management has an incentive to underestimate to make life easier.
See what I did there? There's a fallacy in both statements: one side's actions are portrayed as greedy pursuit of "incentives" while the other side's actions are portrayed as a natural and logical counter to those incentives.
Developers have to push for higher estimates because management has an incentive to underestimate to make life easier.
See what I did there? There's a fallacy in both statements: one side's actions are portrayed as greedy pursuit of "incentives" while the other side's actions are portrayed as a natural and logical counter to those incentives.
You're reading too much into the morallity. Furthermore how is it a fallacy?
it's a fallacy in that it implies that one side is right and the other is wrong. (or one side is fair and the other is greedy)
My argument is not assigning blame, but explaining why the article will not convince many managers. It works assuming either side can be greedy or fair.
many projects everywere are failing their estimates. so the idea that developers overestimate the time it takes to complete a project is not supported by statistics.
Management has to push for lower estimates because developers have an incentive to overestimate to make life easier.
this statement as written clearly supports management and puts blame on developers. if that wasn't your intention then it could be expressed more neutrally:
management pushes for lower estimates, because they believe that developers intentionally overestimate, therefore this article will not convince them
my response to that would still be the same though. statistics don't support that developers overestimate. on the contrary, one might even be motivated to claim that projects failing their estimates is caused by these managers.
Management has to push for lower estimates because developers have an incentive to overestimate to make life easier.
this statement as written clearly supports management and puts blame on developers. if that wasn't your intention then it could be expressed more neutrally:
management pushes for lower estimates, because they believe that developers intentionally overestimate, therefore this article will not convince them
my response to that would still be the same though. statistics don't support that developers overestimate. on the contrary, one might even be motivated to claim that projects failing their estimates is caused by these managers.
> many projects everywere are failing their estimates. so the idea that developers overestimate the time it takes to complete a project is not supported by statistics.
Can you cite your own statistics? But even granting your assertion, it still would not matter because in the end the project will be done sooner the more pressure is put on, so it's better to underestimate and plan for delays than to over estimate. Managers often have two different deadlines for projects: the official deadline, and the real deadline. They simply don't tell their reports the real deadline. At many tech companies it's not unusual that a team will only make 70%-90% of their OKRs, and if they consistently make 100% they are said to be too conservative in their ambitions and encouraged to do more.
> this statement as written clearly supports management and puts blame on developers. if that wasn't your intention then it could be expressed more neutrally:
I believe my intention was clear from the other responses I got that understood what I was saying. But that's not just what management believes, I also believe that, so your version would not be a better expression of what I meant.
Can you cite your own statistics? But even granting your assertion, it still would not matter because in the end the project will be done sooner the more pressure is put on, so it's better to underestimate and plan for delays than to over estimate. Managers often have two different deadlines for projects: the official deadline, and the real deadline. They simply don't tell their reports the real deadline. At many tech companies it's not unusual that a team will only make 70%-90% of their OKRs, and if they consistently make 100% they are said to be too conservative in their ambitions and encouraged to do more.
> this statement as written clearly supports management and puts blame on developers. if that wasn't your intention then it could be expressed more neutrally:
I believe my intention was clear from the other responses I got that understood what I was saying. But that's not just what management believes, I also believe that, so your version would not be a better expression of what I meant.
a quick search on failing software projects suggest a 70% failure rate.
over budget (which i see as a proxy for taking longer than estimated) seem to be above 50%.
here is one source that appears to be neutral:
https://blog.gitnux.com/software-project-failure-statistics/
another that suggests one third of completed projects have cost or time overrun:
https://www.bcs.org/articles-opinion-and-research/a-study-in...
here is one source that appears to be neutral:
https://blog.gitnux.com/software-project-failure-statistics/
another that suggests one third of completed projects have cost or time overrun:
https://www.bcs.org/articles-opinion-and-research/a-study-in...
Also any estimate providedwill be pushed downwards, not to mention unforeseen curveballs, so there is an incentive to estimate higher to preserve your own sanity. Some don't learn to estimate higher until they get burnt.
Another common pitfall is to estimate each task in isolation, and the people receiving the estimates considering them timelines. Effort estimates and delivery timelines are wildly different beasts and great care has to be taken to avoid miscommunications.
Another common pitfall is to estimate each task in isolation, and the people receiving the estimates considering them timelines. Effort estimates and delivery timelines are wildly different beasts and great care has to be taken to avoid miscommunications.
Estimate high is the mathematically most valid thing to do in the face of uncertainty. This is more or less the fundamental theorem of finance. Expected rate of return increases with risk as compensation for the risk. Project planning should be following the same principle. If you're uncertain of traffic conditions, you leave earlier to be safe. If you're uncertain of future work unknowns, you estimate longer completion time to be safe.
If management is pushing for lower estimates, it's typically going some reason along the lines of:
- Someone higher up gave them a fixed budget or a fixed deadline and they can't exceed that.
- They're expecting market conditions to reward earlier delivery more than higher quality.
- They don't understand the problem domain.
- They do understand the problem domain but don't understand limiting factors like tech debt or organizational process hurdles the developers face that preven them from hitting timelines they would hit under ideal conditions.
If it's one of the latter two, they need to have a come to Jesus moment with themselves because you can't run a team if you don't understand what they do, how they do it, and what obstacles they face.
If it's one of the former two, great, communicate that, but then whoever is ultimately accepting or using your product needs to understand the basic release models that you can either get a complete set of well-defined features or you can get a specific release date but you can't get both, except by luck. And you need to have an organizational culture that isn't going to punish developers if they don't get lucky and meet only one of those goals.
Companies purchasing labor output don't get to violate the basic constraints of being a consumer. If you've got a fixed budget, fine, but you get what you pay for.
If management is pushing for lower estimates, it's typically going some reason along the lines of:
- Someone higher up gave them a fixed budget or a fixed deadline and they can't exceed that.
- They're expecting market conditions to reward earlier delivery more than higher quality.
- They don't understand the problem domain.
- They do understand the problem domain but don't understand limiting factors like tech debt or organizational process hurdles the developers face that preven them from hitting timelines they would hit under ideal conditions.
If it's one of the latter two, they need to have a come to Jesus moment with themselves because you can't run a team if you don't understand what they do, how they do it, and what obstacles they face.
If it's one of the former two, great, communicate that, but then whoever is ultimately accepting or using your product needs to understand the basic release models that you can either get a complete set of well-defined features or you can get a specific release date but you can't get both, except by luck. And you need to have an organizational culture that isn't going to punish developers if they don't get lucky and meet only one of those goals.
Companies purchasing labor output don't get to violate the basic constraints of being a consumer. If you've got a fixed budget, fine, but you get what you pay for.
>>Management has to push for lower estimates because developers have an incentive to overestimate to make life easier.
Bingo, having just left a mega-corp this is the status-quo of a lot of projects I had visibility into - take a trivial task, estimate it at 8-13 story points (i.e. the whole 2 week sprint), have nobody question the estimates, complete the story in 1-2 days and then chill for the other 8-9 days left in the sprint. It was pretty much an open secret.
...and nobody gets faulted by management, because they completed the story in the time they committed to.
On the other hand, if you had estimated the task at 3 days, and it ends up taking 5, you would get dinged for it. Estimate the same task at 13 story points, even if it was really only a 3, you were rewarded for meeting estimates - its a very perverse incentive structure.
Bingo, having just left a mega-corp this is the status-quo of a lot of projects I had visibility into - take a trivial task, estimate it at 8-13 story points (i.e. the whole 2 week sprint), have nobody question the estimates, complete the story in 1-2 days and then chill for the other 8-9 days left in the sprint. It was pretty much an open secret.
...and nobody gets faulted by management, because they completed the story in the time they committed to.
On the other hand, if you had estimated the task at 3 days, and it ends up taking 5, you would get dinged for it. Estimate the same task at 13 story points, even if it was really only a 3, you were rewarded for meeting estimates - its a very perverse incentive structure.
Predictability is arguably more important than speed, especially when you have a lot of moving parts.
When you have a developer that is slow, but constantly delivers on his estimates, you have a reliable IC that you can count on not failing to develop an API for some other team to integrate with.
Fast and ambitious guys, who frequently fall behind their own estimates, are a pain in the ass to manage in large teams/companies.
Sure, with startups on the bleeding edge and with RnD it's different, but most of devs aren't doing that
Sure, with startups on the bleeding edge and with RnD it's different, but most of devs aren't doing that
Fast and ambitious guys, who frequently fall behind their own estimates
I wasn't particularly fast, but I was this guy for a year. You're exactly right.
I wasn't particularly fast, but I was this guy for a year. You're exactly right.
Ye. If the estimates are accurate they will be overrun about 50% of the time. Punishing "late" tickets is what leads to the outcome of having to pad the estimates as much as possible.
How about getting rid of the "stories", "points" and "sprints" altogether? Not only is the nomenclature abhorrent, the best software projects don't use enterprise agile methodology.
In my view, it's fine if it's not treated a performance metric, for the individual devs.
I saw a lot of questionable tactics stem from this. It's like when you play capture the flag, and focus on the "KDR" metric, as is often done.
Critical people who were saving the teams life and working their fucking asses off would get grilled and questioned; not intentionally, but as a natural extension of these processes. Meanwhile, people that scored easy points would get a pat on the head, then sit silently during the sprint review; thankful that they got the easy path this sprint.
It got to the point of absurdity. I think it could make sense to look at sprint points during planning, but then the total bank of points goes to the team; who scored what should be anonymous... this was one of those ideas you have that you know you can never share, lol.
I saw a lot of questionable tactics stem from this. It's like when you play capture the flag, and focus on the "KDR" metric, as is often done.
Critical people who were saving the teams life and working their fucking asses off would get grilled and questioned; not intentionally, but as a natural extension of these processes. Meanwhile, people that scored easy points would get a pat on the head, then sit silently during the sprint review; thankful that they got the easy path this sprint.
It got to the point of absurdity. I think it could make sense to look at sprint points during planning, but then the total bank of points goes to the team; who scored what should be anonymous... this was one of those ideas you have that you know you can never share, lol.
I agree, but a lot of big companies are all in on Agile and you (as a developer) don't really get a lot of say on the matter.
Some high-paid consultants got paid a lot of money to sell it to the CEO, who then mandates it....so we are stuck with it ...until those same consultants have some other methodology-du-jour to sell.
Some high-paid consultants got paid a lot of money to sell it to the CEO, who then mandates it....so we are stuck with it ...until those same consultants have some other methodology-du-jour to sell.
Forcing every team in the company to use the same project management framework because consultants who never created great software claimed it's a panacea. Interesting decision.
[deleted]
You punish us for being ambitious and failing and give us nothing for being ambitious and succeeding.
As a developer, I endorse doing as little as possible as a result.
As a developer, I endorse doing as little as possible as a result.
This is a very childish way of viewing the situation. Of cousd you should look out for yourself, but your reward is not fixed, so you should not look to minimize your work at all costs
My reward is fixed as my salary is fixed.
For most people it isn't. Most jobs offer raises, promotion, and bonuses for high performers. Low performers get PIP, salary adjustments, and layoffs. If you work at a competitive place like Amazon or Microsoft, there isn't even a floor for performance because you'll be stack ranked. But hey maybe you work some of the few high pay / low effort jobs where it's impossible to get fired.
[deleted]
> developers have an incentive to overestimate to make life easier
Have you ever seen developers overestimate their tasks? On what kind of alternative dimension this happens?
Developers are always deluded optimists that can't get realistic estimates no matter how much they inflate it.
Have you ever seen developers overestimate their tasks? On what kind of alternative dimension this happens?
Developers are always deluded optimists that can't get realistic estimates no matter how much they inflate it.
The correct conversation is "what can we remove / what can I do / what can we re-prioritized / what else is in the way" to get some version of this ask earlier.
Simply bullying for a lower estimate, which is what I see 90% of the time is idiotic. Basically demanding to be negatively surprised later when the estimate slips rather than positive surprised when the dev is able to beat their initial estimate.
The first conversation requires empathy while the second conversation is a pure power flex. So it is unsurprising which we get more of.
Simply bullying for a lower estimate, which is what I see 90% of the time is idiotic. Basically demanding to be negatively surprised later when the estimate slips rather than positive surprised when the dev is able to beat their initial estimate.
The first conversation requires empathy while the second conversation is a pure power flex. So it is unsurprising which we get more of.
My estimate math:
R = t × [1.1^ln(n+p) + 1.3^X]
R - time it really takes.
t - shortest possible time it would take without need to communicate.
n - number of people working and involved during the process, both customers and developing organization.
p - longest communication distance network involved in the project (typically from the lowest level developer to the end user)
X - number of new tools, libraries, techniques, used in the process.
Example. Project involving one developing writing code. Project would take 2 weeks (t=2), but it has 5 people (n=5) involved total, only 1 new tool (X=1) and longest communication distance is 4.
2×(1.1^ln(5+4) + 1.3^1) = 4.5 weeks.
R = t × [1.1^ln(n+p) + 1.3^X]
R - time it really takes.
t - shortest possible time it would take without need to communicate.
n - number of people working and involved during the process, both customers and developing organization.
p - longest communication distance network involved in the project (typically from the lowest level developer to the end user)
X - number of new tools, libraries, techniques, used in the process.
Example. Project involving one developing writing code. Project would take 2 weeks (t=2), but it has 5 people (n=5) involved total, only 1 new tool (X=1) and longest communication distance is 4.
2×(1.1^ln(5+4) + 1.3^1) = 4.5 weeks.
Out of curiosity, how did you came out with this formula? What’s the math behind it?
It’s from his butt. Which makes it just as valid as how everyone else does estimates.
It's a bullshit formula that can be used to justify "padding" to people that think software development (or any kind of work) is like digging a ditch or like an assembly line.
In real world projects you don't actually know "t", nor do you know how "p" and "n" are conditioned by other factors, nor is there any basis (IMHO) in reality to that "1.3" factor in front of "number of new <whatever's> being used."
It's a pity that in so many orgs people can't just be adults, trust each other, and recognize that work often takes unexpected turns.
In real world projects you don't actually know "t", nor do you know how "p" and "n" are conditioned by other factors, nor is there any basis (IMHO) in reality to that "1.3" factor in front of "number of new <whatever's> being used."
It's a pity that in so many orgs people can't just be adults, trust each other, and recognize that work often takes unexpected turns.
Crude estimate based on some self evident truths:
Logarithms for number of people and communication chain come from network theory because network size and network distances slow down information flow.
New technologies bring in unexpected delays and problems that rapidly accumulate in nonlinear ways. If bring in 20 people to work with new programming language, new library stack, etc. everything slows down to crawl.
Logarithms for number of people and communication chain come from network theory because network size and network distances slow down information flow.
New technologies bring in unexpected delays and problems that rapidly accumulate in nonlinear ways. If bring in 20 people to work with new programming language, new library stack, etc. everything slows down to crawl.
From the other angle, you can see how velocity is impacted by using "boring tech", keeping teams small (two pizza team), clearly identifying stakeholder roles, creating efficient communication channels. It's a pretty useful model.
Why does zero new tools (X) add time?
Alternatively, why does one new tool add so little time?
Alternatively, why does one new tool add so little time?
[deleted]
>X - number of new tools, libraries, techniques, used in the process
How would you know this before starting dev work?
How would you know this before starting dev work?
new to the team, I suppose. Everyone on the team has shipped a rails heroku PG app? Then you have a low number of shinies.
Shipping a Vaticle + Haskell on nixOS in your own server farm?
Maybe that's more new tools for the team...
Shipping a Vaticle + Haskell on nixOS in your own server farm?
Maybe that's more new tools for the team...
Did anyone ever get asked to simply make the estimate lower? Without any other context? That never happened to me, it sounds extremely immature.
Feedback that you don’t agree with the estimate on the other hand, happens all the time. This is a completely different thing than a hollow request for “lower plx”.
Good stakeholders often do have a good idea of how long time things take. Maybe they worked as dev before, or with other clients. Leaving the estimation exclusively for the well oiled hero-team with perfectly calibrated velocity and ponies coming out of their retrospectives, as the article portrays it, isn’t always ideal either. Some tasks are new and unknown to them too, and honestly not all teams are that perfect. There needs to be a two-way dialogue about scope contra timing.
Feedback that you don’t agree with the estimate on the other hand, happens all the time. This is a completely different thing than a hollow request for “lower plx”.
Good stakeholders often do have a good idea of how long time things take. Maybe they worked as dev before, or with other clients. Leaving the estimation exclusively for the well oiled hero-team with perfectly calibrated velocity and ponies coming out of their retrospectives, as the article portrays it, isn’t always ideal either. Some tasks are new and unknown to them too, and honestly not all teams are that perfect. There needs to be a two-way dialogue about scope contra timing.
Oh yeah. Sales sets the ship date, which is 'set in stone' because of a trade show. PM makes a schedule that makes the ship date. PM shows the schedule to engineering and is told it's not possible. PM tells management what engineering said, and management tells the PM to make it work, we need to give sales what they need. Oh, and you can't add more engineering resources, the project isn't that important. PM tells engineering to 'make the schedule work' and we add time to some tasks, but then necessarily take time from other tasks. Then engineering starts the death march, with everyone dreading the inevitable escalation of complaints about the project being late. Start slipping schedule? Let's have a bunch of meetings to rearrange the schedule so we can pretend for a week that we're not behind and let the PM feel good when he gives the weekly update to management.
Of course there's blame on the engineering side of the table too. We chronically underestimate effort, not adding enough margin for unknown-unknowns. So we start working late. Sandbagging estimates. Telling the PM whatever he wants to hear just to end the meeting and get back to work.
Impossible schedules are toxic for people that care, and encourage apathy as a coping mechanism. If you put in a Herculean effort and ship on time you did what you said you were going to do, what, do you think you deserve a cookie or something? The other option is failure. Even if the PM or management isn't upset, engineers still feel the failure of not hitting a goal.
Engineers need to feel wins. Always shipping late because of impossible schedules means no project is a win, no matter how good the design is.
At a former job I found out after a couple years that impossible schedules was a business strategy by the c-level execs. It encourages engineers to work as 'efficiently' (i.e. as much) as possible. God forbid we clock out early because we're not stressed out about being behind. Learning that made me shift from caring to apathy. I left shortly after, but I wish I had stayed a bit longer, it might've been nice to have a job that I didn't care about so I could focus on other areas of my life.
Of course there's blame on the engineering side of the table too. We chronically underestimate effort, not adding enough margin for unknown-unknowns. So we start working late. Sandbagging estimates. Telling the PM whatever he wants to hear just to end the meeting and get back to work.
Impossible schedules are toxic for people that care, and encourage apathy as a coping mechanism. If you put in a Herculean effort and ship on time you did what you said you were going to do, what, do you think you deserve a cookie or something? The other option is failure. Even if the PM or management isn't upset, engineers still feel the failure of not hitting a goal.
Engineers need to feel wins. Always shipping late because of impossible schedules means no project is a win, no matter how good the design is.
At a former job I found out after a couple years that impossible schedules was a business strategy by the c-level execs. It encourages engineers to work as 'efficiently' (i.e. as much) as possible. God forbid we clock out early because we're not stressed out about being behind. Learning that made me shift from caring to apathy. I left shortly after, but I wish I had stayed a bit longer, it might've been nice to have a job that I didn't care about so I could focus on other areas of my life.
TLDR - Yes, but from a crazy person.
Yes, in the most toxic place I ever worked. Gee, those are probably related, huh? The owner of the company was crazy. Not in a hyperbolic "oh yeah she's nuts" way but in a "she's either taken too much medication or not enough because she's unstable." Some of my favorite anecdotes, starting with one relevant to your comment:
1. After I provided an estimate of N weeks for a project, her response was "no it needs to be done faster than that." Okay, what features do you want to remove? What can be added after launch? "Everything is critically important and has to be available at launch, I thought it would take a day or two not weeks!" Finally she just wrote something about 80% of my original estimate and moved on. It took a week or two longer than I had originally estimated and it was fine.
2. Insisted on charging $10 instead of $9.99 because "the taxes get too complicated." Turns out rather than just using billing software like any sane person ca. 2010, she was using a calculator on her desk to figure out what clients owed and just typing that into an invoice and sending it. I bet 90% of our clients either overpaid or underpaid basically every bill by 1 cent due to her rounding in her head.
3. My favorite one ever was she was out on vacation one week, and while she was out we had some production issue over the course of a day and a half or so that was eventually resolved but she was cc'd on everything as she insisted. She pops into my office her first day back at like 8AM and says "I saw $THING wasn't working last week, everything's good now?" Yup. "Okay thanks!" and left. Comes in a few more times asking about $THING over the next hour, kind of weird but not unusual. Runs into my office frantic right before lunch "John Doe just emailed me, $THING is down!" Turns out she was just reading her Outlook top to bottom, so was gradually reading earlier and earlier emails. So in her mind $THING was totally fine and gradually slid into chaos as she read older and older emails.
That was an exciting few years, I have to say.
Yes, in the most toxic place I ever worked. Gee, those are probably related, huh? The owner of the company was crazy. Not in a hyperbolic "oh yeah she's nuts" way but in a "she's either taken too much medication or not enough because she's unstable." Some of my favorite anecdotes, starting with one relevant to your comment:
1. After I provided an estimate of N weeks for a project, her response was "no it needs to be done faster than that." Okay, what features do you want to remove? What can be added after launch? "Everything is critically important and has to be available at launch, I thought it would take a day or two not weeks!" Finally she just wrote something about 80% of my original estimate and moved on. It took a week or two longer than I had originally estimated and it was fine.
2. Insisted on charging $10 instead of $9.99 because "the taxes get too complicated." Turns out rather than just using billing software like any sane person ca. 2010, she was using a calculator on her desk to figure out what clients owed and just typing that into an invoice and sending it. I bet 90% of our clients either overpaid or underpaid basically every bill by 1 cent due to her rounding in her head.
3. My favorite one ever was she was out on vacation one week, and while she was out we had some production issue over the course of a day and a half or so that was eventually resolved but she was cc'd on everything as she insisted. She pops into my office her first day back at like 8AM and says "I saw $THING wasn't working last week, everything's good now?" Yup. "Okay thanks!" and left. Comes in a few more times asking about $THING over the next hour, kind of weird but not unusual. Runs into my office frantic right before lunch "John Doe just emailed me, $THING is down!" Turns out she was just reading her Outlook top to bottom, so was gradually reading earlier and earlier emails. So in her mind $THING was totally fine and gradually slid into chaos as she read older and older emails.
That was an exciting few years, I have to say.
I link with the article, I usually call predictions a forecast, and not estimates, because you don't get angry at a meteorologist.
I have produced estimates for almost 20y now, and boy do I hate that. There's multiple layers to it.
This post touches the nefarious one. Sometimes yes, someone wishes something would come sooner and will shake the tree to see what happens. Sometimes there's actually a reason for it - be it budget, customer related, event related, etc. Sometimes someone knows better, because the feature or project is similar to another that was shorter.
When someone discusses estimates with an underlying motive other than their experience and surprise at the cost, I usually enter a discussion where I produce the evidence for our numbers and justify what we are telling.
It highly depends on why we produce estimates in the first place. If it's for budget or planning, I couldn't care less to reduce estimate, since these exercises are pointless in nature in my experience (the budget or planning is usually rendered moot within weeks of being approved).
If its to predict delivery dates, I'm usually very conservative, note that I am not in the art of divination, and that reducing estimates is a risk in itself if anything bad happens. When people are acting on bad faith, documenting stuff usually tames things a little. Unless things are very simple and predictable, I also usually provide several dates with confidence indices. This is a framework that's much harder to negotiate, and give some information to whomever "needs" those dates. It helps reducing the pressure a bit while being non committal and leaving room for error (and I never give a 100% confidence).
TBH, I don't think I've ever been in trouble for "being late", especially because I have always been able to explain that we weren't late, we just gave an incorrect date in the first place.
I have produced estimates for almost 20y now, and boy do I hate that. There's multiple layers to it.
This post touches the nefarious one. Sometimes yes, someone wishes something would come sooner and will shake the tree to see what happens. Sometimes there's actually a reason for it - be it budget, customer related, event related, etc. Sometimes someone knows better, because the feature or project is similar to another that was shorter.
When someone discusses estimates with an underlying motive other than their experience and surprise at the cost, I usually enter a discussion where I produce the evidence for our numbers and justify what we are telling.
It highly depends on why we produce estimates in the first place. If it's for budget or planning, I couldn't care less to reduce estimate, since these exercises are pointless in nature in my experience (the budget or planning is usually rendered moot within weeks of being approved).
If its to predict delivery dates, I'm usually very conservative, note that I am not in the art of divination, and that reducing estimates is a risk in itself if anything bad happens. When people are acting on bad faith, documenting stuff usually tames things a little. Unless things are very simple and predictable, I also usually provide several dates with confidence indices. This is a framework that's much harder to negotiate, and give some information to whomever "needs" those dates. It helps reducing the pressure a bit while being non committal and leaving room for error (and I never give a 100% confidence).
TBH, I don't think I've ever been in trouble for "being late", especially because I have always been able to explain that we weren't late, we just gave an incorrect date in the first place.
I'm sometimes a bit ashamed of the IT sector as a whole. I have been programming professionally for more than 20 years, but I have not seen much improvement in time to delivery. For each step forward, we seem to be taking two steps back. I can't blame the developers, but I wonder who to blame instead.
The first suspect is: the internet. It may seem like a great invention, but having machines connected at all times, without formal restrictions, results in terrible security problems. Which have to be fixed. Which takes enormous amounts of time.
The second one is related to that, and that is the idea that we have to continuously upgrade everything to the latest fad. As one consequence, we are somehow stuck with a weird common ground for user interfaces defined by web browsers, which leads to overly complex software.
What most people often want is just a push button to send a message to some other system. Both companies and governments alike seem to be paying billions of dollars for that. Because it is all so extremely complex, and people are somehow buying that.
My understanding is that the industry is happy making a lot of money, so there could be limited incentive to change things for the better. However, for some other odd reason, most ordinary people try to avoid technology like the plague, and pride themselves in not understanding how computers work, yet unknowingly spend a big percentage of their tax money on exactly that lack of understanding.
I am still extremely thankful for the likes of Richard Stallman for starting the free software movement. Unfortunately, delivering software is only one (small) part of the problem. Embedding computers in human processes is a whole different ballgame. Can we perhaps have some kind of "free management foundation" as well?
I actually reread the above rant, and I fear for the downvotes, but perhaps someone understands what I am on about and has a good tip to ease my mind.
The first suspect is: the internet. It may seem like a great invention, but having machines connected at all times, without formal restrictions, results in terrible security problems. Which have to be fixed. Which takes enormous amounts of time.
The second one is related to that, and that is the idea that we have to continuously upgrade everything to the latest fad. As one consequence, we are somehow stuck with a weird common ground for user interfaces defined by web browsers, which leads to overly complex software.
What most people often want is just a push button to send a message to some other system. Both companies and governments alike seem to be paying billions of dollars for that. Because it is all so extremely complex, and people are somehow buying that.
My understanding is that the industry is happy making a lot of money, so there could be limited incentive to change things for the better. However, for some other odd reason, most ordinary people try to avoid technology like the plague, and pride themselves in not understanding how computers work, yet unknowingly spend a big percentage of their tax money on exactly that lack of understanding.
I am still extremely thankful for the likes of Richard Stallman for starting the free software movement. Unfortunately, delivering software is only one (small) part of the problem. Embedding computers in human processes is a whole different ballgame. Can we perhaps have some kind of "free management foundation" as well?
I actually reread the above rant, and I fear for the downvotes, but perhaps someone understands what I am on about and has a good tip to ease my mind.
> but I have not seen much improvement in time to delivery.
Is this true, by the way, or it’s just our hedonistic treadmill?
Nowadays it’s extra fast to deliver and serve a lot of functionalities worldwide. Thing that would require a dev team are handled by a free saas out of the box.
But our implied non-functional requirements have grown exponentially. Twenty years ago, if a business critical software was offline for one day a month, it wasn’t a big issue. Today, if Facebook is offline for an hour it’ll make headlines on major newspapers.
Expectations just evolved. And writing working software over multiple layers of mess is as difficult as ever. “Precise estimation” is just a misnomer.
Is this true, by the way, or it’s just our hedonistic treadmill?
Nowadays it’s extra fast to deliver and serve a lot of functionalities worldwide. Thing that would require a dev team are handled by a free saas out of the box.
But our implied non-functional requirements have grown exponentially. Twenty years ago, if a business critical software was offline for one day a month, it wasn’t a big issue. Today, if Facebook is offline for an hour it’ll make headlines on major newspapers.
Expectations just evolved. And writing working software over multiple layers of mess is as difficult as ever. “Precise estimation” is just a misnomer.
And the expectation that every business should act like they are facebook.
No, if your system goes off line for 20 hours a year barely anyone will notice, it will have way, way less impact to your business than spending the money to make sure that doesn't happen.
No, if your system goes off line for 20 hours a year barely anyone will notice, it will have way, way less impact to your business than spending the money to make sure that doesn't happen.
Honestly, the complexity of most systems I've worked on those last 15 years has only grown. Everything require umpteen libraries to show a char on screen (and be inefficient at that). We're still blocked in the 80's for a lot of protocols because of backward compatibility with a ton of hack on top of it. We have built tool on top of other tool to manage the mess we've created, that no one understand at the end.
That's where we're losing time. Dealing with an inherited mess.
That's where we're losing time. Dealing with an inherited mess.
This article is extremely weak, pandering to engineers beset by clueless pointy-hair antics, without acknowledging that engineers can suffer from their own blind spots, regardless of whether stakeholders have the technical background to understand it or not.
The elephant in the room is this: a team can not produce good work without both competence and trust in equal measure. An immature engineer may assume a business stakeholder is dumb because they don't understand or engage on technical details, an immature business stakeholder may assume that pressure and threats can yield quality work. In both cases, the immature individuals are putting their energy into counter-productive hand-wringing.
But now here's where it gets hard: trust can't be blind and incompetence exists. The straw man analogy that content of estimates are somehow immutable and unavoidable facts like the weather demonstrates an incredible lack of agency and resourcefulness. We are talking about humans working together to solve problems and build things, we have incredible latitude on how we want to approach things. This viewpoint reeks of learned helplessness. Look at the proposed solutions:
> In these cases, discuss with your stakeholders: why the estimated effort is this much? what part of the story takes the most time? where are the biggest unknowns? In addition, discuss ways to: slice up the story and deliver it in multiple parts, validate each part early, preferably using prototypes
Do you see the assumed constraint? There is no discussion of the problem to be solved or job to be done. Often in these cases you have a non-technical person prescribing a solution that doesn't make sense. If that's the case, it can only be solved by an engineer who has communication skills and credibility to discuss a better approach to the problem. Assuming that a user story passed down to the team is somehow sacrosanct is the type of process-oriented dysfunction that tanks morale and leads to impotent teams.
The elephant in the room is this: a team can not produce good work without both competence and trust in equal measure. An immature engineer may assume a business stakeholder is dumb because they don't understand or engage on technical details, an immature business stakeholder may assume that pressure and threats can yield quality work. In both cases, the immature individuals are putting their energy into counter-productive hand-wringing.
But now here's where it gets hard: trust can't be blind and incompetence exists. The straw man analogy that content of estimates are somehow immutable and unavoidable facts like the weather demonstrates an incredible lack of agency and resourcefulness. We are talking about humans working together to solve problems and build things, we have incredible latitude on how we want to approach things. This viewpoint reeks of learned helplessness. Look at the proposed solutions:
> In these cases, discuss with your stakeholders: why the estimated effort is this much? what part of the story takes the most time? where are the biggest unknowns? In addition, discuss ways to: slice up the story and deliver it in multiple parts, validate each part early, preferably using prototypes
Do you see the assumed constraint? There is no discussion of the problem to be solved or job to be done. Often in these cases you have a non-technical person prescribing a solution that doesn't make sense. If that's the case, it can only be solved by an engineer who has communication skills and credibility to discuss a better approach to the problem. Assuming that a user story passed down to the team is somehow sacrosanct is the type of process-oriented dysfunction that tanks morale and leads to impotent teams.
Oh my god thank you. Software engineering seems to be the only field where it seems like these types of super weird arguments about being too special or unique to follow or apply any business process are common, coupled with a vibe of "we are way smarter than everyone else".
Why are these people surprised that other stakeholders won't just accept a "trust me bro, it's ready when it's ready you just have to go with it" when nothing else works like that in the business world.
Why are these people surprised that other stakeholders won't just accept a "trust me bro, it's ready when it's ready you just have to go with it" when nothing else works like that in the business world.
If developers did not approach projects with the goal of adding
acronyms to their resumes and infuse every project with the
latest cargo cult du jour it would improve the ability to
predict timelines.
Pick boring technology, that the team is already comfortable with, when possible. Keep the teams as similar as possible, Keep running projects the same way, when possible
I am not saying it will get things perfect, but it will be an improvement.
Pick boring technology, that the team is already comfortable with, when possible. Keep the teams as similar as possible, Keep running projects the same way, when possible
I am not saying it will get things perfect, but it will be an improvement.
Developers do not choose the tools. Not in agile/scrum companies. Heck, they are not even allowed to choose the variable names by themselves.
What? That seems like it would vary from company to company. My company does scrum and developers choose which technologies to use, which seems like it's probably common...
The problem is that developers have a very strong incentive to add new technology to their resume, as their job is not guaranteed. I think most junior devs have seen some old hat at their first real job who codes in one, ancient tech stack; someone that they perceive as un-hirable if the economy takes a turn.
We all see the job listings out there and the tech they desire. It is self-preservation, and it is in direct conflict with what is best for the company itself. To use myself as an example: I have zero regrets with pushing for JavaScript over VBScript many years back, for moving from Microsoft HTA to React, or for moving from Yahoo's YUI to jQuery. Being infused with old tech can very severely limit your ability to survive. Most of my interviews after my first job were simply explaining/defending the ancient tech I had specialized in. It is all risk, no reward at the employee level.
We all see the job listings out there and the tech they desire. It is self-preservation, and it is in direct conflict with what is best for the company itself. To use myself as an example: I have zero regrets with pushing for JavaScript over VBScript many years back, for moving from Microsoft HTA to React, or for moving from Yahoo's YUI to jQuery. Being infused with old tech can very severely limit your ability to survive. Most of my interviews after my first job were simply explaining/defending the ancient tech I had specialized in. It is all risk, no reward at the employee level.
I think that it might even be worse than asking a meteorologist for sunshine. Because asking a meteorologist for sunshine has no conceivable influence on the weather, but putting a thumb on the estimation process can absolutely alter the design of the system. And that, in turn, can alter the overall effort and delivery date.
Whether the influence is positive or negative seems to depend a lot on the details of how you do it. I think, though, that the Extreme Programming community was on to something when they suggested that demanding more meticulous up-front technical design invites overengineering and ultimately makes things take longer. Unfortunately, that's often what happens when managers directly push back on estimates.
I would advocate for something more like a feedback cycle: at the end of every milestone or iteration, the team should compare how long work actually took to their estimates, and discuss the factors that may (or may not!) have contributed to any severe under- or overestimate. That process should improve the quality of estimates over time, and help the team to get better at focusing on the important factors in producing a quality estimate. And it will improve trust, too - I've noticed that it's common for teams that don't do something like this to bicker over estimates rather than collaborating on them.
And then, with all that established, it finally becomes possible for the team to reliably focus attention on the only way to actually reduce development costs without cutting corners: scope management and negotiation.
Whether the influence is positive or negative seems to depend a lot on the details of how you do it. I think, though, that the Extreme Programming community was on to something when they suggested that demanding more meticulous up-front technical design invites overengineering and ultimately makes things take longer. Unfortunately, that's often what happens when managers directly push back on estimates.
I would advocate for something more like a feedback cycle: at the end of every milestone or iteration, the team should compare how long work actually took to their estimates, and discuss the factors that may (or may not!) have contributed to any severe under- or overestimate. That process should improve the quality of estimates over time, and help the team to get better at focusing on the important factors in producing a quality estimate. And it will improve trust, too - I've noticed that it's common for teams that don't do something like this to bicker over estimates rather than collaborating on them.
And then, with all that established, it finally becomes possible for the team to reliably focus attention on the only way to actually reduce development costs without cutting corners: scope management and negotiation.
I'm glad the article gets to talking and haggling with stakeholders. Trying to estimate with different understandings of where complexity lies between stakeholders, product managers, and devs is the biggest source of frustration in my experience.
Lol, long ago I was working with a junior PM who heard what was difficult and what was easy from devs and started to design features around that intuition to make work faster. Too smart for his own good though. Often the proposed features would be more complicated in trying to be easy. Much to his chagrin, our ticket estimation sessions often turned to "wait, what are we trying to do here again?" But often, one week of work turned into a day or two.
The world is complicated and I think a sizable minority of workplaces defy stereotypes.
One hard driving "VP of Operations" type I worked with would push for aggressive estimates, but alongside that suggested every corner that could be cut without hampering the business. In a bizarre way, he was far more agile/MVP/product-validation focused than almost all of the technical staff.
I've seen fast but sloppy developers drive stakeholders crazy. One situation I was in, we needed to culturally back off from way over-spec'ed tickets. The engineers had been focused on closing tickets and "shipping" as fast as possible. If a detail wasn't in the ticket, it wasn't happening, so tickets got bloated and rigid. The rest of the business was ok with slowing down if it meant reliable features, the engineering leadership was the most hesitant.
Lol, long ago I was working with a junior PM who heard what was difficult and what was easy from devs and started to design features around that intuition to make work faster. Too smart for his own good though. Often the proposed features would be more complicated in trying to be easy. Much to his chagrin, our ticket estimation sessions often turned to "wait, what are we trying to do here again?" But often, one week of work turned into a day or two.
The world is complicated and I think a sizable minority of workplaces defy stereotypes.
One hard driving "VP of Operations" type I worked with would push for aggressive estimates, but alongside that suggested every corner that could be cut without hampering the business. In a bizarre way, he was far more agile/MVP/product-validation focused than almost all of the technical staff.
I've seen fast but sloppy developers drive stakeholders crazy. One situation I was in, we needed to culturally back off from way over-spec'ed tickets. The engineers had been focused on closing tickets and "shipping" as fast as possible. If a detail wasn't in the ticket, it wasn't happening, so tickets got bloated and rigid. The rest of the business was ok with slowing down if it meant reliable features, the engineering leadership was the most hesitant.
I dislike the framing here, it disempowers the team and sets up a hostile lens towards stakeholders.
As the product team, you are in general optimizing between quality, scope, and timeline. Pick values for two, the other one will be determined. So if a stakeholder communicates a timeline constraint, you can work with them to achieve it by cutting quality or scope. For example if the urgency is that they need to give a customer demo, maybe a moving skeleton prototype, or at least delivering an iteration without all the integration tests would be appropriate (quality). Or maybe you can chop the deliverable into two milestones and ship the features they urgently need sooner (scope).
I acknowledge that in some cases there is just an asshole who doesn’t know what they are talking about, trying to inject urgency. But in many cases, if you actually empathize with the stakeholder and try to figure out what they are really communicating, you can find the underlying issue and modify your deliverables accordingly. This is what it looks like to be a high-performing team.
The idea that the timeline is out of your control is asinine, and will make stakeholders distrustful, since the idea is obviously nonsense (or if it’s true, the team is adrift). I strongly advise you to never use this language or philosophy in your stakeholder interactions.
As the product team, you are in general optimizing between quality, scope, and timeline. Pick values for two, the other one will be determined. So if a stakeholder communicates a timeline constraint, you can work with them to achieve it by cutting quality or scope. For example if the urgency is that they need to give a customer demo, maybe a moving skeleton prototype, or at least delivering an iteration without all the integration tests would be appropriate (quality). Or maybe you can chop the deliverable into two milestones and ship the features they urgently need sooner (scope).
I acknowledge that in some cases there is just an asshole who doesn’t know what they are talking about, trying to inject urgency. But in many cases, if you actually empathize with the stakeholder and try to figure out what they are really communicating, you can find the underlying issue and modify your deliverables accordingly. This is what it looks like to be a high-performing team.
The idea that the timeline is out of your control is asinine, and will make stakeholders distrustful, since the idea is obviously nonsense (or if it’s true, the team is adrift). I strongly advise you to never use this language or philosophy in your stakeholder interactions.
Completely agree, the article reads more like someone who thinks they are doing research rather than development. There's no esoteric perfect form for software that needs to be discovered, there's a set of patterns and structures that can be learned before the project starts.
Analogies are often unhelpful because people argue about the analogies instead of the actual problem at hand. If you can't communicate why these things are hard, and why 'do it faster' won't always get results, you need to get better at dev management.
Analogies are often unhelpful because people argue about the analogies instead of the actual problem at hand. If you can't communicate why these things are hard, and why 'do it faster' won't always get results, you need to get better at dev management.
Except the meteorologist has no inherent incentive to predict a specific outcome. A dev who will need to deliver against the resulting target deadline has a powerful incentive to overstate. Even more so if they think they’ll subsequently be pushed to revise downwards
Rubbish metaphor
Rubbish metaphor
The problem is not with estimates themselves, but on giving point estimates. A better way of saying something will take 2 weeks, is that there's a 80% chance this takes less than weeks, 15% chance it takes 2-4 weeks and 5% chance 4+. But people have a hard time wrestling with uncertainty so they'd rather a point estimate that's wrong but makes them feel like they understand the situation
Pushing estimates is silly. If you have another estimate than your developer you have every right to have it and make decisions based on it. But the reality of how much it will actually take is the future. It is unknown and will probably worse than both your estimate and the one of your developer you don't agree with.
Why are you pushing software engineers for "estimates"? You don't ask mathematicians how long that conjecture will take to prove. It's done when it's done.
Because developing software is almost always an economic activity, and proving maths conjectures almost always isn't.
While thats true, business leaders still need to realize developing software is not the same sort of economic activity as running a horseshoe press or something. Machine can’t just be ran faster. You can’t also just plug another machine in the wall and expect it to know exactly what to do and double your output. Roadblocks often emerge that cannot be foreseen at all short of taking even more time to speculate on these potential blocks down the road.
Certain jobs do have these estimates better managed. For example, tunnel construction often hits unknown things underground that delays the project substantially in time and money. However this is par for the course with tunnel construction and such delays are even expected at this point.
Certain jobs do have these estimates better managed. For example, tunnel construction often hits unknown things underground that delays the project substantially in time and money. However this is par for the course with tunnel construction and such delays are even expected at this point.
There is no evidence that you get better economic outcomes from micromanaging software engineers, and not for the lack of trying.
> There is no evidence that you get better economic outcomes from micromanaging software engineers, and not for the lack of trying.
Thats not really the point that my reply was addressing. Software production almost always takes place within a wider context of economic activity: product launch activities need to be scheduled, server capacity needs to be provisioned, hardware needs to be produced and assembled, people need to be paid out of budgets, etc. I'm a dev and I hate being micromanaged, but usually people really do need to know when the code will be done.
Not so much for mathematicians proving conjectures. Which is nice for them. I guess.
Thats not really the point that my reply was addressing. Software production almost always takes place within a wider context of economic activity: product launch activities need to be scheduled, server capacity needs to be provisioned, hardware needs to be produced and assembled, people need to be paid out of budgets, etc. I'm a dev and I hate being micromanaged, but usually people really do need to know when the code will be done.
Not so much for mathematicians proving conjectures. Which is nice for them. I guess.
That's yearly planning. If estimation means giving your best effort to complete a project over the next year then that's not a problem. When you start micromanaging on a biweekly basis with daily status updates then it becomes a real problem.
I'm sorry, I can't imagine any business anywhere that would allow all software project estimates to have a precision of "about a year".
We might prefer that our projects be given unlimited leeway, but we still have to fit within businesses and their ability to forecast what they can sell, when the next round of bugs will be patched, and even how many developers should be hired.
Estimated is hard, leadership often fails to understand how hard it is, and it should always be accepted with a bunch of caveats, but it _is_ a very useful tool.
We might prefer that our projects be given unlimited leeway, but we still have to fit within businesses and their ability to forecast what they can sell, when the next round of bugs will be patched, and even how many developers should be hired.
Estimated is hard, leadership often fails to understand how hard it is, and it should always be accepted with a bunch of caveats, but it _is_ a very useful tool.
How long does it take to fix a Linux kernel bug? Anywhere from a day to 20 years to never. It's either done as soon as possible, or it's done when it's done and that works for the best software projects.
Estimating is not hard, it's snake oil. That's how you end up paying $100M for burndown charts and a government website that doesn't work.
Estimating is not hard, it's snake oil. That's how you end up paying $100M for burndown charts and a government website that doesn't work.
So all custom software should be written with a blank check and an unlimited timeframe?
You're either arguing for something that can not work in commerce or you're not arguing in good faith; I'm not sure which.
You're either arguing for something that can not work in commerce or you're not arguing in good faith; I'm not sure which.
You write the check once a year and plan projects no shorter than three months.
Estimates help planning. The problem is that they often travel through a company and become immovable deadlines.
Planning too often is also a problem. You should not do it more often than every three to six months.
Hello waterfall my old friend. How have you been doing?
But seriously.. there's levels to planning. There's strategic planning which is less often and then implementation of delivery stages which is more on going. It is helpful to know if something will be delivered in 2 weeks or 2 months. The problem is when the dev team says 2 weeks but discovers more and knows it will be 6 weeks but the deadline is firmly set to the initial 2 week estimate.
But seriously.. there's levels to planning. There's strategic planning which is less often and then implementation of delivery stages which is more on going. It is helpful to know if something will be delivered in 2 weeks or 2 months. The problem is when the dev team says 2 weeks but discovers more and knows it will be 6 weeks but the deadline is firmly set to the initial 2 week estimate.
Probably because software engineers are not mathematicians. Also, you're not doing foundational research or breaking away at the edge of human knowledge either. Similarly, mathematicians are not immune to deadlines either.
Software engineers are not assembly line laborers developing x cogs per hour either. There is no evidence that micromanaging software projects works.
Tenured mathematicians are immune to deadlines, and non-tenured ones don't "story point" conjectures. Your PI does not usually make you submit daily status reports. Targeting a submission date three to six months ahead and trying again if it doesn't work out is a framework that would work in software engineering too.
Tenured mathematicians are immune to deadlines, and non-tenured ones don't "story point" conjectures. Your PI does not usually make you submit daily status reports. Targeting a submission date three to six months ahead and trying again if it doesn't work out is a framework that would work in software engineering too.
Pushing estimated is wrong but solutions exists in a spread of quality, completeness and efficiency, you can definitely find a balance where the time to release is shorter, if you are prepared to give up something else
Often the issue is that programmer are unaware of the exact quality and sophistication expectations and estimate the perfect solution with the most efficient algorithmic complexity whether it makes sense or not for the business scale and the other constraints at hand.
Then management ask shorter deadlines, programmers find different solutions that may or may not be appropriate, and it gives the illusory appearance that managing is working, while the underneath visibility/communication issue remains unaddressed while creating potential technical debt.
Often the issue is that programmer are unaware of the exact quality and sophistication expectations and estimate the perfect solution with the most efficient algorithmic complexity whether it makes sense or not for the business scale and the other constraints at hand.
Then management ask shorter deadlines, programmers find different solutions that may or may not be appropriate, and it gives the illusory appearance that managing is working, while the underneath visibility/communication issue remains unaddressed while creating potential technical debt.
The following point has stuck with me for half a year now.
> What they actually want is "the earliest date you cannot currently prove to be infeasible"
https://news.ycombinator.com/item?id=35318124
> What they actually want is "the earliest date you cannot currently prove to be infeasible"
https://news.ycombinator.com/item?id=35318124
That echoes the book Waltzing With Bears, if I'm remembering it right.
[deleted]
I disagree. Engineers have a habit of over engineering. Businesses have a habit of introducing too much process, too many meetings, too many layers between the end user and the engineer building.
A lot can be done most of the time to help devs optimize to deliver quickly. However, most businesses get stuck in their ways, struggle to give sufficient autonomy, and... sometimes get burned by giving too much to a dev when they aren't yet ready for it.
In short, getting efficiency "right" is a balancing act, and each "story" could be unique which makes it difficult to balance well consistently.
In my experience, don't get too caught up with estimates. Devs do need goals (even artificial ones) to help focus effort and prevent too much "bad" distraction (sometimes distraction is exactly what they need though--stepping away from the problem for some amount of time can help them look at it differently).
Give estimates. Motivate with goals. Build a real team environment where delivering is contagious. Its actually much harder to do than say, and I'd guess many devs have never experienced this before.
A lot can be done most of the time to help devs optimize to deliver quickly. However, most businesses get stuck in their ways, struggle to give sufficient autonomy, and... sometimes get burned by giving too much to a dev when they aren't yet ready for it.
In short, getting efficiency "right" is a balancing act, and each "story" could be unique which makes it difficult to balance well consistently.
In my experience, don't get too caught up with estimates. Devs do need goals (even artificial ones) to help focus effort and prevent too much "bad" distraction (sometimes distraction is exactly what they need though--stepping away from the problem for some amount of time can help them look at it differently).
Give estimates. Motivate with goals. Build a real team environment where delivering is contagious. Its actually much harder to do than say, and I'd guess many devs have never experienced this before.
> Engineers have a habit of over engineering
Developers have one. It's in most academic definition of engineering that the job is to produce the cheapest design that will do the job safely.
Devs also have a habit of underestimating, which puts them under pressure once the date has came and gone.
Developers have one. It's in most academic definition of engineering that the job is to produce the cheapest design that will do the job safely.
Devs also have a habit of underestimating, which puts them under pressure once the date has came and gone.
Engineers have been burnt by too many ex-engineer PM's who haven't coded in 20 years, but push back against estimates by claiming "I could've implemented this in Perl in 2 hours. How can it be 2 weeks!?!"
So it depends on who's saying "no, it's less effort than that".
Often I come to my engineers and say "No, it's less effort than that" because I know "You've never done this before, and you're buffering for the unknown. But actually one part of this can be reused from <module> and you can get this other part from <existing service>". I share the context, the engineers go "oh cool", and update the estimate.
And just as often I come to my managers (people and product) and say the opposite - "No, it's more effort than that" because I know what other things the devs are working on that are not visible to the PMs, what scaling cliff they're stopping us from going over, or that the PM's t-shirt size is not including automation, testing, infrastructure, scaling, etc.
So it depends on who's saying "no, it's less effort than that".
Often I come to my engineers and say "No, it's less effort than that" because I know "You've never done this before, and you're buffering for the unknown. But actually one part of this can be reused from <module> and you can get this other part from <existing service>". I share the context, the engineers go "oh cool", and update the estimate.
And just as often I come to my managers (people and product) and say the opposite - "No, it's more effort than that" because I know what other things the devs are working on that are not visible to the PMs, what scaling cliff they're stopping us from going over, or that the PM's t-shirt size is not including automation, testing, infrastructure, scaling, etc.
This metaphor is wrong: meteorologists don't have any impact on the sunshine, whereas devs have direct impact on estimates.
In both cases, wrong estimates will generate problems for the stakeholders, but devs can make choices during the implementation that will influence the outcome and may in some ways mitigate the lower estimates, but meteorologists won't ever have any influence on the weather.
In both cases, wrong estimates will generate problems for the stakeholders, but devs can make choices during the implementation that will influence the outcome and may in some ways mitigate the lower estimates, but meteorologists won't ever have any influence on the weather.
Pushing for lower estimates is generally a sign of dysfunctional project manager.
This is when the PM does not have practical knowledge of existing obstacles to the project flow or the implications of external dependencies (intra team included).
This is a set up for throwing the team under the bus in case the schedule derails.
PM is supposed to harmonize the objectives and abilities, not manufacture the curves.
This is when the PM does not have practical knowledge of existing obstacles to the project flow or the implications of external dependencies (intra team included).
This is a set up for throwing the team under the bus in case the schedule derails.
PM is supposed to harmonize the objectives and abilities, not manufacture the curves.
Unlike the meteorologist, the developer has the ability to bend reality a bit when it comes to estimates, but they can never bend reality in a way which makes it worthwhile. Cutting corners is almost always a mistake. It's a very short term move which may only make sense if the business is collapsing and looking for a quick exit.
You could spend 15 years cutting every corner imaginable as a self-professed genius 1-man engineering team until everything becomes unsustainable, feature work is impossible due to frequent fires, the business is faltering, and you can't even understand your own code any longer. Then, quit as soon as a new hire comes in so you can't be held accountable for your quagmire by other engineers. I don't really understand why someone would do this, but I recently got to see it first hand. ;)
Damn 15 years is a long time. I think the oldest ball of unmaintainable spaghetti code I saw was 3 years old and it was almost impossible to add or change anything. None of the developers who worked on it and had the most knowledge of it could explain how it worked, not even at a high level. Like they barely understood it better than non-tech end users.
If you ask for a lower estimate it means that you are providing an estimate. Why people that are not qualified to estimate, scum masters, team leads, product owners, provide estimates? The whole management structure is upside-down and then we wonder why software is crap and people quit.
More like a clueless "leader" demanding an earlier sunrise.
If he's going to want an earlier sunrise, he's going to need to shave off a good portion of the still-dark Earth that's standing in the way and he's going to need to get it done before dawn.
The team can do their part after that.
If he's going to want an earlier sunrise, he's going to need to shave off a good portion of the still-dark Earth that's standing in the way and he's going to need to get it done before dawn.
The team can do their part after that.
I wish we could somehow get away from estimates where the expectation is precision and instead talk about a spectrum of possibilities (i.e., best case, worst case, and points in between). As the journey to the destination gets longer and more complex the range of possibilities increases. Why do we continue to pretend otherwise?
That aside, more accurate running scoring (if you will) would also help. Engineering is asked for an estimate but engineering knows that they don't have absolute complete control end to end of everything. Someone else somewhere along the line is going to cause delays, but the estimate stays fixed and engineering remains accountable. That's not helpful in the short term or long.
That aside, more accurate running scoring (if you will) would also help. Engineering is asked for an estimate but engineering knows that they don't have absolute complete control end to end of everything. Someone else somewhere along the line is going to cause delays, but the estimate stays fixed and engineering remains accountable. That's not helpful in the short term or long.
This isn’t going to be a popular take, but this is just wrong.
Developers will often plan out a cathedral when what’s needed is a garage. Usually this is due to a misunderstanding of the requirements, or an inability of the requestor to formulate or express them. Also, developers are notoriously bad at forecasting work product and the numbers they deliver usually have a tenuous link to reality.
The conversation that starts with “We don’t have 6 months, how do we deliver this by 12/31?” is ultimately a hashing out of what the requirements are. When it’s a cool tech driven story, we call it “an MVP”. When it’s driven by the business, the author considers it yelling at the weatherman.
Developers will often plan out a cathedral when what’s needed is a garage. Usually this is due to a misunderstanding of the requirements, or an inability of the requestor to formulate or express them. Also, developers are notoriously bad at forecasting work product and the numbers they deliver usually have a tenuous link to reality.
The conversation that starts with “We don’t have 6 months, how do we deliver this by 12/31?” is ultimately a hashing out of what the requirements are. When it’s a cool tech driven story, we call it “an MVP”. When it’s driven by the business, the author considers it yelling at the weatherman.
My favorite bit of this argument is the presumption of honesty, accuracy, or transparency on the part of developers. Someone in the estimation process is always protecting themselves, packing on a little margin, or fudging the numbers. It's nothing to get upset about, it's just normal human behavior, happens in all industries.
For this reason alone, I always kick estimates back down and amazingly they almost always come back better-optimized – usually because some trusted graybeard engineer, who has been on both 'sides' of the business, steps in and cleans it up based on his experience.
For this reason alone, I always kick estimates back down and amazingly they almost always come back better-optimized – usually because some trusted graybeard engineer, who has been on both 'sides' of the business, steps in and cleans it up based on his experience.
> Next time, when someone starts a conversation about your team's estimate, pushing for a lower estimate without any new insights that will lower the effort, ask them: do you ever tell the meteorologist it isn't going to be this bad weather tomorrow?
I'm more direct. I ask them why. As in "why do you think it's less work / time / effort?". Every single time they've realised it's not less, they just _want_ it to be less.
I'm more direct. I ask them why. As in "why do you think it's less work / time / effort?". Every single time they've realised it's not less, they just _want_ it to be less.
Estimates aren't deadlines. If we're talking estimates then we should also talk about accuracy and precision.
I can give a low estimate if you're ok understanding that it's not a deadline and that is has astonishing low accuracy.
Estimates indicate that there's a probability that the time required could be more OR less. Choosing the deadline to be exactly the same as the estimate is ignoring the probability that the the task will take longer.
I can give a low estimate if you're ok understanding that it's not a deadline and that is has astonishing low accuracy.
Estimates indicate that there's a probability that the time required could be more OR less. Choosing the deadline to be exactly the same as the estimate is ignoring the probability that the the task will take longer.
Dev teams have choices though. They can choose to use existing 3rd party code, services, etc, to accelerate development or not. They can choose some amount of non-functional requirements. They can choose the amount of "future proofing", abstraction, etc. And on and on...many choices that would drive timelines, trade speed for quality, longevity, maintainability, or cost, and so on.
But unless that 3rd party code, and those services, have already been discovered, evaluated, and learned by that particular dev team, integrating them might take more time than building something from scratch that meets the specific requirements at hand.
And if it's built in-house, that means that in addition to being much more tailored to the organization's needs, it can be much more easily changed as those needs evolve.
This doesn't mean that I think it's always better to roll your own, of course; there are lots of instances where that counts as "reinventing the wheel." But it's absolutely not as simple as "just use something that's already out there and it will be faster and work just as well."
And if it's built in-house, that means that in addition to being much more tailored to the organization's needs, it can be much more easily changed as those needs evolve.
This doesn't mean that I think it's always better to roll your own, of course; there are lots of instances where that counts as "reinventing the wheel." But it's absolutely not as simple as "just use something that's already out there and it will be faster and work just as well."
I wasn't suggesting that example was a magic bullet. Just that it is one of many choices that drive an estimate...down OR up. I agree there are cases where 3rd party software doesn't help. I think it would be pretty rare for a team to have zero choices in their control that would change an estimate.
Quite often using third party tools take longer time but still are worth it in the long term due yo lower maintaisnce and generally simpler tech stack.
Sorry to be a stickler but this is a heavy editorialization of the title.
The original title is "Someone saying 'No, it's less effort than that!'?".
The current HN title isn't even a proper quote of the article, the quote is
> Pushing for a lower estimate is like negotiating better weather with the meteorologist!
The original title is "Someone saying 'No, it's less effort than that!'?".
The current HN title isn't even a proper quote of the article, the quote is
> Pushing for a lower estimate is like negotiating better weather with the meteorologist!
I don't get the meteorologist analogy: The meteorologist does not create the weather. The software development team does create the software.
Also weather is (somewhat) possible to predict. In software, the unknown unknowns are a problem, so all estimates are basically bullshit.
Also weather is (somewhat) possible to predict. In software, the unknown unknowns are a problem, so all estimates are basically bullshit.
Estimates are just that - estimates.
More importantly they’re estimates of effort - not of time. If you estimate in time you’re tracking time over time and as such not your ability to estimate time.
Estimating within the team should be for the team, not for the business (directly).
More importantly they’re estimates of effort - not of time. If you estimate in time you’re tracking time over time and as such not your ability to estimate time.
Estimating within the team should be for the team, not for the business (directly).
Sometimes. Or the estimator is fixated on an extent of scope/depth that is not intended by the stakeholders at the initial stage. Or sometimes the estimator is baking in extra time that will get filled whether or not it’s necessary.
My manager once gave me a succinct method for accurately estimating project times:
1. List all the necessary tasks
2. Estimate the time for each task
3. Add up all the times
4. Multiply by π
If using unknown technology, that last step should be "multiple by π^2".
1. List all the necessary tasks
2. Estimate the time for each task
3. Add up all the times
4. Multiply by π
If using unknown technology, that last step should be "multiple by π^2".
This is a bad metaphor. You can't make the sun come out faster by dropping features.
yeah i cannot use this analogy to tell my client to backoff.
they will say: if you guys are only watching the weather and telling me whether it will rain or not -- I dont need you guys then. I will hire someone else - who will build me a working umbrella within my budget before it starts to rain.
or some other imperfect analogy that we cannot question having done the same thing ourselves first
they will say: if you guys are only watching the weather and telling me whether it will rain or not -- I dont need you guys then. I will hire someone else - who will build me a working umbrella within my budget before it starts to rain.
or some other imperfect analogy that we cannot question having done the same thing ourselves first
What you can do is release a product faster with less features and continue working on adding the missing features after the initial release.
This happens all the time in embedded systems which can be updated by the customer.
This happens all the time in embedded systems which can be updated by the customer.
So happy to work without estimates for decades.
We just work on our tasks until they're done.
We just work on our tasks until they're done.
[deleted]
[deleted]
If you're asking for estimates from devs at all you're probably pushing waterfall on them.
If you want to be waterfall, that's fine. If you're forced into doing it by your business context, that's also fine. But, you shouldn't be under any illusions about what you're doing. It's a waterfall behavior that will drive waterfall effects.
If you want to be waterfall, that's fine. If you're forced into doing it by your business context, that's also fine. But, you shouldn't be under any illusions about what you're doing. It's a waterfall behavior that will drive waterfall effects.
That's just not true. It _can_ be waterfall, but story points are everywhere in agile development.
Story points are for relative sizing are not estimates. That's why you use story points and not hours or days. They're for re-arranging the priority of stories and deciding which ones to do or not.
> relative sizing are not estimates.
Relative sizing is still an estimate.
> They're for re-arranging the priority of stories and deciding which ones to do or not.
Hard disagree - that's what priority is for. Story points are an _estimate_ for how much we can do in a period.
Relative sizing is still an estimate.
> They're for re-arranging the priority of stories and deciding which ones to do or not.
Hard disagree - that's what priority is for. Story points are an _estimate_ for how much we can do in a period.
>Relative sizing is still an estimate.
Not one which would attract any pressure.
Not one which would attract any pressure.
If you're doing Scrum, then you might have noticed that the Scrum Guide considers the contents of a sprint to be a "commitment" on the part of the team. That "commitment" is usually built by taking the number of story points delivered last sprint, and bin-packing the same number of story points from the backlog into the next sprint.
If you don't think toxic managers and scrum masters are going to use that "commitment" to death-march the team if it looks like the sprint goal is going to be missed then you have a far more optimistic view of humanity than I do.
If you don't think toxic managers and scrum masters are going to use that "commitment" to death-march the team if it looks like the sprint goal is going to be missed then you have a far more optimistic view of humanity than I do.
> If you don't think toxic managers and scrum masters
If your managers and PM's are toxic you've already lost and no process is going to fix it. The only move is to change your team in that case. If everywhere you look you only see toxic managers though, maybe you're the problem.
If your managers and PM's are toxic you've already lost and no process is going to fix it. The only move is to change your team in that case. If everywhere you look you only see toxic managers though, maybe you're the problem.
The non-technical managers and agile coaches are the problem. That's why the best software projects don't have them. Linux kernel developers don't run story ticket velocity poker sprints.
An obsession with technical knowledge being superior to everything else is one of the most grating things about this community.
> The non-technical managers and agile coaches are the problem.
No, shitty managers are. In fact, most of the utterly useless managers and leaders I've had have been technical who just assumed that management, soft skills and leadership are "easy".
> That's why the best software projects don't have them.
There's no one definition of "best" software projects. And something being good software doesn't mean it serves a products needs.
> Linux kernel developers don't run story ticket velocity poker sprints.
The Linux kernel works because the project management knows their audience. The project is managed differently and ran differently. If I drop into an email thread talking about a large feature and say "I think that will take 2 days" people will disagree with that. That's all planning poker really is - once you've decided to do something, have a gut check on how much work it is.
> The non-technical managers and agile coaches are the problem.
No, shitty managers are. In fact, most of the utterly useless managers and leaders I've had have been technical who just assumed that management, soft skills and leadership are "easy".
> That's why the best software projects don't have them.
There's no one definition of "best" software projects. And something being good software doesn't mean it serves a products needs.
> Linux kernel developers don't run story ticket velocity poker sprints.
The Linux kernel works because the project management knows their audience. The project is managed differently and ran differently. If I drop into an email thread talking about a large feature and say "I think that will take 2 days" people will disagree with that. That's all planning poker really is - once you've decided to do something, have a gut check on how much work it is.
Technical knowledge should be a necessary but not sufficient condition to become an engineering manager. A layman can't take a two day course with no exam and become a managing partner at a law firm. Why is that sufficient to become a micromanager in an enterprise software project?
Scrum is designed to protect the team from toxic management. That's why it exists. It's built into the operating assumptions.
> If everywhere you look you only see toxic managers though, maybe you're the problem.
Charming.
> If everywhere you look you only see toxic managers though, maybe you're the problem.
Charming.
Using scrum to extract commitments on a sprint is also just waterfall by another name.
Sometimes Scrum does get called "lots of very short waterfalls". It's not entirely wrong, in the current incarnation. [On edit, I see you've made this point below. Yes.]
Note that until relatively recently (2020, I think), the Scrum Guide referred not to "commitments" but to "forecasts". That was a much better framing, and I don't know why they changed it.
Note that until relatively recently (2020, I think), the Scrum Guide referred not to "commitments" but to "forecasts". That was a much better framing, and I don't know why they changed it.
Waterfall is not the same as having a plan and commiting to delivering part of it
That's exactly waterfall - make a plan up front, commit to it and focus exclusively on delivery.
Scrum does that because it considers waterfall on a 2 week cycle to be training wheels for people who have been doing it on 6 month increments and because it considers that "closer" to agile.
Scrum does that because it considers waterfall on a 2 week cycle to be training wheels for people who have been doing it on 6 month increments and because it considers that "closer" to agile.
Hmmm it doesn’t seem unreasonable in that context? You’re really asking people to work more effectively, to accomplish the same amount of work more quickly.
It’s like asking sales people what their quota should be. They pick a number that is no-brainer hittable, because there is a lot of complexity and many unknown variables in getting deals signed, so to prevent looking bad they’ll pad their number. But their no-brainer number is below what the business needs.
So you tell them their quota is going to be a bit higher. They’ll have to stretch to hit it.
And it’s even MORE important since their comp is DIRECTLY tied to hitting that number.
And yet sales people aren’t writing article after article about how self-set quotas are sacrosanct, should only settable by sales people themselves, and how clueless management is to try to get more performance above the no-brainer target.