"No, it's less effort than that"
smartguess.is
smartguess.is
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.
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 write 10 more lines, code for 10 for minutes, etc.
Or my personal favorite, bugs fixed!
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.
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.
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.
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.
And a phone call doesn't mean a sale closes.
See conversation upthread.
Every time the probability is non null. Small, but not zero.
Law of big numbers always help scammers. And mediocre sales.
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.)
It’s fun to think you’re special and easy to do when you’re paid a shitload of money.
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.
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.
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.
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".
There's plenty of decisions devs make that impact how quickly they deliver a solution.
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.
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.
This is actually a pretty common motivation for devs who work under legacy management.
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.
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.
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.
P.S. Not really, you covered it nicely under fraud
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
Legacy management steeped in manufacturing has entered the chat!
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.
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.
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.
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.
https://www.justice.gov/opa/pr/wells-fargo-agrees-pay-3-bill...
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.
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?
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.
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.
Sure, if you’re a contract dev shop who is marking up hours, then longer is better.
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.
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.
That's why it's called tech debt, it accrues interest.
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.
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?
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.
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
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?
It's not whatever you mentioned here.
No amount of effort on either your or my part is going to make the baby appear faster.
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.
> 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?
…
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?
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.
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.
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?
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.
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”
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.
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.
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.
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.
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.
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.
I have already made my millions by working with sane ipo companies. At this point, I would much rather take advice from folks who prefer a good management structure. Please continue with your TC grind. Thanks for the offer though!
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.
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.
You don’t own 100% of your time when participating in group activities.
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.
This is business 101 stuff.
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.
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.
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.
On the whole, yes. You get what you incentivise.
> Cringeworthy naïveté.
Yeah that's exactly what dishonest people tend to call it when they're called out.
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.
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.
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.
That's awesome. In my feistier days I would have used that at work!
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.
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.
It definitely needs to be a 2-way bridge, and when both sides can and do come together, great things can happen!
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.
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.
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.
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
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.
While I agree with your sentiment, high quality software (and: what is high quality, anyway?) is not necessary the goal of an enterprise.
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.
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.
What do you mean by "unintuitive ways of working"?
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.
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.
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).
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.
Regular approaches, avoiding firefighting are essential to steady, stable states.
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...
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...
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.
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.
Even things that don’t blow up on those have so many hidden costs people don’t think about.
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!
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.
The real genius is to propose a simplified solution, by discarding some assumptions. This is the best and only way to shrink the schedule
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’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’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 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
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.
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.
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.
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)
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 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.
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).
> 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.
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 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.
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).
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.
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.
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.
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.
To this day I still don't know how this event came to pass.
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?
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.
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?"
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.
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.
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.
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'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!
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?
Yes. Not give a fuck about the code debt and quality, and just rush out something that barely works. That will keep them satisfied.
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.
I say this as the person who gets hired to fix things after they left.
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.
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.
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?"
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.
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.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.
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.
It's all communication, programmers and stakeholders live in different worlds.
“The bearing of a child takes nine months, no matter how many women are assigned.”
Can't get better than this
"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."
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.
If you want to go far, go with people.
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.
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.
Sure, with startups on the bleeding edge and with RnD it's different, but most of devs aren't doing that
I wasn't particularly fast, but I was this guy for a year. You're exactly right.
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.
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.
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.
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.
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.
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...
As a developer, I endorse doing as little as possible as a result.
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.
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.
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.
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.
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.
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.
How would you know this before starting dev work?
Shipping a Vaticle + Haskell on nixOS in your own server farm?
Maybe that's more new tools for the team...
Alternatively, why does one new tool add so little time?
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.
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.
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.
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.
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.
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.
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.
That's where we're losing time. Dealing with an inherited mess.
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.
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.
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.
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.
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.
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.
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.
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.
Rubbish metaphor
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.
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.
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.
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.
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.
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.
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.
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.
"Your estimate, your problem"
> What they actually want is "the earliest date you cannot currently prove to be infeasible"
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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."
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!
Also weather is (somewhat) possible to predict. In software, the unknown unknowns are a problem, so all estimates are basically bullshit.
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).
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".
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
This happens all the time in embedded systems which can be updated by the customer.
We just work on our tasks until they're done.
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.
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.
Not one which would attract any pressure.
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.
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.
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.
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.
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.
> If everywhere you look you only see toxic managers though, maybe you're the problem.
Charming.