I fixed giving “napkin” or “rough estimate” times out. I roll a D6 for number of people, D12 for number of months, D20 for the day we will go to production ( not allowed to do installation during end of month). D% is used to say how accurate the estimate is. With the requester there, I pull them out, roll them, give the estimate.
I did have a VP in a meeting go “I don’t like that estimate.” I pushed the dice over and said “Ok, you roll”. Their hand got about 1/2 way before their brain caught on to what was happening and they pulled their hand back.
We normally agree on them writing a 2-3 page scope and I do an estimate based off the scope. Slow learners ask, How long to get the estimate, I look them dead in the eye and reach for the dice again saying “I’d like to see the scope beforehand but ....”
>The Dice Man is a 1971 novel by American novelist George Cockcroft, writing under the pen name "Luke Rhinehart".[1] The book tells the story of a psychiatrist who makes daily decisions based on the casting of a die.[2] Cockcroft describes the origin of the title idea variously in interviews, once recalling a college "quirk" he and friends used to decide "what they were going to do that night" based on a die-roll, or sometimes to decide between mildly mischievous pranks.
>The newest thing here is a flock of self-proclaimed “coin boys” who carry a quarter on hand at all times and constantly flip it. They have their entire personality revolve around coins, coin flips, and chance. When we went around doing an ice breaker, 4 or 5 of the kids said some variation of “I live by the coin and die by the coin” as their fact.
>Just about an hour ago, when I assigned the first assignment of the school year, one of the coin boys was bold enough to say “heads I do it, tails I don’t.” I told him if he flipped the coin he would be getting a call home on the first week of HS. He flipped it anyway and it came up heads (thank god for that at least).
>But then the other coin boy in that class flipped his coin and it came up tails. He said the coin has spoken and he’s not doing it. I say very well, enjoy your 0 and your call home— what a great way to start off the school year and your high school career.
When I'm told "I don't like that estimate" I take it as an invitation to negotiate (same as when you don't like a quote from a tradesman) and so counter with "OK, we may be able to shave x off of it if you give us y and z in addition to what we have now or if we cut w out of the scope".
And then a year later I’m the only one who can remember that the reason we are in the middle of a grotesque rewrite is that we got a promise from management that we could treat all X as Y and they didn’t keep their word because that was last year and this is now.
Why can’t you idiots figure out how to code?
I have told a few people that when we substituted their judgment for mine this became their problem. I really think I should have said it more often.
All of these are familiar, unfortunately. Just one nitpick:
> Proper estimations take time.
IME there's no such thing as "proper" estimations. They're all a wild guess with little basis in reality. Scrum came along to make us pretend that relative estimates ("story points") are somehow more accurate, but they're the same illusion.
Software development is inherently chaotic. Every task is different from another, and developers can only get a sense of the time and effort requirements once they start working on something. And these are constantly changing during development. It might take a long time to discover that a bug can be fixed by a single line change, or a chain of bugs might be discovered that need separate investigation, or a bug might not exist at all, etc. Every case is different. Additionally, every engineer is different, and they're different from themselves every time. Tasks that require mental effort are unpredictable by definition.
Estimates are useful to managers and executives to pretend they're in some type of control, but they're otherwise useless. They only serve to demotivate development teams when they're not met. I wish the industry would move on from them and adopt the more sensible approach of "it's done when it's done". Unfortunately, this doesn't gel with the rest of the business which functions on deadlines, so here we are.
As a dev who has now gone into management, I fully feel the frustration that you feel about estimate. I was on the "estimates are stupid and pointless" train for a decade and I've made the same arguments you've made here to my managers countless times over the years.
Being on the other side of it now though, I really take issue with sentences like "Estimates are useful to managers and executives to pretend they're in some type of control, but they're otherwise useless". In the places I've worked as a manager, with the managers, directors, and VPs I've worked with, I've never gotten the impression from anyone that it's about control. It's about resource and risk management as well as ROI.
Developer time is a limited and incredibly expensive resource at most companies and managers need to make sure it's used in the most impactful way that it can be. A project may make sense to do if it's going to take a month, but it may not make sense to do if it's going to take a year. Without some sort of estimate on the time a project will take, you can't properly prioritize work. There are absolutely projects where it's just like, we need to get this done no matter how long it takes, but most projects aren't like that.
Again, I totally get your frustrations, but the thing I always tell my teams is let's say you wanted to build a house from scratch. You call a contractor and tell them everything you want done and then ask for an estimate and they tell you, "I don't know. It'll cost what it costs. Every project is different and I won't know until I'm done."
I doubt you would hire them, right?
You need more information than that to be able to truly make a decision because at a certain dollar value it's just not worth it anymore. You don't need an exact dollar amount, but knowing whether it's going to cost $100k or $500k will completely change the value proposition.
Again, I totally feel where you're coming from with pushing back on estimates, but I don't think you're ever going to get away from them. With that in mind, one of the things I've started asking my teams to do where they're really pushing back on estimating is to take a day and think on it and then come back and give me two numbers. Give me an estimate that you're 90% sure is too high and a second estimate that you're 90% sure is too low. I've feel like that takes some of the pressure off because there's no exact number that they can be held to and it gives me enough info to make a decision.
> You call a contractor and tell them everything you want done and then ask for an estimate and they tell you, "I don't know. It'll cost what it costs. Every project is different and I won't know until I'm done."
I see you haven't needed to hire many building contractors. "I won't know until I'm done" wasn't how the engagements started, but it's how they all ended up. When the budget's gone and they're only halfway done what are you gonna do, live with a hole in the wall and no running water? If you got a home renovation done on time or on budget (I refuse to believe both), congrats on catching a unicorn.
Your analogy falls flat, because building software is not the same as building a house. In fact, unusual construction projects with unknown dependencies and shifting requirements are just as unplannable as software development, and are just as liable to go over budget.
Don’t ever start that bullshit conversation with people. You’ve now signaled that they can’t trust you and now any “information” they give you will now be untrustworthy because you’re untrustworthy and turnabout is fair play.
If you’re trying to control ROI and manpower, you tell us what date ranges work for the org and we figure out what we can fit in that time. And if you don’t get any nice to haves in that initial estimate you might as well pull the plug now because everyone knows that scope will have to be shed to hit the date. And that we try to pretend anything different is happening is part of that illusion of control thing GP mentioned. If we can’t build a thing by whenever then it’s time to rethink the project. A different approach, possibly involving buying part of the solution instead of building the whole thing. Or we do some other project first that will teach us how to do this project better.
Why not then be honest about what kind of estimate is being made? How about saying "Can you give me ballpark estimates? On the order of days, weeks, months, years?" Then everyone knows it is a rough estimate and no one is forced to make impossible promises and trying to do the dumb "what I think multiply by 3" or whatever stuff goes on. Framed as ballpark or "rough" there's a clearer sense of shared ambiguity
I feel like this is the crux of the issue. Dev estimates should be taken with large error bars, and I think the entire problem is caused by people who take them at face value, making developers not want to give estimates at all next time.
Well, it helps if you have retrospectives, though I see them rarely done properly.
What kind of works is tracking similar efforts (in the same code base) and measuring how long they take. While every task is different, there are usually a small number of different classes of tasks, and knowing how quickly these can be done helps in both estimating as well as defending the estimates.
I understand and sympathize with the managerial PoV as well. :) It doesn't make the exercise of estimates any less pointless, though.
> I've never gotten the impression from anyone that it's about control. It's about resource and risk management as well as ROI.
Don't get me wrong. I didn't mean "control" in the sense that they want power over the project. It's more that they want to feel that these processes make the project more predictable than it would be without them. This is what I argue is a fallacy.
Whatever estimates they get back from the dev team, and whatever extrapolated metrics like "velocity" they think help them get a feel for the team's productivity, is ultimately pointless. The problem is that these metrics are relied upon, when they're really no more reliable than not tracking them.
Your house example is how management wants to visualize software development, but it's just not an accurate analogy, and never will be. Software development is nothing like "real" engineering, despite what developers like to call themselves. When building a house or any real-world object, you can rely on physics to make time estimates. You know how long concrete takes to set; you know how long a machine takes to cut wood beams; you could even know how long it takes for a builder to lay bricks. You can then extrapolate this to the building requirements, and more-or-less give an informed estimate, where only unpredictable circumstances like weather or human-related issues could delay the project.
Whereas software development depends entirely on humans (for now, at least; AI is not reliable yet), and there's no predictable physical component to it. Every project is entirely different from every other. This is not like building a house, where most houses have something in common. This is like inventing an entirely new way to build a house, from entirely different components, every time. The problems you run into each time are wildly different. Even when using the same programming languages, frameworks and APIs, the interaction between all of these changes every time you put them together.
But I'm sure you know all this. I'm just saying that the exercise of estimates is pointless, and the value they bring to the company is an illusion.
First reaction: Has this person been my coworker? I feel like someone’s been taking notes on places I’ve worked.
Second: But OK, those ones about shifting priorities? That’s startup life. Sometimes you throw something out the door because a customer wants to pay you $12M if you can salve over that one pain point. You know darn well that hack’s going to be there until The Rewrite (which, if you’re lucky, will never come). It’s ugly, you’re ashamed to have your name on the git blame, but your stock options went up 8% the moment you deployed to prod. The customer rarely pays you to be an artisan. They just want that feature before they write the check.
I’m still highly sympathetic to the sense of pride and ownership we all want to feel over our work. That’s the best! But getting paid’s pretty cool, too. Get a hobby project you can polish into a masterpiece after work.
> OK, those ones about shifting priorities? That’s startup life.
I've seen it at pretty much all scales. I think it's usually worse in bigger corps actually. Great point though - it behoves us to remember where the money for our technical airs and graces comes from.
I have worked at places that prioritized the wrong customer and ended up with a product that was tuned to work only for the ones who won’t pay more than what we originally offered the product for. Even inflation adjusted I’m sure it was less than $12M. You have to watch what your costs per year end up being for that check you got three years ago. The VCs will notice when they look at your books.
If you're following the bullshit that is SAFe/"Agile" at a startup, you're going to fail.
Capital-A Agile is project management for dummies that won't learn about things like GANTT charts, what "slack" means in links between dependent tasks, what a "critical path" is or how to analyze it, let alone things like S-curves and earned value.
The Gantt is a lie to get the project approved and then beg forgiveness later.
Nobody ever figures bus numbers into the chart, because it would make the timelines so much worse that management wouldn’t approve it. But the blame for going over the estimates rolls downhill. Those stupid devs can’t get anything done on time.
Thankfully I haven’t had to look at one of those stupid things in about 20 years. They used to make me see red.
A really good senior engineer knows how to deliver a "quick hack" that is as well-documented and extensible as possible to avoid the most contagious tech debt. There is a big difference between "hack in production" and "suboptimal, incremental solution in production".
It's very easy to see the PMs etc. as the enemy, but they would have their own list of unfair gripes about engineers (e.g. as evidenced by this article, they seem to just want to be solitary geniuses left alone to work on things they aren't communicating about).
The only correct estimation is actually doing the work and looking at how long it took.
The closest to that is half-assing the task at hand and multiplying the time it took by ten. For prototype to actual application, you multiply it by a hundred. This also applies for the prototypes of the prototypes (100x for the actual prototype, then 100x of that for the proper implementation), and yes, those exist, but they are usually named "concepts".
For bugs: Half the amount of time needed for the feature that caused that bug. They need a workaround? It will actually take longer - except when the workaround is already available and just needs to be applied. Then it's 90% of the proper solution.
> The only correct estimation is actually doing the work and looking at how long it took.
You seem to be missing the point of 'estimation' (as in, it is an approximate prediction, not an accurate measure). Admittedly management also tends to miss this same point, and that fact puts a lot of us on the defensive - but the answer can't be to throw estimation out entirely.
If you ask a civil engineer to estimate the cost and timeline of building a bridge, they'll get you an estimate. It'll likely be within 1-2 orders of magnitude of the actual cost/time, due to a bunch of unknown-unknowns that are hard to factor in (things like: how long the legislature will take to permit the build). But it'll still give you useful data about the differences between building a $million foot bridge, and a $100 billion highway bridge...
Yeah, the general attitude that estimation is impossible, guesswork, or useless is simply not commercially or professionally defensible. Other fields do it all the time without our tools, competencies, supposed specialties, or environmental control.
If one needs more information to articulate the issue at hand, get it. If the estimate is being misrepresented (ideal days vs calendar days), clarify. If methodology is uncertain, do it and iterate and improve it with experience.
Playing coy about how long it takes to build a deck based on a sketch and current availability, while making cute wordplay about how ‘the deck has to be built before one can know what deck there was to build to begin with’…? Whatever, Confucius, it really doesn’t sound like there’s enough deck building experience here, and the obfuscation seems unserious and anxiety related.
> Playing coy about how long it takes to build a deck based on a sketch and current availability, while making cute wordplay about how ‘the deck has to be built before one can know what deck there was to build to begin with’…? Whatever, Confucius, it really doesn’t sound like there’s enough deck building experience here, and the obfuscation seems unserious and anxiety related.
Ouch. Usually the ones writing very aggressive comments filled with attacks on stereotypes are the ones with anxiety problems :) You are fighting with the windmills. I do make estimates, and I'm usually better than many at it. It doesn't mean that the others like my estimates.
Also, you didn't even understand what I'm saying. TL;DR: You need to allocate a considerable amount of time on analyzing the task to make the estimate (around 10% of the time it'd take to solve it). I also take a jab at people injecting workarounds for the sake of keeping it in the estimated time and failing.
I know it is quite common, but the culture is the problem. The "leadership" in this piece have interests that are almost orthogonal to that of the engineer. The company is structured top-down, leading to a "it must become true because I said so" mentality, and probably the incentives of the people involved don't align either. Management doesn't have to care about that, because they're not incentivized to. When the wrong people get into that chain, these things happen. And worse too: in other industries, managers regularly override safety concerns.
I find these complaints to be symptoms of taking yourself too seriously, which is not only a poor way to act at a company but also a poor way to live your life.
Yes you’re an engineer and your time is valuable but you don’t have to act like it! Even if getting distracted causes you to lose some threads, you can’t ignore that you’re helping other people in the meantime. If you’re emotionally upset when you’re helping people they’re going to feel that and not want to try their best.
A company is not successful because of individuals, it’s the cooperation that causes the whole to be greater than the sum of its parts.
I don't think you read the article, or understand engineering if you discard the author's opinions with "taking yourself too seriously".
For example, reread the following paragraph:
> Few things are more disruptive to engineering than constant priority shifts. They make it impossible for engineers to plan or finish meaningful work.
Again, reread it and try to understand why the author stated that, instead of accusing them of taking themselves too seriously.
The problem is, if a leader asks for 3 weeks of work, and then every week asks for a different 3 weeks of work, nothing will ever get done. It belittles the engineer because that engineer isn't able to make positive contribution.
I suspect that you believe that engineers are merely pawns in a political game. Ultimately, companies that operate this way fail.
I disagree. I think it's pretty clear that they are saying that getting help from an anyone (in this particular case, an engineer) is a two-way street. Nobody likes being interrupted, especially when the interruptor has not made even the slightest effort themselves.
I'm the 'pointy-haired' boss and I usually don't take my engineering teams estimates at face value. I've learned to multiply the estimates to know when I can reasonably expect something to be completed. The multiplier is never less than 1.5.
And I can see if they are making progress and where they might be hitting difficulties. (Most roadblocks have nothing to do with the tech. It's usually either some organisational barrier or a personal issue.)
For me that's only true for projects/fixes with low time unit.
When I say 'it'll take a month', I usually took into account testing and deployment, so it usually take a month (and a week or two because I still overestimate myself).
When I say 'it should take an hour/half a day/a day', yes you are definitely right, and my manager is in trouble.
True. But I'm not measuring their performance relative to their estimates. I'm measuring performance relative to their peers and their previous performance. So giving me a padded estimate won't make much of a difference. Obviously, judgements are deeply subjective, since no two programming tasks are ever identical or even alike, but if you code a lot like, me you have a pretty good idea of what constitutes good.
"Could we have a meeting with your coworkers so you convince them this is the best course of action?"
I'm not a salesman or an evangelist. I'm a tech person and actually the local expert in the subject, a fact that you constantly advertise to the board. If you trust me, make a decision, it's your job.
Instead of that, you book the meeting, make me explain what we should do (that you vehemently agreed on before) and, when the others frown (the juniors because it's work, the seniors because it's change) you reverse the decision and quickly rebuke me and tell me we'll do it gradually (=never).
> [Senior engineers] keep things running, ensure projects get delivered, and prevent your codebase from turning into spaghetti. The good ones? They’re rare and highly sought after.
I didn’t see much of the ”highly sought after” bit in the recent years. On the contrary, the job market looks employer-friendly and the strategies for recruiting senior engineers seem increasingly backwards. Or is it expected that good senior engineers skip recruiting and rely on networking alone?
Sought after but many don’t know that is what they are searching for.
Getting the real senior devs in the enables and protects the process. Whether that process is winning depends on the total culture of humans segueing over things they want.
We make great layoff candidates because most of our code is something other people can take over maintaining. They keep the jackass who makes things nobody else understands.
The author seems to work for a company where engineers are treated as pawns in political games; and where leadership is more about perception than accomplishment.
The best way to handle situations like this is to leave, quickly! Companies that operate like this don't last long, because someone else will come and out compete them.
Edit: One thing I do when interviewing, is when I talk to the manager, I point blank ask, "how often will I be asked to change a task before I complete it?," and, " how many meetings will I attend during a day?." It screens out situations like this very quickly, because the managers who are looking to hire pawns won't hire me after asking questions like that.
> The best way to handle situations like this is to leave, quickly!
If you find these situations frustrating, I agree. There is little hope of changing how software development is done in these companies.
> Companies that operate like this don't last long, because someone else will come and out compete them.
I take it that you haven't worked in many corporate environments. This is how software development is done in many, if not most, large companies. Their only competition are other companies with the same processes. Smaller companies can operate more quickly, and sometimes this can be a variable that helps with disrupting established behemoths, but it's usually not the primary one, and it takes many years to do so.
> I take it that you haven't worked in many corporate environments.
I'm mid-career and I have worked in all different sized companies. That's why I explained how to avoid these situations.
You don't have to put up with being a pawn, nor should you encourage others to put up with working conditions like this.
Edit: I was in situations like the article describes twice.
The first time was when I tried to start a company. It took me over a year to realize the guy I was working with was just an "idea person," who couldn't stop letting his imagination run away. We could never work on a hypothesis, because every other week he had a new idea and wouldn't follow through on last week's idea.
The other time was a startup where I built an industry-leading product. It was usually middle management and inexperienced people who acted like the article described. Upper management would intervene, and often people who acted like the article described got pushed out of the company.
I'm only disagreeing with your assertion that companies that work like this don't last long. They do, and if they get disrupted by competition, this way of working is not the biggest reason for it.
I disagree. Engineer is correct when the role is about understanding that this is not an art [1] - there is a calculation performed to find the right balance between many variables of complexity, maintenance, cost effectiveness, ease of construction, reliability of construction, operation, etc.
These apply in concept no differently to building a bridge or a distributed software system.
There may be many who are just code monkeys but that doesn't mean some aren't practising engineering.
[1] Art in the sense that it can be perfect in its own right. There is no perfect engineering - everything is to a requirement and result of an optimal compromise.
I used to work for a Japanese corporation, and, when meeting with Japanese managers, you’ll see that they have a small notebook, open on the table, in front of them. Occasionally, they will jot something down in it.
You will also note that, whenever a date is mentioned, something gets written.
You are now being held to that date. They will completely leave you alone, until that date, when they will expect you to deliver “what was promised.”
In my experience, Americans never took this seriously, and it could be a real problem.
In my last company there was a new top priority every two weeks. And i still had a very junior team who needed a ton of mentoring and development to be able to turn things around quickly. Who were then getting blamed for not hitting impossible-in-the-first-place deadlines.
It seems that people in these kinds of positions feel very powerless, frustrated, and cranky. And they love to vote for posts that say these kinds of things. They validate the frustration that they experience working in these enterprise environments.
In theory, you're asking for hacker news, it just happens to be that there's many different communities represented here.
The tyranny of the front page means you're probably missing a lot of the posts that you might want to see. And people aren't making many of those posts because they know they won't get seen by many people.
cynical take: those people are typically too busy working 50+ hours a week and have worse work-life-balance. they might spend less time on hacker news.
I would recommend you attend a TiE event, but mostly to listen rather than talk. It is important to understand what "investors" actually typically do, and what people say to try to convince other people their ideas are viable.
The post and most of the comments feel kind of naive. Yes, these things are frustrating, but it’s your job. That’s what you’re paid to do. Nobody cares if you ship a hack if it “works”. Every single legacy project I’ve seen that earns actual money is full of hacks like that - it’s just the way it is, and a senior engineer should know how to work with that, how to communicate what really needs to be done and why it’s important. That involves dealing with management that doesn’t speak your language - learn how to do that too.
The points of this post are essentially how Chinese companies operate (of course , some western companies have this issue too, but for Chinese ones it seems the norm: call everyone in, waste an hour if everyone's time) :)
I just stopped going to recurring meetings with no agenda. Nothing bad has happened so far. Sometimes someone has something to discuss and asks me to show up, and then I do.
If you’re a senior engineer then your job is to manage these.
1 + 2: Tell them to open a ticket, mark it appropriately, and we’ll do it; but then when you come asking why we didn’t do other things, I’ll show you that chart.
4 + 4b: As a senior engineer, it’s literally your job to interface between leadership, PMs, and junior engineers. “Sync” usually means they want some time to chat about whatever comes to mind — make sure you regularly have these with all major stakeholders. Block out dedicated work hours, but let people consume your time outside of that — it’s your job.
5 + 7: Your job is to manage that we’re paid for features not craftsmanship; hacks are inevitable, but you should leave slack for improvements, document the business case for major fixes, etc.
3 + 8: Along the same lines, help leadership figure out a plan. Unavoidable thrashing happens at times at a startup, but even then, you should talk about roadmaps. Help leadership split the effort between long term goals and immediate payoffs; help them understand priorities.
There are people happier remaining at career IC levels (SDE2 at Amazon) because they don’t want to do these things — and that’s perfectly okay, too.
You need to read this for a while to understand that with "engineer" they mean "programmer". Nowhere does it say "software engineer". Indicating that somebody is trying to give general advice but is actually too deep into their bubble to realize the big picture.
> Engineers juggle a million things at once.
Eh what? If that's how your "engineer" calendar looks like then your org has more serious problems than a spontaneous "30 min sync" popping up in your calendar.
What is a "senior engineer" anyway? Everybody beyond intern stage is called "senior" these days.
There was massive inflation with job titles. When I started, we had three levels: junior, medior and senior. Anything else was just vanity. But now nobody hires medior or below anymore, so senior is the new entry level, followed by principal engineer, and "distinguished fellow engineer" is proposed as the real new senior title.
While all these points are valid - and I for one have a couple of people to forward the article to - I think there is more to this.
Alignment and understanding the product: As engineers it is easy to dismiss their task as conveying how the product works and defer to "it is implemented!".
I have stup a goal to post in the non-engineering Slack channels at least a couple of times with a video of how new features work, or give a short introduction on "that new testing framework" in human language.
Doing so is first and foremost a proactive move. Secondly it takes away the excuse of not knowing what eng is up to.
I like t-shirt estimates but only when we all agree we known wtf we are talking about. I also really like hacks. They get the job done and not everything needs layers and layers of leaky abstraction. I also quite like easy things like Config fixes, esp if they get escalated. You can leverage these to show impact and get a good rapport going.
I hate meetings without agenda. Honestly send me a message and I'll make sure I reply. Meetings with written agenda are great.
I have this recurring thought that every task I do seems to take either 10 minutes or 3 days and I never really know which it will beforehand.
Of course that's an exaggeration, but I've always found software time estimation to be difficult compared to actually writing the software and usually not very accurate.
I did have a VP in a meeting go “I don’t like that estimate.” I pushed the dice over and said “Ok, you roll”. Their hand got about 1/2 way before their brain caught on to what was happening and they pulled their hand back.
We normally agree on them writing a 2-3 page scope and I do an estimate based off the scope. Slow learners ask, How long to get the estimate, I look them dead in the eye and reach for the dice again saying “I’d like to see the scope beforehand but ....”
reply