by lauriswtf on 11/19/21, 10:20 AM with 271 comments
by crispyambulance on 11/19/21, 12:52 PM
Regardless of what you think your process is, somewhere near the top of the leadership pyramid, it all boils down to a customer promise upon which hinges your organization's reputation.
In non-dysfunctional organizations people at all levels can understand and adapt to curveballs that cause deadlines to slip. In such places you make estimates to the best of your ability with limited time and resources and communicate constantly with stakeholders on how things are going.
The hard thing is it all requires honesty.
Probably the most angry I ever got at work was once when, at the end of a project, I was on one of those bullshit status update conference calls with 20 people on the line. Throughout the project the team was I was on was led to believe that we were constantly behind and the deadline was from the beginning impossible to meet yet magically got pushed out several times to give us "grace-time". We cut corners like mad-men, amassed insane levels of tech-debt, and all but put a midget in the machine to make it work. What happened on the call? The product management team congratulated the PM for delivering so far ahead of time. I was so angry I couldn't even talk. Basically, the PM got accolades, the customer got shitty product, and we hated our jobs.
by harry8 on 11/19/21, 12:04 PM
IIRC each item is described by a poisson distribution. (Have I got that right, mean, long tail). Nobody models estimates as a sequence of dependent, poisson distributed events, that I've heard of at least. If you did you might at least get a range on the estimate. Between 2 and 20 days. That would be more accurate. Useful to anyone much? Unclear.
by rahoulb on 11/19/21, 11:53 AM
I broke it down into components and individual tasks, then put estimated hours against each one, then put it all into a giant spreadsheet, to track planned vs actual times.
If I remember rightly, it totalled about three months of elapsed work time. And it took me over a week to compile the estimate.
I also remember that I hit the predicted end date to within two days.
But the interesting bit was each individual task was inaccurate - lots were wildly underestimated, balanced by those which were wildly overestimated. Stuff like things I thought would take a day taking 15 minutes, other things I thought would take an hour taking a week.
by Mountain_Skies on 11/19/21, 10:53 AM
I believe this has only happened to me once in my career. My employer had recently switched from flat rate project bids to time and materials. A data transformation project that looked like it would take five or six weeks turned out to have repetitive tasks that could be automated easily. My estimate of three days, which was already padded, wasn't appreciated by the PM what wanted a month of revenue. After being told several times to account for contingencies and not budging much on my estimate, the project was taken from me and given to another engineer who gave the PM the estimate she wanted. While this was going on, I had already written the necessary code. My coworker had a month of mostly relaxed days as I turned the code over to him and he got busy finding ways to look like he was doing work for a month. Maybe I should have done that instead.
by nobody9999 on 11/19/21, 12:38 PM
And if that estimate isn't within 10-15% (the usual error bars) of the actual project duration/billable hours, there's going to be a problem.
What's more, while the developer(s) involved should have some input into that SOW, they shouldn't be writing that document. Rather, they should be writing code for other projects already estimated and sold.
As for in-house projects, that's a whole different story and is really dependent upon the processes of that particular organization.
All that said, developers should be spending their time developing, and their managers/managing consultants/salespeople should be doing all the other non-development tasks.
Edit: Fixed grammatical errors.
by sirwhinesalot on 11/19/21, 12:11 PM
That's the whole point of Agile, you need regular interaction with a customer to slowly build the software to a state they are happy with. And they should keep paying for the work until it is done or accept whatever state was delivered by the time the budget ran out.
If that is not how you are doing Agile you have missed the point. It is not possible to predict software development because unlike a bridge the requirements are never fixed and there are too many unknowns.
If you get your requirements fixed at the start, they never change, and you are not going to suddenly have to deal with some library/framework change in the middle of everything, then you can estimate, but you are not doing the software development 99% of the world is.
by stronglikedan on 11/19/21, 11:24 AM
by tupac_speedrap on 11/19/21, 11:09 AM
by brainwipe on 11/19/21, 3:45 PM
Budgets are built on it, deliveries agreed. Doesn't matter how much you decompose the task - unless you've coded that exact same thing many times before in the same way under the same conditions then it's just a guess. Been estimating for industry for about 20 years (although not the last 6 because we're agile in the truest sense) and most of the estimates have been wrong - sometimes over, sometimes under. Tech estimates are a lie that loads buy into.
by brianmcc on 11/19/21, 11:55 AM
And lo and behold, we price for a 30 day project that ends up taking 50...
So ridiculous.
by Hokusai on 11/19/21, 11:07 AM
The problem is not to ask for estimates, companies need to budget, plan hiring, and inform clients. The problem is that many companies do NOT ask for estimates but create delivery dates out of thin air.
So, I agree that estimates are a waste of time if they are not used. But they should be used as are part of any reasonable-managed engineering project.
by iamthepieman on 11/19/21, 2:41 PM
The utilities are heavily regulated, often beholden to taxpayers, lawmakers and public utility boards and working on use it or lose it budgets with hard cutoff times for delivery and go-live dates.
It's not just budgets and time constraints that make it impossible to do flexible estimates. Their internal personnel all have their regular work duties to attend to while supporting the migration and they can't drop everything for years at a time to dedicate support for the project. Add in the coordination with multiple vendors and you need to be hitting your time estimates, planned years in advance, within a week. Sometimes budgets don't matter that much, once they are a year into a three year project, they will find the money if it's needed, but the coordination alone requires this kind of accuracy.
It's amazing what necessity does to your estimates. We have become really good at it. This includes things like "Oh we're working with Oracle, add 3 weeks to that integration just because" or "this is a mobile app for the service techs who tend to be resistant to change, add another week for training and a month for revisions". Yes this is just "padding" but it's very specific padding that's tailored to the type of work being done and has so far been accurate and continually getting better for us.
edit: I should add that our estimation process involves multiple week long workshops with all parties. We go over every tool, process, integration and technology currently in use and then write a detailed design document that goes through 2 rounds of review with the customer before being signed off on. These design documents become the basis for a secondary contract to do the actual work and the customer understands that if it's not in the document, it's not getting built or migrated. Any additions require a contract change order.
by ajsnigrutin on 11/19/21, 11:51 AM
by tbwriting on 11/19/21, 3:35 PM
The bigger the project, the more likely it is that some small thing - something in the original spec, maybe, or more likely, an unforeseen interaction of its pieces - will be missed and will take an inordinate amount of time to deal with. All it takes is one of these to thwart the entire estimate.
by ubermonkey on 11/19/21, 1:37 PM
In software, it's hard to do estimates at all if you're a blue-sky environment. Once you have a codebase you're working on, it can be possible to give a better estimate of what it will take to implement a new feature, but the more elaborate the feature, the softer the estimate.
We have just shipped a very big change to our product, and we thought it would be a 3-6 month effort to do so. It took 3 years, because it was VERY invasive and VERY complex, and we just didn't understand the underlying challenges enough when we set out to do it.
by denton-scratch on 11/19/21, 4:43 PM
That's not an estimate; that sounds like the outcome of a negotiation. If someone demands an estimate from me, they get one - if it's not the one the manager wanted, he's free to substitute his own.
I'm accustomed to managers upping my estimates by 10%, and I've known them to increase them by 100%. For small jobs, requiring an estimate instantly doubles the estimate, because it takes longer to produce a good estimate than it does to do the work.
If you reduce my estimate, or try to talk me down, the new estimate is your estimate, not mine. And if you think it's fair to try to nail me to my estimate, then you obviously don't know what "estimate" means, and I need a new employer.
by rdsubhas on 11/19/21, 12:54 PM
Here is what works at a project level:
* When estimating, never go any step beyond the Feature level (don't split tasks, most of the time not even stories – just Epics or milestones are enough)
* Do RELATIVE COMPLEXITY estimate. Not time. If <epic1> is a medium, then relative to it, is <epic2> large or small? Stop at that level. Don't split it down any further.
Now compare just one of the epics to past history. That's all you need to estimate the rest of the scope, as it's all relative. It takes not more than a few hours for due diligence.
by todd8 on 11/19/21, 5:27 PM
So often, management wants a certain outcome, but needs the estimates as cover for making the decision. Just demand a detailed estimate, fool around with the estimates details--no matter what the estimate ends up being, and finally say "Estimates indicate that we should do this.", which is what they wanted to say all along.
by danielvaughn on 11/19/21, 2:18 PM
1. A daily standup bot pings us with the tickets assigned to us. We respond with a gut-level "percent complete" number for each ticket.
2. The bot tracks these estimates and over time, each team member can see whether they tend to over or under estimate.
The point is that we don't try to cram accuracy into developers, we just let them guess and let them see over time how good they are at gut-level estimation. The hope is that they'll eventually improve their estimations, but we're not going to tie it to performance or anything.
by dasil003 on 11/19/21, 4:45 PM
Without trust everyone is trying to cover their own ass, and in the case of large projects most of them will easily succeed since you only need one scapegoat. This is the type of environment where detailed estimates are demanded so that management had a paper trail, or where engineers implement the letter of a PRD and never propose changes to inconsistent or awkward requirements because it's too much energy and they'll be gone before they have to deal with the tech debt anyway. Often times in these type of environments someone will propose a process such as scrum to address particular pain points, but layering a process on a dysfunctional team doesn't address the core issue; at best the routine can shield individuals from chaos, but it won't actually improve throughput in any meaningful way.
At the end of the day, the best you can do with large scale estimation is get a handful of your best engineers who can roughly envision what needs to happen and have them chalk out a rough plan at a very coarse granularity and with key assumptions enumerated. Then with your best product people chalk out a strategic roadmap showing where they believe the product should go over the next 5 years so they can take that as input into account for architectural strategy. The key thing is that everyone understands that all long-term plans are subject to unknowns and change for all sorts of reasons—the point is not to pin people down but to leverage individual expertise to develop a best guess at what is possible. This is where trust is at its most tenuous and stands on a razor's edge; all it takes is one bozo to treat these things as guarantees and start throwing people under the bus when things go wrong, and before you know it trust is gone and everyone is in cover-your-ass mode. Now the group has lost the ability to accomplish the most ambitious goal of which they would otherwise be capable.
by drawkbox on 11/19/21, 12:11 PM
Estimates for tasks/apps/games/projects that have NOT been done before, or known from previous work are usually wildly incorrect. Like for instance making the first version of a puzzle game with new everything. Even more so for a new game type that you haven't done before.
Software estimation is like 65% correct (2/3rd) usually. There are so many internal, external and just unknown areas that usually these are underestimated greatly. The estimation is off by more when there are third parties or components/frameworks that get you 90% of the way but make the last 10% more tasking than custom sometimes.
The nature of software design and development is usually creating new value, in that case lots of those projects are unknown or the first time through something, estimation is almost useless in those areas. It is better to do prototypes to help refine and break it up into parts that can better be estimated.
Anyone doing an estimate on a new area that hasn't had a prototype will always be wrong. Estimates more than a month out are also wildly wrong. When you are asked to estimate something big, always just do an estimate for a prototype first before you ever begin to try to estimate the rest.
by diiq on 11/19/21, 12:00 PM
I'm not sure the prescription given fits the disease described; it feels more like passing the problem on to a different role than actually changing the approach.
by TrackerFF on 11/19/21, 12:20 PM
At least then you should have some data to look at - but when it comes to boutique products, with new clients, new teams, etc. who knows - you could easily get stuck on something for weeks to months, with no obvious resolution.
by lkrubner on 11/19/21, 11:57 AM
http://www.smashcompany.com/business/the-worst-project-manag...
About this:
>There is back-and-forth as the estimates are questioned for being too high, almost never for being too low.
Sonia did not allow us (the engineers) to talk to upper management, so she handled the translation herself. In some cases she was worried about macho engineers who competed on how fast they could do something:
"I can do that in a day"
"Oh yeah? Well, I can do that in 4 hours!"
"Ha! You two suck! I can do it in 2 hours!"
Perhaps Sonia's greatest ability was to figure out exactly how much each engineer tended to overestimate or underestimate tasks, and then to weight their answers accordingly. For the upper leadership, she was the only one who continuously offered accurate estimates of how long big new features would take.
by rackjack on 11/19/21, 4:18 PM
"That's another thing we've learned from your Nation," said Mein Herr, "map-making. But we've carried it much further than you. What do you consider the largest map that would be really useful?"
"About six inches to the mile."
"Only six inches!" exclaimed Mein Herr. "We very soon got to six yards to the mile. Then we tried a hundred yards to the mile. And then came the grandest idea of all ! We actually made a map of the country, on the scale of a mile to the mile!"
"Have you used it much?" I enquired.
"It has never been spread out, yet," said Mein Herr: "the farmers objected: they said it would cover the whole country, and shut out the sunlight ! So we now use the country itself, as its own map, and I assure you it does nearly as well."
from Lewis Carroll, Sylvie and Bruno Concluded, Chapter XI, London, 1895
from Wikipedia: https://en.wikipedia.org/wiki/On_Exactitude_in_Science#Influ...
by commandlinefan on 11/19/21, 5:03 PM
It got to the point of such ridiculousness that we finally started trying to flex the scope because the dates were so unrealistic.
Management's response? Add another row and column in the matrix of "resources" (that is, it's ok to add people if you need to) and "somewhat flexible". So after that all of our requirements were "date least flexible", "scope somewhat flexible" and "resources most flexible".
by hkt on 11/19/21, 12:25 PM
It was pretty crushing to have to constantly explain that my tickets were bigger than the average to a guy who obviously only cared about getting his KPIs down. I left.
by AnimalMuppet on 11/19/21, 5:18 PM
Do you need developers to do the detailed estimates? Yes, for two reasons. Politically/socially/culturally, having someone else telling you how long something is going to take you to do is... not received well, given normal human nature. Functionally, the developers have to be the ones to do the detailed estimates, because they're the ones who actually know what the details are.
All that said... overly detailed estimates are a waste of time. Don't break it down into a series of tasks, each of which take one hour or one day.
by noduerme on 11/19/21, 10:59 AM
I've always had a strong feeling that my strong feeling about when something will be done is fairly accurate. Decomposing that into ?+?+?+Contingency for the client tends to be the hard part.
by jb3689 on 11/19/21, 5:08 PM
Time estimates are still useful even if the range is large. If a high-bound estimate is still acceptable - great, ship it. If a low-bound estimate is barely good enough, that is a huge risk. If you get multiple estimates from multiple developers and they are wildly different, there's a conversation (i.e planning poker)
by karmakaze on 11/19/21, 2:55 PM
by kenoyer130 on 11/19/21, 12:04 PM
https://www.joelonsoftware.com/2007/10/26/evidence-based-sch...
by Zigurd on 11/19/21, 5:10 PM
by xputer on 11/19/21, 5:09 PM
by bengale on 11/19/21, 11:58 AM
At the end of the day a business is always going to need some sort of idea of what's being built and when it might be ready so that they can get a rough schedule together. No matter what games developers and project managers play with story points, or t-shirt sizes, or the myriad of other coping strategies they come up with, someone in the chain is going to try and map those to time scales.
In my experience, a reasonably senior developer can give a rough estimate of how long something is going to take in any case that isn't a complete unknown, if they really can't then you need an investigation project and that can be given a set time. But for almost everything else you can roughly say if it's an hour, or a day, or a week, or month. As long as everyone accepts that sometimes that will be over, and sometime under. If its an hour that doesn't mean you can do eight of them in a work day, but it means you can prioritise work.
That's the key I think, if you have a fixed date or a fairly fixed date, then it's often a good constraint. What you need to do is prioritise the work, and the only way you can do that is if you know that the things in your list could reasonably be done in that time. You can't have no estimates, and task three means your entire team needs to invent an AI or something stupid that will burn the whole timeline down.
If you've put a rough estimate of a week on something and you're reaching the end of week two, it's a great time to reassess. What technical people often don't get told, or don't understand is that sometimes something is only valuable if it can be done in a certain time. The business might want a feature that could be done in a week, but have no interest in it if it'll take six months.
If both sides can admit to their fears then it shouldn't really be too complex. Business is scared you'll get to the deadline and have 20% of the work done, with a good prioritised list they'll probably be happy if you're 80% of the way there. Developers are scared you'll hold it over them and berate them if their one day estimate becomes two days, but they probably know their one week estimate is bullshit and they just want to cover their ass a bit.
by Noe2097 on 11/19/21, 2:12 PM
The by-product of these discussion may be summed up as a number. But oh yes its unit must not be time.
by turbinerneiter on 11/19/21, 8:14 PM
What is so magically different about it? All other professions can do it. And not just the other professions, our company is one of many software shops that sells projects. We need to be able to make good estimations to be profitable, and we are.
Maybe it's all the VC and BigCorp money that is stopping you.
by willmadden on 11/19/21, 2:58 PM
The wildly inaccurate stuff seems to come from new work with loose definitions, manic developers, or situations where the work is billable hourly and outsourced.
Sometimes it's good to have an old, graybeard developer on the team :).
by Dumblydorr on 11/19/21, 5:46 PM
by r3trohack3r on 11/19/21, 2:52 PM
by jrs235 on 11/19/21, 4:00 PM
by pxc on 11/19/21, 6:26 PM
those lines made me laugh out loud the first time I heard them
by brightball on 11/19/21, 12:59 PM
https://www.brightball.com/articles/reality-driven-developme...
by movedx on 11/19/21, 12:09 PM
As long as the middle ground between rough-as-toast and perfection is found when developing something, and that something is delivered, then it takes as long as it takes and that's that.
by dqpb on 11/19/21, 4:12 PM
However, PMs weaponize estimates against the engineers and that ruins the whole exercise.
Also, teams should use a betting market with real money. People deserve to be paid extra for being right.
by Cyberthal on 11/20/21, 2:06 AM
by balaji1 on 11/19/21, 7:53 PM
by Kalanos on 11/19/21, 8:55 PM
on one hand, estimating essentially requires architecting, and that's never a waste of time. on the other hand, you could argue that even w a good plan you won't know where the 1-2 rabbit holes will be (some subtly critical facet of my use case not jiving with the proposed toolset).
So i'd say get a decent plan (weeks, not hours) in place and give yourself a 50%+ buffer.
by marcodiego on 11/19/21, 2:09 PM
by pacifika on 11/19/21, 12:50 PM
by ricardobayes on 11/19/21, 2:56 PM
by jrochkind1 on 11/19/21, 3:29 PM
by ChrisMarshallNY on 11/19/21, 12:03 PM
I worked this way for most of my career. One of the big reasons, is that I spent a lot of my career, writing software in support of hardware devices, and coordinating parallel development efforts was crucial. Lots of critical paths.
Also, hardware people tend to be very "waterfall-y," so I was often never given a choice.
As a result, we learned to give fairly accurate estimates, for pretty long-term projects.
The main problem with this approach, is that it delivers yesterday's technology, tomorrow. By the time the project is released, no one wants it. Also, it's quite possible to deliver features and algorithms that aren't useful, inherently flawed, or actually detrimental to the user's workflow.
Once it has been written into the lists, it is set in stone; even if it is found to be a mistake.
After leaving my last job, I started experimenting with more flexible development methodologies. I think I've had some success[0]-[4], but the scope of the projects has been much more humble than my previous works (out of necessity).
In the project that I'm developing now, there has been almost no "up front" plan at all, and no set schedule. I've been working on the frontend app (a native Swift iOS app) for over a year. The backend is a couple of servers that I wrote years ago. One has since become a standalone open-source initiative, run by a different team[5], and the other was one that I made as "practice," several years ago[6].
In developing the frontend, I created a TestFlight-ready app, almost immediately (I made my first TestFlight release about a month after I started coding). This has been a "running prototype," ever since. The entire team gets releases, quite quickly, and gives feedback and testing. Additionally, the app is continuously being vetted by Apple, so we are unlikely to have the "App Store Approval Brick Wall" problem.
This has allowed the specification to "morph," throughout the life of the project. I have actually thrown away months' worth of code, as we have decided to pivot direction, many times, throughout the lifecycle.
We're all very happy with where it's at, now. We are in the home stretch (but we still have at least a couple more months of work on the frontend app). It is almost entirely different from the original, unworkable, "idea man" concepts, that were presented to me, over a year ago.
I've also been doing this for free. I can't imagine any company that wanted to make money, doing it this way. I would have been forced to deliver a crap hack, six months ago.
[0] https://littlegreenviper.com/miscellany/thats-not-what-ships...
[1] https://littlegreenviper.com/miscellany/forensic-design-docu...
[2] https://littlegreenviper.com/various/evolutionary-design-spe...
[3] https://littlegreenviper.com/various/concrete-galoshes/
[4] https://littlegreenviper.com/various/testing-harness-vs-unit...
[5] https://bmlt.app
[6] https://riftvalleysoftware.com/work/open-source-projects/#ba...