15 ms·

I've been developing software for over 20 years, and I still can't estimate how long something will take me when I've never done it before. This uncertainty nee

I've been developing software for over 20 years, and I still can't estimate how long something will take me when I've never done it before. This uncertainty needs to become more than just a stick to beat developers about the head and shoulders with. Most of the time the PMs understand this, but there have been many projects where they just don't get it. I have suffered great anxiety from being forced to give estimates when the truth is I have no clue. It depends on how easy it is and how many unforeseen issues I encounter. It was so bad that once my husband asked me how long it would be before I was done cooking something, and I practically had a meltdown. That's when I knew it was time to leave that team. Can we stop pretending we can forecast the unknown? (edit typo)

java-man 7y ago
I think there is a way to give an estimate (have been doing it myself for a decade), even for dependencies that are not known from the start. (I mean, reasonable dependencies. No one can account for unknown unknowns, but the software engineering field is not an art, more of a skill, we do have well established processes to minimize the surprises). Is this something that HN audience is interested in?
- Bjartr 7y ago
  I'd love to hear what you have to say in the topic.
  - java-man 7y ago
    Sorry, tried to answer and apparently I was "posting too fast". One may start with enumerating the features that needs development (a.k.a. "user stories"). Also enumerate external dependencies, team overhead (more people working together means overhead is greater). For each feature enumerated in step 1, try listing as much detail as possible, also listing open issues and unknowns. For example, list all the UI elements under development. List all individual functions / use cases that need distinct functionality (classes, functions) to be developed. List all the test cases. List external APIs, enumerate different ways the said API can be used. Enumerate failures and possible recovery actions. I'll give you an example: a login dialog for an application. This starts as a two page requirements document, which balloons to around 120 items using this method. This alone should give a good idea at the start of the project. Keep doing it (enhancing the level or detail), while keeping the ratio of initial estimate vs real value - that will help in estimating the remaining portion of the work. The problem (the way I see it) is that we don't really have the tools to do this kind of tracking and analysis. Jira and similar systems don't even come close. Here is an attempt to apply the methodology using Excel: https://github.com/andy-goryachev/PasswordSafe/blob/master/Feature%20Matrix.xlsx https://github.com/andy-goryachev/PasswordSafe/blob/master/F...
    - stronglikedan 7y ago
      And then the customer decides that they don't want to move forward with the project because it's too expensive. Oh, and they don't want to pay you for all the time you spent estimating because no one pays for estimates up front anyway.
      - java-man 7y ago
        Yep. 30% upfront. But actually, once you show the customer what's involved, and give them a realistic estimate, it might reduce the chances of cancellation. The discussion might be steered towards what they really want, or prioritization of deliverables. A mockup (and multiple iterations thereof) might be necessary as well.
    - DougBTX 7y ago
      https://www.microsoftpressstore.com/store/software-requirements-9780735679665 https://www.microsoftpressstore.com/store/software-requireme... That book is from this perspective, that you can work out what needs to be done for a project before actually doing it.
    - silveroriole 7y ago
      This is roughly how I was taught to estimate. It is accurate but takes time and everybody hates the result. Management halved my estimates without telling me, made fun of my mentor’s estimates, complained about needing to know everything upfront (not very agile eh!), etc. I think you are right and estimating is more of a solved problem than we think, some people just don’t want to admit it!
      - java-man 7y ago
        Oh yes, my experience as well. I just hope these companies do not manufacture aircraft or nuclear power plant software.
- justinpombrio 7y ago
  > Is this something that HN audience is interested in? Are you teasing? Yes, we want to know! Though frankly I'm incredulous.
  - rhizome 7y ago
    Fred Brooks would be incredulous.
  - java-man 7y ago
    No, I wasn't teasing, but I wasn't sure that people would find it interesting (at least, this was my expectation based on experience). I tried to describe the process somewhere in this thread.
    - justinpombrio 7y ago
      It just sounded like teasing because it's a famously hard problem. But having read your proposal, I actually totally believe that that could result in accurate time estimates. To summarize, remove the unknowns by planning things out beforehand, then count how many hundreds of small pieces you'll need! That sounds plausible as long as what you're doing is straightforward. (E.g., no crazy database optimizations needed to make things fast enough, no crazy ML techniques needed to make things accurate enough, no crazy algorithms needed to solve NP-hard problems, etc.)
      - java-man 7y ago
        You are right: non-trivial things are hard to estimate - as tasks may not even have an upper time limit. But in the majority of software development projects the tasks are trivial, and it is possible to enumerate all the little details and their dependencies. I was thinking of writing a tool to support the process instead of using excel, but unfortunately the dev has stalled due to lack of time on my part. https://github.com/andy-goryachev/ReqTraq https://github.com/andy-goryachev/ReqTraq
- LyndsySimon 7y ago
  > I think there is a way to give an estimate (have been doing it myself for a decade), even for dependencies that are not known from the start. I agree with this. The problem is that estimates vary, and that management teams often don't understand the way they vary. It's one thing if your estimates are precise and are generally accurate within 20%; it's another if your estimate is "it will likely take between six months and three years", and a third of the time the actual required time falls outside even that range. ... and yes, there are many projects for which such a large estimate wouldn't be unreasonable; nor would it be unreasonable for there to be unexpected breakthrough or challenges that significantly impact the timeline. > Is this something that HN audience is interested in? I can't speak for the community, but I think the only way you can know the answer to this question is to post it :)
cwyers 7y ago
Flip it around: it's really hard to budget, plan for staffing, make commitments, etc. without the ability to give estimates of this sort. The best thing to give yourself when giving estimates of a dificult sort is the freedom to be wrong, and the ability to express how confident you are in such an estimate.
Frost1x 7y ago
I'm the same way but only about 15 years experience. I have a friend recently retired who has done a wide variety of software development since the era of punch cards (at least 40 years development) and he agrees with me entirely. I'm not sure how people can provide any reasonable estimates, especially these days when technology is shifting even faster under your feet unless it's a clone of something you've already done in a specific set of technologies that haven't changed. For me, I simply make a very conservative guess and use a 2x or 2.5x multiplier to be safe. I'm usually far ahead of schedule but there have been occasions I as happy I added a 2.5x multiplier in. Everyone is typically happy... the fact is, my estimates are garbage.
- vnorilo 7y ago
  This is what I do! I disagree on 'garbage', though, I would say that you sound like you estimate very well, and that factor of 2.5 uncertainty is reasonable given all the unknowns in this line of work.
- danmaz74 7y ago
  Even those estimates are good for people who have no clue if something can take 2 weeks or 6 months. They're not garbage.
- username90 7y ago
  > Everyone is typically happy... the fact is, my estimates are garbage. If people are happy with your estimates then they are good estimates.
shados 7y ago
> Can we stop pretending we can forecast the unknown Within reason. Ive worked in orgs where there is no estimate at all, and that bring a different set of problems (unbound projects and no work getting done because of the complete lack of pressure). Now you're totally right: software engineers rarely do the same thing (or even similar things) twice, so estimating is somewhere between "very hard" and "impossible". "Scoping" however is still needed. If you ask me "How long will it take to add a button to this page", that's a very ambiguous question. I can solve the problem in a few ways: - Tack on a plain html button element - Add a button from an existing styleguide/library/design system. - Build our own button component instead of reusing one. - Build a full blown button editor that allows a non-software engineer to use a WYSIWYG editor that will create their own custom button and insert it on the page without code. Now obviously there's a range between these, going from a few seconds (plus deploy), to months or years of work. The project/product/whatever managers and the tech leads/engineers need to work together to agree on scope. An arbitrary deadline can be picked and then engineers have to do whatever they can up to that deadline. Or we can agree on minimum functionalities with onbound deadline that MUST be created regardless of how long it will take. Realistically, successful projects will be a mix of both, along with various forms of padding and revisiting estimates along the way to account for unknown and mistakes.
- deleted 7y ago
  [deleted]
- jrs235 7y ago
  > because of the complete lack of pressure I would say it may be due to more of a lack of focus.
- avgDev 7y ago
  I feel as you should be able to provide an estimate even if it something that you have not completely done before. One should spend some time to gauge how much of this new thing is really "new" and what parts should be easy to figure out. Then, try to look at resources about those unknown parts, and that should allow to provide a rough estimate. And when road blocks come up just communicate early, and then if PM/boss don't understand there is not much you can do but probably look for a better gig.
lowken10 7y ago
I just round up. If I get pressed I round up higher.
bfrydl 7y ago
There's a balance to it for sure. It sounds like estimation was taken far too seriously on your team if it was affecting you outside of work too. However, estimation is one of the primary skills of a software engineer. It's always hard to estimate well, but it's infinitely harder for a less technical person to do it for you. I think it's important to understand that and do one's best to improve at it over time.
Isamu 7y ago
>That's when I knew it was time to leave that team Currently in that situation. My "agile" estimate blew up by a factor of as much as 10, just because the ask was conceptually very simple, even to the domain experts I consulted. And by bad luck the way I was implementing the story it happened that the issues unfolded one-at-a-time, rather than somewhere in the beginning where we could have broken things up into more stories with additional time. I mean, it happens in engineering sometimes. We engineer our way out of it, and the engineering is solid in the end. But no, we blew up our story, so all that working nights and weekends to get back on track are for naught.
- celticmusic 7y ago
  why in the world would you ever use the end of a sprint as a hard deadline? That's broken from the get-go.
  - Isamu 7y ago
    >That's broken from the get-go. Indeed.
  - abawany 7y ago
    Broken, but very very common, IME. All of the agile-phile places that I have had the misfortune to interact with had things like sprint commitments, and etc. Very abusive and quite the opposite of 'people over process'.
- rhizome 7y ago
  >My "agile" estimate blew up by a factor of as much as 10, just because the ask was conceptually very simple Please do not feel bad, nor let anybody make you feel bad about this. It's absolutely natural for this to happen. If anything you could use it to ask for a junior or intern to delegate implementation details while you dig further into the coal mine of this feature. "Simple is hard." What you can learn from this (beyond team pushback) is what kinds of questions can be asked to figure out if a simple ask is masking 10 other things.
- matwood 7y ago
matthewhartmans 7y ago
I think this is where a 'spike' solves your problem. By creating a spike, you can do some initial investigation into how the code is written, what's involved, how long it will take, etc. Once you have completed your spike, you can come back to the original piece of work and give a better estimate based on your findings.
- eropple 7y ago
  In the perfectly spherical Agile world, yes. In practice, for anything that's new, your project devolves into a set of spikes for development because your time-boxed investigation leaves unknown unknowns everywhere. Which is fine in that perfectly spherical Agile world, but it makes less-than-perfectly-spherical stakeholders very upset that they are not getting to use the Agile stick to beat over their developers' heads, as they have been trained to do.
- dymk 7y ago
  Maybe a spike takes a week. Maybe a spike takes an hour. I can't estimate that. Which would be fine, but then management or the PM expects me to loop back around when a spike is complete. I'd rather just continue engineering a solution when I'm done investigating, which is the natural progression of things. I'd rather treat {get requirements, investigate, implement, debug, deploy} as a single atomic task, rather than splitting it across N meetings for planning the sprint, planning the spike, meeting with the PM for more requirements they forgot to put in the user story, describing it at a retrospective, showing it at a demo. Now I know somebody will say "But that's now how agile works!". Well, we have a few agile "coaches" that were embedded in our teams who would disagree.
  - nprateem 7y ago
    What are you doing in a spike? If you can't work out after a day the rough complexity of the task (bearing in mind you should be working on a small deliverable) there's something seriously wrong. You're not meant to be doing the work in the spike. If your research spike shows that it could be a can of worms, then the outcome of it should be another ticket for a proof-of-concept for another sprint, but with specific goals (e.g. "get a POC working that does X, Y & Z").
rhacker 7y ago
I know that kind of environment too. Usually some department head is a YES person, saying the delivery can be done in some timeframe X. Then timeframe X is told to the dev team and the dev team says X + 50 days. Then the dept. head goes back to the sales team and by that time it's too late. Then the entire organization pushes down on the dev team with fury. The product is of course released in X + 75. (because you always need to double or triple the dev team estimate) Those environments are toxic and the sign of toxicity is that the estimation process is not up for discussion (AKA the dept head keeps doing it again and again and no heads roll)
gesman 7y ago
Sometimes it's good to give people what they ask for [insist on], even if it does not make a sense. No anxiety needed. Then calmly explain that the reason things didn't work out as [they] expected is because in real world things doesn't work the way they want or fantasy about. Suggest better approach. If they refuse and keep doing [asking] the same thing all over again and expect a different result - then let it be their insanity [or anxiety], not yours.
jtolmar 7y ago
Most time estimates aren't necessary in the first place and it's aggravating that we need so many of them. Yes it's mostly a stick to beat devs with. But since folks reading this will probably need to make estimates anyway, this tends to be accurate: Estimate it'll take as long as the most recent similar thing you've done (real time, not heads down time). Resist the urge to trim out parts of the previous task that aren't related (you'll have new yak shaving) or related to mistakes you've learned not to make (you'll make new ones). If it's really different from anything previous, look for a time you had to learn something and implement a new system based on what you learned (you're allowed to be meta).
- mdpopescu 7y ago
  There's a problem with this. See JB Rainsberger's video: https://www.youtube.com/watch?v=WSes_PexXcA https://www.youtube.com/watch?v=WSes_PexXcA
xwdv 7y ago
No. Even bad estimates are better than no estimates. If you are having meltdowns your reputation is being tied too closely to your ability to give estimates. You must never turn estimates into a promise, always remind people they are estimates. Want to give fast estimates? Here’s how: 1) first determine the scale of the task? Is it a year, month, week or day kind of task? 2) Then, it’s just 3 of those units. The smallest task takes 3 days. One day to completely fuck up, one day to figure out why, one day to get right. The longest takes 3 years. One year to fuck it all up, one year to learn why, one year to finish it. I suggest never giving estimates in units smaller than a day. They just become noise. If a task is smaller than dayscale just say the task is too small to provide any meaningful estimate but won’t take more than a day.
- deleted 7y ago
  [deleted]
- bb88 7y ago
  > Even bad estimates are better than no estimates. No estimate is clearly better. Here's a common story I've seen across multiple companies. 1. Marketing management asks Engineering management how long it takes to do feature X so they know when to launch the online ad campaign. 2. Engineering management then asks potentially good coder how long it will take. Coder replies with a time and "it's just an estimate." 3. Engineering management reports to Marketing that coder's estimate leaving off the most important caveat, and Marketing treats that as the gospel truth. 4. Coder takes longer than expected because of some bad technical cruft that some other engineer put in because he was potentially rushed or just plain inept. 5. Marketing is pissed because they now have to withdraw the ad campaign, and starts blaming engineering. 6. Under increased scrutiny, Engineering gets a bad reputation, who then throws the coder under the bus in front of Marketing and other managers. 7. This shows up on the coder's annual review who then leaves. 8. Engineering hires replacement which will have a 3-6 month learning cycle, and potentially writes worse code than the person that just left. EDIT: The point is that if there's no estimate, management has to deal with the uncertainty that the coder experiences. Hope for the best, plan for the worst.
  - 7y ago
nprateem 7y ago
> I still can't estimate how long something will take me when I've never done it before In that case you're meant to do a spike to research the issue. You can timebox the spike to half/whole a day. Then use that knowledge to help your estimation for the following sprint.
hector_vasquez 7y ago
Nobody in charge cares about the estimate of an individual task. They care about progress toward program goals. With experience and skill, estimation mistakes tend to come out in the wash.
agumonkey 7y ago
Probably lost 10 years due to that.
jen729w 7y ago
After many years in large infrastructure transformation projects, Johnny’s Rule of Threes now goes like this: 1. The first time you do something, you can guess how long it will take and what the detailed steps will be, but that is all. You should still plan it, but during execution of this phase you must take copious notes. Do not expect it to be correct. 2. After you have done something for the second time — using what you learned from the first time — you should end up with an accurate schedule. This schedule contains all of the steps required to do the thing along with accurate estimates of time and cost. 3. The third time you do the thing, you are able to do it to schedule and to budget.
- nitely 7y ago
  I can see how this would work for software boutiques doing fairly similar projects each time, or projects with very similar parts, but not in complex products. Much less for software that does not use any kind of framework or follows any kind of recipe. Sometimes it's just step 1 in a loop.
carlmr 7y ago
Use a random number generator to generate your estimates and slowly modify the mean until it matches expectations. I bet your estimates won't be as far off as your colleagues'.
allenu 7y ago
I agree. My theory now it's due the fractal nature of the tasks in software development. To design at a high level and break out the work, you have to make some assumptions about the ground-level designs (i.e. how individual components talk to each other). As you start implementing those, you'll have often encounter unexpected constraints that require you to rework the high-level design. As you progress through implementation, you find more and more tasks that need to be done and eventually the number of tasks generated levels off and starts to decay and it's only then that you really have an idea of how long you need (assuming no large bugs surprise you at that point). I find even heuristics like double your estimate or padding it aren't useful because there's so much variance.
matwood 7y ago
Estimates are like the cones of uncertainty NOAA publishes during hurricane season. A simple task I have done before is at the bottom of the cone. Possible complexity and unknowns push my estimates further out the cone. Less than a year, but more than 3 months is my standard answer for those random 'how long will this feature take' that I only have a vague idea about [0]. I then follow up asking if they would like to schedule a few weeks of research to close the cone a bit. The point is that you have to manage the person asking for the estimate. Teach them that unknowns means something could take a day or a month. I've only had one person really be a jerk about it, and my response was to make the estimate whatever they wanted. If they were not going to listen to me, then there was no point in giving an estimate at all. That response was from my younger, smart ass self though YMMV. [0] This also depends on what is being asked. How unknown are the unknowns? For example, is the feature clearly visible in another product?
snarfy 7y ago
You go to the mechanic and tell them your car won't start - nothing happens when you turn the key. You ask them how long it's going to take to fix and how much it will cost. They don't assume it's the starter and tell you it will be $400 for parts and labor. They tell you it will be $150 diagnostic fee and the diagnostic will take two hours. Then they call you and tell you the cost to fix and time it will take. For whatever reason, software engineers don't have the luxury of doing a diagnostic. We are made to guess up front and assume it's the starter, when we really have no idea what rat's nest is under the hood until we look.
- disqard 7y ago
  This was a good analogy!
- theptip 7y ago
  > software engineers don't have the luxury of doing a diagnostic These are called "spikes" in the agile community (no idea why), and "prototypes" elsewhere. If you feel that the error bars are too wide on your estimate, you should build the minimum prototype required to reduce the uncertainty to tolerable levels. I like to schedule these at least a sprint prior to kicking off the main task, so that you can benefit from the improved estimate accuracy when actually scheduling the thing.
- rufflez 7y ago
  Often, you think it is a car, and then when you start to work, you realize it is actually an octopus
  - gilbetron 7y ago
    I love this comment! The analogy I've been using lately is that it's like estimating how long it will take to pack your kitchen when you are moving, except sometimes you open a cupboard door and there's another kitchen inside.
- GFischer 7y ago
  For whatever reason, software engineers don't have the luxury of doing a diagnostic. That´s not necessarily true. I´ve worked with very good, serious consultancies, and I´ve seen a quote for thousands of dollars for exploratory work to give an estimate. Of course that was for a million dollar project - smaller projects might not have this opportunity. Other companies had some interesting approaches where they gave order-of-magnitude estimates and then refined the estimate iteratively.
galaxyLogic 7y ago
I usually reply: Give me a week to look into it then I will have more insight into how long it might take. But you are right the problem is you can't estimate (correctly) how long it will take to do something your organization has never done before, that's what should be made clear to them. At the same time it is true that estimates get better as we start working on it, and the work can start by focusing on the unknowns to figure out how difficult they are to do. If that is a plan they agree to.
majikandy 7y ago
Spot on! I’ve also been developing software for over 20 years and my estimates have never improved. I think an order of magnitude is the only reasonably useful estimate, which can then feed into the question “is it worth doing it or not?”
ericmcer 7y ago
If you are a good engineer and a valuable member of the team people will know, whether you hit your estimates or not. It’s almost like the better you are at actually producing the less you need to worry about the red tape. If you are invaluable and crushing projects no sane manager is going to fire you over your estimate accuracy, but if you are doing poorly and not producing they may point to it as a problem area. I have only worked for small-mid size teams though so maybe it is not like that for huge ones.
deleted 7y ago
[deleted]
bsder 7y ago
> Can we stop pretending we can forecast the unknown? Except that you're wrong. We predict quite well, thanks. The problem is that everybody ignores the predictions. Most people predict approximately where the 50% probability is with maybe a little fudging. And they tend to be pretty good at it. The problem is that everybody just adds those up. And that's the disaster from a statistical viewpoint. Things can only come in so early, but they can come in infinitely late. A blown schedule on an early dependency throws everything out of whack far more than a late dependency would. We can roll these up in a proper way. We can run Monte Carlo simulations and get "real" numbers. People have done this and the results are remarkably accurate. The problem is that someone in management will always undercut the realistic estimate for personal gain. And then wind up longer than the estimate at the end. And, the worst part is that this is RATIONAL. The only way to get a project completed is to start and get the sunk-cost fallacy rolling in the powers-that-be.
tootie 7y ago
I just screamed this at someone (over IM, not really screaming) that estimates in scrum are meant to measure complexity and not time to completion. There are still people in 2019 saying things like "1 point is 1 day of work" and I want to murder them. The whole point of scrum is that time estimation is futile. Estimate complexity and then measure your velocity as tasks get completed and you can make a rough forecast of future velocity.
ChrisCinelli 7y ago
There are ways to get better at estimates. And a proper process will help you to do it. Unfortunately most of the orgs do not do it. 1) We know that "People are bad at estimates". That is why the estimate should come from the team (not one person in the team). Most of the orgs that I know do not do this. And to be honest they are not set up to do it because people in a team do not have overlapping skills. Ideally you have a team where people can take other people jobs (to a certain degree). You can then, during grooming, play "poker scrum" to estimate (where it is harder for people to cheat following what the lead person says). It is ok for somebody to say "I have no idea". The AVERAGE (not the MODE) is used for the estimation. If the items are more than 2 card apart have the 2 people at the extreme say why they think they think it takes the little amount of points and the other person why they think should take the large number of points. 2) If it is hard to agree on the estimation, the item probably needs to have a "spike" where more assessment or design is done in order to make clear what need to be done. In my team we also agree that a story has more than a certain number of points, we may say that it is too big and we have to break it down. 3) During retrospective or a specific meeting we have the team look at the time that an item really took and when it was more than 2 card off, try to understand what was under or over estimated. Usually after about 5 cycles, people start developing a sense of what the right amount of story point should be for a story. If you are always left by yourself at estimates and you never properly scope the task before and reflect on the variance afterward, it will be very hard to become good at estimations.
NullInvictus 7y ago
I've become convinced over the years that upper management doesn't really care about 'estimates'. What they care about 'commitments'. Every team I've been on has had upper management drive team leaders to get 'commitments'. They want some form of emotional investment in the work. That way, when scope has arbitrarily changed or a massive problem has lead to run over, they can stare at you like a whipped puppy-dog and say "I know it's 10PM and you want to get home to your wife, but you promised us, you committed, to getting this done on time..." Pure emotional exploitation. The ideals of agile are laudable. I was the excited bannerman of my first agile experience and I read the manifesto with a lot of hope. However high-minded agile is, the language is too easily co-oped into the worst sins of management. In many places it exists solely to blackmail free overtime out of engineers, get away with micro-management, and ride engineers with false deadlines under a guise of hipness and modernity. Estimates are just there for a false sense of stakeholding, or at best a ballpark cap so you don't work yourself into suicide. They can't be made accurately even if we could estimate properly, because all estimates are constantly second guessed by people who are making judgmental jokes about sandbagging, or asking "Are you really sure it'll take that long?" in voices that practically scream "chilling effect". More than a few possibly realistic estimates are torpedo'd by managers who are looking at their roadmap and tsking about how they don't line up. I would even say accurate estimates are actively undermined. I've worked at companies which have positive work images abroad, and even there any team which was on time found either its sprint budget slashed, or scope increased until it was forced behind. The underlings won't do over-time if they don't feel the squeeze. Story points, velocity, burndown, and any other metric you can think of that Agile courts are absolutely useless, because this industry refuses to come to terms with Goodhart's Law. I just watched a 10 million dollar project go up in flames. Their sprint graphs were great, and a constant buzz was going about the company about how these teams were setting the standard, meeting their metrics and goals consistently. Only recently did the CEO get down to business and figure out that all the metrics were bogus, and that for the past year all of the PMs and teams had been gaming the system to hide the fact that they were way behind schedule and over budget. The project was quietly scrapped and nothing changed. The shell games continue to actively sabotage data. I only know of the fallout because of who I sit next to. Most of the benefits of agile seem to fail basic contact with humans unless they are backed by outstanding and visionary leadership. Most companies do not have that, yet they still find value in switching to Agile. Why? Maybe because even in total collapse it provides an unparalleled system for squeezing out more overtime, in my cynical opinion anyways. I don't really what else to offer in place of Agile. I'm not that intelligent, but I don't really feel the industry can come up with a good development model of software development culture until it stops what it's doing and starts acknowledging problems arising from basic psychology, politics, and data gathering.

java-man 7y ago

I think there is a way to give an estimate (have been doing it myself for a decade), even for dependencies that are not known from the start. (I mean, reasonable dependencies. No one can account for unknown unknowns, but the software engineering field is not an art, more of a skill, we do have well established processes to minimize the surprises). Is this something that HN audience is interested in?

Bjartr 7y ago
I'd love to hear what you have to say in the topic.
- java-man 7y ago
  Sorry, tried to answer and apparently I was "posting too fast". One may start with enumerating the features that needs development (a.k.a. "user stories"). Also enumerate external dependencies, team overhead (more people working together means overhead is greater). For each feature enumerated in step 1, try listing as much detail as possible, also listing open issues and unknowns. For example, list all the UI elements under development. List all individual functions / use cases that need distinct functionality (classes, functions) to be developed. List all the test cases. List external APIs, enumerate different ways the said API can be used. Enumerate failures and possible recovery actions. I'll give you an example: a login dialog for an application. This starts as a two page requirements document, which balloons to around 120 items using this method. This alone should give a good idea at the start of the project. Keep doing it (enhancing the level or detail), while keeping the ratio of initial estimate vs real value - that will help in estimating the remaining portion of the work. The problem (the way I see it) is that we don't really have the tools to do this kind of tracking and analysis. Jira and similar systems don't even come close. Here is an attempt to apply the methodology using Excel: https://github.com/andy-goryachev/PasswordSafe/blob/master/Feature%20Matrix.xlsx https://github.com/andy-goryachev/PasswordSafe/blob/master/F...
  - stronglikedan 7y ago
    And then the customer decides that they don't want to move forward with the project because it's too expensive. Oh, and they don't want to pay you for all the time you spent estimating because no one pays for estimates up front anyway.
    - java-man 7y ago
      Yep. 30% upfront. But actually, once you show the customer what's involved, and give them a realistic estimate, it might reduce the chances of cancellation. The discussion might be steered towards what they really want, or prioritization of deliverables. A mockup (and multiple iterations thereof) might be necessary as well.
  - DougBTX 7y ago
    https://www.microsoftpressstore.com/store/software-requirements-9780735679665 https://www.microsoftpressstore.com/store/software-requireme... That book is from this perspective, that you can work out what needs to be done for a project before actually doing it.
  - silveroriole 7y ago
    This is roughly how I was taught to estimate. It is accurate but takes time and everybody hates the result. Management halved my estimates without telling me, made fun of my mentor’s estimates, complained about needing to know everything upfront (not very agile eh!), etc. I think you are right and estimating is more of a solved problem than we think, some people just don’t want to admit it!
    - java-man 7y ago
      Oh yes, my experience as well. I just hope these companies do not manufacture aircraft or nuclear power plant software.
justinpombrio 7y ago
> Is this something that HN audience is interested in? Are you teasing? Yes, we want to know! Though frankly I'm incredulous.
- rhizome 7y ago
  Fred Brooks would be incredulous.
- java-man 7y ago
  No, I wasn't teasing, but I wasn't sure that people would find it interesting (at least, this was my expectation based on experience). I tried to describe the process somewhere in this thread.
  - justinpombrio 7y ago
    It just sounded like teasing because it's a famously hard problem. But having read your proposal, I actually totally believe that that could result in accurate time estimates. To summarize, remove the unknowns by planning things out beforehand, then count how many hundreds of small pieces you'll need! That sounds plausible as long as what you're doing is straightforward. (E.g., no crazy database optimizations needed to make things fast enough, no crazy ML techniques needed to make things accurate enough, no crazy algorithms needed to solve NP-hard problems, etc.)
    - java-man 7y ago
      You are right: non-trivial things are hard to estimate - as tasks may not even have an upper time limit. But in the majority of software development projects the tasks are trivial, and it is possible to enumerate all the little details and their dependencies. I was thinking of writing a tool to support the process instead of using excel, but unfortunately the dev has stalled due to lack of time on my part. https://github.com/andy-goryachev/ReqTraq https://github.com/andy-goryachev/ReqTraq
LyndsySimon 7y ago
> I think there is a way to give an estimate (have been doing it myself for a decade), even for dependencies that are not known from the start. I agree with this. The problem is that estimates vary, and that management teams often don't understand the way they vary. It's one thing if your estimates are precise and are generally accurate within 20%; it's another if your estimate is "it will likely take between six months and three years", and a third of the time the actual required time falls outside even that range. ... and yes, there are many projects for which such a large estimate wouldn't be unreasonable; nor would it be unreasonable for there to be unexpected breakthrough or challenges that significantly impact the timeline. > Is this something that HN audience is interested in? I can't speak for the community, but I think the only way you can know the answer to this question is to post it :)

cwyers 7y ago

Flip it around: it's really hard to budget, plan for staffing, make commitments, etc. without the ability to give estimates of this sort. The best thing to give yourself when giving estimates of a dificult sort is the freedom to be wrong, and the ability to express how confident you are in such an estimate.

Frost1x 7y ago

I'm the same way but only about 15 years experience. I have a friend recently retired who has done a wide variety of software development since the era of punch cards (at least 40 years development) and he agrees with me entirely. I'm not sure how people can provide any reasonable estimates, especially these days when technology is shifting even faster under your feet unless it's a clone of something you've already done in a specific set of technologies that haven't changed. For me, I simply make a very conservative guess and use a 2x or 2.5x multiplier to be safe. I'm usually far ahead of schedule but there have been occasions I as happy I added a 2.5x multiplier in. Everyone is typically happy... the fact is, my estimates are garbage.

vnorilo 7y ago
This is what I do! I disagree on 'garbage', though, I would say that you sound like you estimate very well, and that factor of 2.5 uncertainty is reasonable given all the unknowns in this line of work.
danmaz74 7y ago
Even those estimates are good for people who have no clue if something can take 2 weeks or 6 months. They're not garbage.
username90 7y ago
> Everyone is typically happy... the fact is, my estimates are garbage. If people are happy with your estimates then they are good estimates.

shados 7y ago

> Can we stop pretending we can forecast the unknown Within reason. Ive worked in orgs where there is no estimate at all, and that bring a different set of problems (unbound projects and no work getting done because of the complete lack of pressure). Now you're totally right: software engineers rarely do the same thing (or even similar things) twice, so estimating is somewhere between "very hard" and "impossible". "Scoping" however is still needed. If you ask me "How long will it take to add a button to this page", that's a very ambiguous question. I can solve the problem in a few ways: - Tack on a plain html button element - Add a button from an existing styleguide/library/design system. - Build our own button component instead of reusing one. - Build a full blown button editor that allows a non-software engineer to use a WYSIWYG editor that will create their own custom button and insert it on the page without code. Now obviously there's a range between these, going from a few seconds (plus deploy), to months or years of work. The project/product/whatever managers and the tech leads/engineers need to work together to agree on scope. An arbitrary deadline can be picked and then engineers have to do whatever they can up to that deadline. Or we can agree on minimum functionalities with onbound deadline that MUST be created regardless of how long it will take. Realistically, successful projects will be a mix of both, along with various forms of padding and revisiting estimates along the way to account for unknown and mistakes.

deleted 7y ago
[deleted]
jrs235 7y ago
> because of the complete lack of pressure I would say it may be due to more of a lack of focus.
avgDev 7y ago
I feel as you should be able to provide an estimate even if it something that you have not completely done before. One should spend some time to gauge how much of this new thing is really "new" and what parts should be easy to figure out. Then, try to look at resources about those unknown parts, and that should allow to provide a rough estimate. And when road blocks come up just communicate early, and then if PM/boss don't understand there is not much you can do but probably look for a better gig.

lowken10 7y ago

I just round up. If I get pressed I round up higher.

bfrydl 7y ago

There's a balance to it for sure. It sounds like estimation was taken far too seriously on your team if it was affecting you outside of work too. However, estimation is one of the primary skills of a software engineer. It's always hard to estimate well, but it's infinitely harder for a less technical person to do it for you. I think it's important to understand that and do one's best to improve at it over time.

Isamu 7y ago

>That's when I knew it was time to leave that team Currently in that situation. My "agile" estimate blew up by a factor of as much as 10, just because the ask was conceptually very simple, even to the domain experts I consulted. And by bad luck the way I was implementing the story it happened that the issues unfolded one-at-a-time, rather than somewhere in the beginning where we could have broken things up into more stories with additional time. I mean, it happens in engineering sometimes. We engineer our way out of it, and the engineering is solid in the end. But no, we blew up our story, so all that working nights and weekends to get back on track are for naught.

celticmusic 7y ago
why in the world would you ever use the end of a sprint as a hard deadline? That's broken from the get-go.
- Isamu 7y ago
  >That's broken from the get-go. Indeed.
- abawany 7y ago
  Broken, but very very common, IME. All of the agile-phile places that I have had the misfortune to interact with had things like sprint commitments, and etc. Very abusive and quite the opposite of 'people over process'.
rhizome 7y ago
>My "agile" estimate blew up by a factor of as much as 10, just because the ask was conceptually very simple Please do not feel bad, nor let anybody make you feel bad about this. It's absolutely natural for this to happen. If anything you could use it to ask for a junior or intern to delegate implementation details while you dig further into the coal mine of this feature. "Simple is hard." What you can learn from this (beyond team pushback) is what kinds of questions can be asked to figure out if a simple ask is masking 10 other things.
matwood 7y ago

matthewhartmans 7y ago

I think this is where a 'spike' solves your problem. By creating a spike, you can do some initial investigation into how the code is written, what's involved, how long it will take, etc. Once you have completed your spike, you can come back to the original piece of work and give a better estimate based on your findings.

eropple 7y ago
In the perfectly spherical Agile world, yes. In practice, for anything that's new, your project devolves into a set of spikes for development because your time-boxed investigation leaves unknown unknowns everywhere. Which is fine in that perfectly spherical Agile world, but it makes less-than-perfectly-spherical stakeholders very upset that they are not getting to use the Agile stick to beat over their developers' heads, as they have been trained to do.
dymk 7y ago
Maybe a spike takes a week. Maybe a spike takes an hour. I can't estimate that. Which would be fine, but then management or the PM expects me to loop back around when a spike is complete. I'd rather just continue engineering a solution when I'm done investigating, which is the natural progression of things. I'd rather treat {get requirements, investigate, implement, debug, deploy} as a single atomic task, rather than splitting it across N meetings for planning the sprint, planning the spike, meeting with the PM for more requirements they forgot to put in the user story, describing it at a retrospective, showing it at a demo. Now I know somebody will say "But that's now how agile works!". Well, we have a few agile "coaches" that were embedded in our teams who would disagree.
- nprateem 7y ago
  What are you doing in a spike? If you can't work out after a day the rough complexity of the task (bearing in mind you should be working on a small deliverable) there's something seriously wrong. You're not meant to be doing the work in the spike. If your research spike shows that it could be a can of worms, then the outcome of it should be another ticket for a proof-of-concept for another sprint, but with specific goals (e.g. "get a POC working that does X, Y & Z").

rhacker 7y ago

I know that kind of environment too. Usually some department head is a YES person, saying the delivery can be done in some timeframe X. Then timeframe X is told to the dev team and the dev team says X + 50 days. Then the dept. head goes back to the sales team and by that time it's too late. Then the entire organization pushes down on the dev team with fury. The product is of course released in X + 75. (because you always need to double or triple the dev team estimate) Those environments are toxic and the sign of toxicity is that the estimation process is not up for discussion (AKA the dept head keeps doing it again and again and no heads roll)

gesman 7y ago

Sometimes it's good to give people what they ask for [insist on], even if it does not make a sense. No anxiety needed. Then calmly explain that the reason things didn't work out as [they] expected is because in real world things doesn't work the way they want or fantasy about. Suggest better approach. If they refuse and keep doing [asking] the same thing all over again and expect a different result - then let it be their insanity [or anxiety], not yours.

jtolmar 7y ago

Most time estimates aren't necessary in the first place and it's aggravating that we need so many of them. Yes it's mostly a stick to beat devs with. But since folks reading this will probably need to make estimates anyway, this tends to be accurate: Estimate it'll take as long as the most recent similar thing you've done (real time, not heads down time). Resist the urge to trim out parts of the previous task that aren't related (you'll have new yak shaving) or related to mistakes you've learned not to make (you'll make new ones). If it's really different from anything previous, look for a time you had to learn something and implement a new system based on what you learned (you're allowed to be meta).

mdpopescu 7y ago
There's a problem with this. See JB Rainsberger's video: https://www.youtube.com/watch?v=WSes_PexXcA https://www.youtube.com/watch?v=WSes_PexXcA

xwdv 7y ago

No. Even bad estimates are better than no estimates. If you are having meltdowns your reputation is being tied too closely to your ability to give estimates. You must never turn estimates into a promise, always remind people they are estimates. Want to give fast estimates? Here’s how: 1) first determine the scale of the task? Is it a year, month, week or day kind of task? 2) Then, it’s just 3 of those units. The smallest task takes 3 days. One day to completely fuck up, one day to figure out why, one day to get right. The longest takes 3 years. One year to fuck it all up, one year to learn why, one year to finish it. I suggest never giving estimates in units smaller than a day. They just become noise. If a task is smaller than dayscale just say the task is too small to provide any meaningful estimate but won’t take more than a day.

deleted 7y ago
[deleted]
bb88 7y ago
> Even bad estimates are better than no estimates. No estimate is clearly better. Here's a common story I've seen across multiple companies. 1. Marketing management asks Engineering management how long it takes to do feature X so they know when to launch the online ad campaign. 2. Engineering management then asks potentially good coder how long it will take. Coder replies with a time and "it's just an estimate." 3. Engineering management reports to Marketing that coder's estimate leaving off the most important caveat, and Marketing treats that as the gospel truth. 4. Coder takes longer than expected because of some bad technical cruft that some other engineer put in because he was potentially rushed or just plain inept. 5. Marketing is pissed because they now have to withdraw the ad campaign, and starts blaming engineering. 6. Under increased scrutiny, Engineering gets a bad reputation, who then throws the coder under the bus in front of Marketing and other managers. 7. This shows up on the coder's annual review who then leaves. 8. Engineering hires replacement which will have a 3-6 month learning cycle, and potentially writes worse code than the person that just left. EDIT: The point is that if there's no estimate, management has to deal with the uncertainty that the coder experiences. Hope for the best, plan for the worst.
- 7y ago

nprateem 7y ago

> I still can't estimate how long something will take me when I've never done it before In that case you're meant to do a spike to research the issue. You can timebox the spike to half/whole a day. Then use that knowledge to help your estimation for the following sprint.

hector_vasquez 7y ago

Nobody in charge cares about the estimate of an individual task. They care about progress toward program goals. With experience and skill, estimation mistakes tend to come out in the wash.

agumonkey 7y ago

Probably lost 10 years due to that.

jen729w 7y ago

After many years in large infrastructure transformation projects, Johnny’s Rule of Threes now goes like this: 1. The first time you do something, you can guess how long it will take and what the detailed steps will be, but that is all. You should still plan it, but during execution of this phase you must take copious notes. Do not expect it to be correct. 2. After you have done something for the second time — using what you learned from the first time — you should end up with an accurate schedule. This schedule contains all of the steps required to do the thing along with accurate estimates of time and cost. 3. The third time you do the thing, you are able to do it to schedule and to budget.

nitely 7y ago
I can see how this would work for software boutiques doing fairly similar projects each time, or projects with very similar parts, but not in complex products. Much less for software that does not use any kind of framework or follows any kind of recipe. Sometimes it's just step 1 in a loop.

carlmr 7y ago

Use a random number generator to generate your estimates and slowly modify the mean until it matches expectations. I bet your estimates won't be as far off as your colleagues'.

allenu 7y ago

I agree. My theory now it's due the fractal nature of the tasks in software development. To design at a high level and break out the work, you have to make some assumptions about the ground-level designs (i.e. how individual components talk to each other). As you start implementing those, you'll have often encounter unexpected constraints that require you to rework the high-level design. As you progress through implementation, you find more and more tasks that need to be done and eventually the number of tasks generated levels off and starts to decay and it's only then that you really have an idea of how long you need (assuming no large bugs surprise you at that point). I find even heuristics like double your estimate or padding it aren't useful because there's so much variance.

matwood 7y ago

Estimates are like the cones of uncertainty NOAA publishes during hurricane season. A simple task I have done before is at the bottom of the cone. Possible complexity and unknowns push my estimates further out the cone. Less than a year, but more than 3 months is my standard answer for those random 'how long will this feature take' that I only have a vague idea about [0]. I then follow up asking if they would like to schedule a few weeks of research to close the cone a bit. The point is that you have to manage the person asking for the estimate. Teach them that unknowns means something could take a day or a month. I've only had one person really be a jerk about it, and my response was to make the estimate whatever they wanted. If they were not going to listen to me, then there was no point in giving an estimate at all. That response was from my younger, smart ass self though YMMV. [0] This also depends on what is being asked. How unknown are the unknowns? For example, is the feature clearly visible in another product?

snarfy 7y ago

You go to the mechanic and tell them your car won't start - nothing happens when you turn the key. You ask them how long it's going to take to fix and how much it will cost. They don't assume it's the starter and tell you it will be $400 for parts and labor. They tell you it will be $150 diagnostic fee and the diagnostic will take two hours. Then they call you and tell you the cost to fix and time it will take. For whatever reason, software engineers don't have the luxury of doing a diagnostic. We are made to guess up front and assume it's the starter, when we really have no idea what rat's nest is under the hood until we look.

disqard 7y ago
This was a good analogy!
theptip 7y ago
> software engineers don't have the luxury of doing a diagnostic These are called "spikes" in the agile community (no idea why), and "prototypes" elsewhere. If you feel that the error bars are too wide on your estimate, you should build the minimum prototype required to reduce the uncertainty to tolerable levels. I like to schedule these at least a sprint prior to kicking off the main task, so that you can benefit from the improved estimate accuracy when actually scheduling the thing.
rufflez 7y ago
Often, you think it is a car, and then when you start to work, you realize it is actually an octopus
- gilbetron 7y ago
  I love this comment! The analogy I've been using lately is that it's like estimating how long it will take to pack your kitchen when you are moving, except sometimes you open a cupboard door and there's another kitchen inside.
GFischer 7y ago
For whatever reason, software engineers don't have the luxury of doing a diagnostic. That´s not necessarily true. I´ve worked with very good, serious consultancies, and I´ve seen a quote for thousands of dollars for exploratory work to give an estimate. Of course that was for a million dollar project - smaller projects might not have this opportunity. Other companies had some interesting approaches where they gave order-of-magnitude estimates and then refined the estimate iteratively.

galaxyLogic 7y ago

I usually reply: Give me a week to look into it then I will have more insight into how long it might take. But you are right the problem is you can't estimate (correctly) how long it will take to do something your organization has never done before, that's what should be made clear to them. At the same time it is true that estimates get better as we start working on it, and the work can start by focusing on the unknowns to figure out how difficult they are to do. If that is a plan they agree to.

majikandy 7y ago

Spot on! I’ve also been developing software for over 20 years and my estimates have never improved. I think an order of magnitude is the only reasonably useful estimate, which can then feed into the question “is it worth doing it or not?”

ericmcer 7y ago

If you are a good engineer and a valuable member of the team people will know, whether you hit your estimates or not. It’s almost like the better you are at actually producing the less you need to worry about the red tape. If you are invaluable and crushing projects no sane manager is going to fire you over your estimate accuracy, but if you are doing poorly and not producing they may point to it as a problem area. I have only worked for small-mid size teams though so maybe it is not like that for huge ones.

deleted 7y ago

[deleted]

bsder 7y ago

> Can we stop pretending we can forecast the unknown? Except that you're wrong. We predict quite well, thanks. The problem is that everybody ignores the predictions. Most people predict approximately where the 50% probability is with maybe a little fudging. And they tend to be pretty good at it. The problem is that everybody just adds those up. And that's the disaster from a statistical viewpoint. Things can only come in so early, but they can come in infinitely late. A blown schedule on an early dependency throws everything out of whack far more than a late dependency would. We can roll these up in a proper way. We can run Monte Carlo simulations and get "real" numbers. People have done this and the results are remarkably accurate. The problem is that someone in management will always undercut the realistic estimate for personal gain. And then wind up longer than the estimate at the end. And, the worst part is that this is RATIONAL. The only way to get a project completed is to start and get the sunk-cost fallacy rolling in the powers-that-be.

tootie 7y ago

I just screamed this at someone (over IM, not really screaming) that estimates in scrum are meant to measure complexity and not time to completion. There are still people in 2019 saying things like "1 point is 1 day of work" and I want to murder them. The whole point of scrum is that time estimation is futile. Estimate complexity and then measure your velocity as tasks get completed and you can make a rough forecast of future velocity.

ChrisCinelli 7y ago

There are ways to get better at estimates. And a proper process will help you to do it. Unfortunately most of the orgs do not do it. 1) We know that "People are bad at estimates". That is why the estimate should come from the team (not one person in the team). Most of the orgs that I know do not do this. And to be honest they are not set up to do it because people in a team do not have overlapping skills. Ideally you have a team where people can take other people jobs (to a certain degree). You can then, during grooming, play "poker scrum" to estimate (where it is harder for people to cheat following what the lead person says). It is ok for somebody to say "I have no idea". The AVERAGE (not the MODE) is used for the estimation. If the items are more than 2 card apart have the 2 people at the extreme say why they think they think it takes the little amount of points and the other person why they think should take the large number of points. 2) If it is hard to agree on the estimation, the item probably needs to have a "spike" where more assessment or design is done in order to make clear what need to be done. In my team we also agree that a story has more than a certain number of points, we may say that it is too big and we have to break it down. 3) During retrospective or a specific meeting we have the team look at the time that an item really took and when it was more than 2 card off, try to understand what was under or over estimated. Usually after about 5 cycles, people start developing a sense of what the right amount of story point should be for a story. If you are always left by yourself at estimates and you never properly scope the task before and reflect on the variance afterward, it will be very hard to become good at estimations.

NullInvictus 7y ago

I've become convinced over the years that upper management doesn't really care about 'estimates'. What they care about 'commitments'. Every team I've been on has had upper management drive team leaders to get 'commitments'. They want some form of emotional investment in the work. That way, when scope has arbitrarily changed or a massive problem has lead to run over, they can stare at you like a whipped puppy-dog and say "I know it's 10PM and you want to get home to your wife, but you promised us, you committed, to getting this done on time..." Pure emotional exploitation. The ideals of agile are laudable. I was the excited bannerman of my first agile experience and I read the manifesto with a lot of hope. However high-minded agile is, the language is too easily co-oped into the worst sins of management. In many places it exists solely to blackmail free overtime out of engineers, get away with micro-management, and ride engineers with false deadlines under a guise of hipness and modernity. Estimates are just there for a false sense of stakeholding, or at best a ballpark cap so you don't work yourself into suicide. They can't be made accurately even if we could estimate properly, because all estimates are constantly second guessed by people who are making judgmental jokes about sandbagging, or asking "Are you really sure it'll take that long?" in voices that practically scream "chilling effect". More than a few possibly realistic estimates are torpedo'd by managers who are looking at their roadmap and tsking about how they don't line up. I would even say accurate estimates are actively undermined. I've worked at companies which have positive work images abroad, and even there any team which was on time found either its sprint budget slashed, or scope increased until it was forced behind. The underlings won't do over-time if they don't feel the squeeze. Story points, velocity, burndown, and any other metric you can think of that Agile courts are absolutely useless, because this industry refuses to come to terms with Goodhart's Law. I just watched a 10 million dollar project go up in flames. Their sprint graphs were great, and a constant buzz was going about the company about how these teams were setting the standard, meeting their metrics and goals consistently. Only recently did the CEO get down to business and figure out that all the metrics were bogus, and that for the past year all of the PMs and teams had been gaming the system to hide the fact that they were way behind schedule and over budget. The project was quietly scrapped and nothing changed. The shell games continue to actively sabotage data. I only know of the fallout because of who I sit next to. Most of the benefits of agile seem to fail basic contact with humans unless they are backed by outstanding and visionary leadership. Most companies do not have that, yet they still find value in switching to Agile. Why? Maybe because even in total collapse it provides an unparalleled system for squeezing out more overtime, in my cynical opinion anyways. I don't really what else to offer in place of Agile. I'm not that intelligent, but I don't really feel the industry can come up with a good development model of software development culture until it stops what it's doing and starts acknowledging problems arising from basic psychology, politics, and data gathering.