10 ms·

I can’t accurately estimate non-trivial software. I’ve never met anybody who can accurately estimate non-trivial software. I’ve never seen anybody claim to be

I can’t accurately estimate non-trivial software. I’ve never met anybody who can accurately estimate non-trivial software. I’ve never seen anybody claim to be able to accurately estimate non-trivial software. Yet for some reason people still insist that estimating non-trivial software is not only possible, but trivial.

drspacemonkey 7y ago
>Yet for some reason people still insist that estimating non-trivial software is not only possible, but trivial. It's always maddening to get into debates about this stuff with project managers who believe this nonsense. I know the Fibonacci point scale is supposed to address this by giving PMs something, but I've only ever seen it turn into time-estimates-by-proxy. These days, I only ever give estimates in terms of time scale. A task will take "hours", "days", "weeks", or "months". As long as it's within my power, my team will only ever estimate on that scale.
- wikiman 7y ago
  This 100% this. I run my teams via "Kanban" (I don't know how kanban it actually is, but that's what I call it). The only question I ask around prioritization is "Is it worth doing?" If the answer is yes, I ask the stakeholder if they care how long it takes. If they do, I ask for a range and give a best estimate if it's achievable. If the answer is no, I ask why they care how long it takes if it's the most important thing to do. My engineers know that they're expected to do that one project to completion, and we loop in other stakeholders (marketing, sales, QA, etc) progressively as we approach completion. Admittedly I work at a company of 20, but it works remarkably well, despite the absence of a "schedule"
  - edgarvaldes 7y ago
    > don't know how kanban it actually is, but that's what I call it We also work with a Kanban-like methodology. Basically a pull system with a hard limit on WIP.
  - thaumasiotes 7y ago
    > If the answer is no, I ask why they care how long it takes if it's the most important thing to do. Well... would you rather get $150,000 two years from now, or $90,000 next month? You generally don't want to be making any decisions off ordinal comparisons.
  - conradfr 7y ago
    You meet the PM/PO. They want to do Scrum, standups, retros, grooming, poker planning the whole thing. Ask them to prioritize the tickets. Maybe they want some rough estimate to decide between some of them, maybe not (which is, suprisingly, in most case). During the same meeting you can groom the tickets. The developers then start working on those tasks, when they are ready you release them according to your company policy and calendar. By then everyone have forgotten about Scrum, management is amazed you release so much stuff, you can probably put all that in a one hour max weekly team meeting and everyone is happy. I'm pretty sure that's applicable in a lot of pure player tech teams and quite scalable (I managed up to a 15 devs team this way but PR validation etc overtook the management part a bit much).
  - turk73 7y ago
    Wow, I wish the Fortune 10 company I work for had this kind of insight! The "agile" process I work under is causing horrible outcomes. It's basically a sweat shop operation is what it really is. I'm a tech lead and am always fielding questions like "why did this take so long?" It took so long because there was unexpected difficult A, B, and C, two of the four guys on team are mid-level devs and not senior level, and so I worked a third night this week to try and pull this off. The sprint plan never makes it past 1-2 days each sprint and then I catch a bunch of righteous indignation with phrases like "you committed to this" and crap like that. "Why can't we better estimate these things?" Because when I give honest estimates I get threatened by my boss. Your process is not reality driven. "Can we break this work down into smaller stories?" No, I can't break down the final integration of all the parts into a smaller story. Or more commonly, they told me we have "too many stories" and can't keep track of them all when we break them apart. The best is when a Product Owner or other business type says "I'm not a technical person." Then why the hell are you working in a such technical business and calling the shots on stuff you don't even understand?
- cocoa19 7y ago
  Most maddening thing I've seen is PM translating agile points to man-hours because that's what upper management requests. Same people: you must complete assignments in the estimated time, or else, be prepared to work overtime including weekends. It drives me bonkers.
  - metamet 7y ago
    Quarterly planning is equally frustrating. I don't think we've ever had a quarter where we're on track three sprints in. Something always comes up, we pivot a bit, or our estimates were as uninformative as we all thought they were.
  - k_ 7y ago
    I had that too. Also they were negotiating down every last estimate while we were doing "planning poker" which was only a façade and was really us committing to unrealistic man-hours estimates unwillingly.
    - meheleventyone 7y ago
      Or you get someone very senior in the company who rocks up in your planning meeting demanding to know the “real estimate”.
      - Aeolun 7y ago
        The real estimate is ‘as long as it takes’.
  - BurningFrog 7y ago
    We have a great labor market. Don't be shy about quitting when things get cray-cray!
    - godzilla82 7y ago
      By we do you mean software engineering in general or bay area? Asking because most people commenting on hn tend to assume the entire universe is just the sf bay area.
- xky 7y ago
  Similar but I’ll ask for a range which has a built in confidence level. A lot of developers are very reluctant to give estimates for various reasons but if the reason is that they don’t know where to start, I’ll do a thought experiment with them. I ask first will the task take 20 years to finish and they usually laugh and say of course not. Then I ask what about 20 seconds and they laugh again. We keep going on both sides of the boundary until they stop laughing and it starts sounding more reasonable. Then I have something to work with like 3 to 6 months which gives me more options. I can accept the risk or I can take other steps to reduce it or break it into more manageable bites. It’s not perfect but it’s worked pretty well.
danpalmer 7y ago
The trick is to break it down until it’s all trivial. That process takes time itself, but you can estimate that much more easily. I’ve recently found I end up giving an estimate of, say, 2 days to get a solid estimate, and then come away from that with 2-5 weeks of tasks that are no more than a day each. Estimates of a day are pretty accurate (for me). Another approach I had some success with was estimating the 80% likelihood case, I.e. I’m 80% sure I can finish this in the time I’m estimating. Less accurate, but much more predictably on schedule, which is more useful for many stakeholders. A last one is giving rough estimates and being clear about how rough they are and how much time it will take to get more confidence. I was handed a 50 page PDF of API docs for a service and asked what the estimate was for integration. After 15 minutes I said “1-4 weeks”, if you want more accuracy then I’ll need a few days. The answer was “no problem, we wouldn’t consider it unless it was < 1 week”. These examples are all on the weeks to low number of months scale, but the same applies further up. Having a good understanding of the codebase and domain are very useful. Estimating isn’t easy, but treat it like any skill, it can be improved. It requires some flexibility from product managers, but open communication goes a really long way and results in better decisions overall, less wasted effort.
- henryfjordan 7y ago
  You cannot, by definition, break down a non-trivial project into trivial parts without having at least 1 non-trivial part in there somewhere
  - thijsvandien 7y ago
    The non-trivial part might be combining the trivial parts. :)
    - wvenable 7y ago
      This is a good point and something probably not caught in the estimation of the smaller trivial parts.
      - 7y ago
edoo 7y ago
I do pretty well at it. My method is to identify all the components of a system and individually assign how many days I think I could do it in if I was really motivated. Then multiply by about 2-3 depending on your experience implementing previously similar modules. Then multiply by 2. I usually end up with a conservative time estimate where some things take longer and some shorter but overall it generally works. On this project that approach would have been... i can do it 3 weeks, give myself 6, and double it = 12. People love it when you come in at or under estimated time and really don't like it when you are late. Give yourself a buffer.
- twothamendment 7y ago
  That is pretty close to how I do it and I'm not the only one who thinks I'm good at it. This only works on a stack and team that I'm familiar with. It works with projects that are days, weeks or a year long. If you can't break it down you don't understand it and if you don't understand it you aren't ready to estimate it.
- r41nbowdash 7y ago
  i ran analysis on our codebase, most of the files had 40% rewrites, with some outliers being 90% rewritten. the file sizes followed linear distribution, usually from 100 to 2000 lines of code. when the 90% rewrite hit a larger files, it accounted for almost 50% of total effort put into development. what i got from this, for a single component i take the ideal estimate then multiple it x2, and do the same x2 project wide. there's additional friction when integrating outside components, but i'm rarely blamed for it, so i don't care that much to put it in estimates. now the hard part is selling the idea to the management, like "here are our ideal estimates, lets multiply it by 4". when doing freelance work i usually bill for the ideal estimated time multiplied by 2, the rest being my risk, on the other hand any changes in the requirements, or miscommunication is a risk of the client.
davnicwil 7y ago
OP here - it's just (somehow, repeatedly) surprising the magnitude to which you can be wrong, even when it's just you and there's no pressure from anyone else to get it done quickly and it's really just an honest guess. I see this over and over again with people I know bootstrapping projects - the over optimism I think is just part of being a builder. Sometimes in startup circles there seems to be this meme of how you should 'throw together a prototype of the tech in a week' being the standard way to get going with an idea. In practice though, seems so impossible that you could get anything even useful shaped built in that amount of time. For me when I get down to work on something, even just plumbing together the vague structure of an app takes longer than a week full time.
- iainmerrick 7y ago
  Have you tried to track data for multiple projects? For the specific case you wrote up, is the lesson simply “multiply my estimate by 4 next time”?
a_wild_dandan 7y ago
I think this is due to people adhering to a bad implicit analogy: "Estimating software construction projects must be like estimating other types of construction projects, e.g. bridges or cars." The problem is that most software projects don't have a myriad near-identical existing solutions from which to source a project's duration. We aren't making a building with the exact same floor plan, using the exact same crew size with the exact same skills, in the exact same regions, using...You get the point. It's just a bad comparison. Most software projects are more like R&D than construction. For the adventurous analogy, software is like hiking an unknown trail. You might generally know where you're going, but you can't foresee the river, detours, and feral hogs you'll have to battle to reach the end. You simply can't estimate software the way you can more tangible products. You can do Scrum planning poker and pretend your're not playing Numberwang, if that makes you feel more in control.
- wvenable 7y ago
  Construction projects have detailed blueprints used to construct the estimate. Developing the blueprints is much more like developing software and probably has similar issues with estimating the time it takes, effort, etc. But nobody ever compares that. There is no construction phase in software (except compiling); the entire project is the planning stage.
  - meheleventyone 7y ago
    I also think this comparison is made by people that have never been involved in construction projects. Even something reasonably small in scope like rebuilding a house is still an exploratory process. Redoing ours we found the frame was no good and had to go back to get planning permission to build a new top structure. Even now we're getting our lower outer wall repaired (basically the only part of the structure that's actually original now) and the initial cleaning showed there was more work involved. So we renegotiated the cost with the builder. Then you look at big civil engineering projects that seem to always be over-time and over-budget. The treatment of estimates in project management for software is way more like the assumption we have an assembly line where even if there are issues these are routine enough that they can be padded in. The problem is that software is an exploratory process and not an assembly line. It's even worse the more creative the project is. I've worked in games for fifteen years and I don't think it's possible to estimate when a game will be 'good'. Making one is a process that requires a lot of feedback, iteration and scope management. It's part of why we see so much reflexive crunch as the reality of making a game hits poor project management strategy based on this assembly line thinking. The words Gantt chart make me shudder.
pas 7y ago
Estimation needs a baseline. Predicting the time needed for a greenfield (from scratch) project without some experience working on that project with a fixed team ... will lead to misery.
seph-reed 7y ago
It's magic, but I'm actually pretty good at it. Pretty much every time I'll say the number, my boss will be unhappy and get me to say a lesser number, then it'll be what I predicted. I have a method, but I'm pretty sure it's just magic.
eyegor 7y ago
I find I can "accurately" estimate it by estimating the time for each major feature, and then tripling that number. Typically I ship ahead of schedule, even with glitch ups. Of course if you're in uncharted territory you should spend more time making sure your funding is secured regardless of ship date. Nothing worse than having the rug pulled out beneath you one day.
drawkbox 7y ago
There is also too much given to the importance of hitting the date over hitting the product/market polish, value and fit needed for success. People forget a project was late if it succeeds, they never forget a project on time that failed because it was rushed, buggy and not polished production. Discipline and time estimates are important, but not more important than a product setup for success. One that is easy to sell and market because it has value, is polished and a good experience. Game development notoriously is late, and as long as the developers have time to finish it right people forget. Everyone knows when a game company and the business/marketing/financial side pushes out an incomplete or buggy product, it can permanently harm perception. Valve Time is something that is really common game development where engineers/developers/designers/product people are still in charge and making good solid product. [1] Technology, innovation and especially game development needs time to make it fun, a good experience and a solid product. Creativity can't always be rushed, there must be "open" and "closed" modes of development, not crunched in "closed" only modes. John Cleese has an excellent talk on managing creativity and I recommend all people I work with watch it, very valuable insight. [2] [1] https://developer.valvesoftware.com/wiki/Valve_Time https://developer.valvesoftware.com/wiki/Valve_Time [2] https://www.youtube.com/watch?v=Pb5oIIPO62g https://www.youtube.com/watch?v=Pb5oIIPO62g
jammygit 7y ago
How do you do estimates for contract jobs then? Clients are very uncomfortable when you say “between X and 3X weeks”
- meh2frdf 7y ago
  Often it’s the assumptions that go into an estimate that are critical, and defining them along with the estimate. Often it’s problem and delays at the client side that delays things or makes them harder.
buzzkillington 7y ago
I can. Do your estimation normally. If you've done it a dozen times multiply by sqrt(pi), if you've done it a couple of times multiply by pi, if you've never done it before multiply by pi^2. I'm not off by more than 20%.
- jacobolus 7y ago
  Your heuristic that someone who has done a dozen previous software estimates will not take more than 177% of their current estimate to finish a “non-trivial software” project seems wildly optimistic to me. Consider that many software projects led by experienced software engineers go so far over time that they are never finished.
  - buzzkillington 7y ago
    No, that's category 3, pi^2, or roughly 10 times the estimate. Category 1 is >I've written a script to get the data from tables 1 to 24 of this database, now I need to write one for table 25. It should take me an hour. >Oh look, it took me nearly 2 hours because I forgot that table is owned by a different user to all the other ones and I didn't have the right permissions.
    - jacobolus 7y ago
      So to clarify: what the top-level poster here is calling “non-trivial” you are calling “category 3”, and heuristically estimating that it will take 10x longer than anticipated. But this (a) is still quite optimistic, and (b) ignores variance. The potential time a new research project could take is unbounded.
      - meheleventyone 7y ago
        Yup, padding estimates is akin to what you might do if you had a repeatable process but there was some predictable variance (e.g. illness, machinery maintenance, holidays) rather than a bunch of unknown and exploratory problem solving.
dboreham 7y ago
Deluded people are everywhere.
mathgladiator 7y ago
I do it well, but only after I completely understand the problem. For instance, I wrote out a series of design documents, then gathered buy in for management to start hiring. I told them that this will take 2 years to complete, but we can start realizing value in the first six months. Every timeframe was hit without crunch, and everything landed roughly on schedule. The problem is that most people I've met dont really understand what they are actually doing and/or have the leadership to grow people to achieve. It is not trivial in the least and requires a great deal of lead time to even understand the problem(s). This field is at its infancy, and I dont yet know if my insights can be replicated yet. I'm thinking of writing a book where I illustrate thought exercises and career challenges that help people grow from junior to senior principal, but it is proving difficult.
- jdc 7y ago
  How long does it take to understand the problem and write design documents?
  - mathgladiator 7y ago
    3 to 6 months... maybe longer. The key is to focus that time towards collecting data to help sell to stakeholders.
  - commandlinefan 7y ago
    According to every project manager/“agile coach” I’ve ever worked with, that would be part of a one-hour “grooming meeting” and if it takes longer than that, you must just be an incompetent developer, in need of more “coaching”.
- generatorguy 7y ago
  Isn’t The hard part understanding the problem and writing the design documents? That is the task which takes the unknown amount of time. Once the roadmap is in place and people are assigned to build the things that have been designed the problems that occur are much more concrete. Unless there is some oversight or omission in the design, change in the requirements. Etc. How long was the discovery and design document phase on the 2 year project?
tomelders 7y ago
Developers are optimists.
mc3 7y ago
I feel that to get accurate estimates you need the same people using the same tech stacks producing roughly the same solutions week in and week out. I imagine something like making slightly interactive marketing sites using Ruby on Rails every time, Active record every time, etc. These estimates will be perfect. On the other hand, for a complex SaaS back end and front end doing something unique, a complex system to which you are being asked to add something groundbreaking, where you need to pay off various tech debt as you go in order to get the job done, where you are negotiating the requirements as you go along, and finding dead ends and impossible things that you can't do that you thought were simple and vice versa - I think it is hard to estimate. I think in that case estimation is a waste of time and it should be thought of like a "value train". If there is a genuine deadline (rocket launch) then best to manage it well with appropriate large buffers and dependency management. I don't see this being done anywhere, it is usually the business trying to haggle down the engineers on their estimates (even though the engineers are paid a salary so ???).
- markburns 7y ago
  The issue with this is that if you’re doing cookie cutter websites. At some point it’s going to be more efficient to abstract out the shared functionality and build a framework of some sort. You’ll become more efficient but you’ll either lose predictability or you’ll just be padding estimates to whatever you were estimating before. Not a bad position to be in but you’ll always be somewhere between predictable and inefficient or efficient and unpredictable.
paggle 7y ago
Many people have the ability to estimate non trivial software, given the number of software products which ship on a schedule and don’t slip. Things like features announced at big conferences. Granted, the companies that do this can add people to projects as necessary, so they can work with months rather than man-months.
paggle 7y ago
The much-derided “execs” who demand time estimates don’t do so out of spite. They do so because their costs are measured in man-months, and a business needs to know how much something is going to cost to decide whether it’s worth building. Also, they may have partner companies who they need to coordinate timelines with. I’d guess that freelance developers who are paid per project, and thus have to own their P&L, are very good at estimating.
- jdlshore 7y ago
  I don't know about freelancers, but typical fixed-bid RFP responses are lowballed in order to get the work, then they make their profit on the inevitable change requests. So accurate estimates aren't as important as you might think.
navinsylvester 7y ago
Its hard to estimate without breaking it down to smaller tasks and this process is laborious. This process assumes we are tackling stuff in which we already have expertise. The rule of thumb i use - anything which takes more than 3 days needs to be broken down further into tasks. If any task takes more than 3 days during execution then it needs to be broken down to more tasks.
teddyuk 7y ago
I was taught it takes about a quarter of the time to estimate work so if you think it will take 1 day you should have spent 1/4 day estimating. If you think 4 weeks then 1 week estimating. Whenever I’m asked to estimate I tell them that I’ll take a week to estimate a 4 week piece of work they almost always say don’t bother - then when the made up estimates are wrong we can discuss the fact that they didn’t bother estimating. It is a funny thing but works every time (in corps).
username90 7y ago
It is possible that a project is non-trivial to you but trivial to someone else, then that someone else could properly estimate it. Also most software projects are trivial so I don't see why estimations would be impossible, it is not like your typical react app is going to push boundaries on research topics. They might push boundaries to mediocre developers though, in which case it is a non-trivial project for them. I think the real reason estimations are hard is that basically every developer is working on projects too hard for them. Like, if you are so good at your current job that you can reliably churn out good solutions with ease then instead of just producing you would move on to do harder things for better pay.
Aeolun 7y ago
Estimating non-trivial software is easy. Making those estimates any kind of accurate is the problem. I was talking with my project manager today, and he was asking me if we could finish on time if we got twice as much time as I estimated. My reply was that we’ve tried that 4 times now, and we’ve never reached the point where we actually finish within the time estimated. So increasing the time would just mean we fail later, not that we suddenly succeed. I’m firmly starting to believe that work expands to fill the time allocated to it.

drspacemonkey 7y ago

>Yet for some reason people still insist that estimating non-trivial software is not only possible, but trivial. It's always maddening to get into debates about this stuff with project managers who believe this nonsense. I know the Fibonacci point scale is supposed to address this by giving PMs something, but I've only ever seen it turn into time-estimates-by-proxy. These days, I only ever give estimates in terms of time scale. A task will take "hours", "days", "weeks", or "months". As long as it's within my power, my team will only ever estimate on that scale.

wikiman 7y ago
This 100% this. I run my teams via "Kanban" (I don't know how kanban it actually is, but that's what I call it). The only question I ask around prioritization is "Is it worth doing?" If the answer is yes, I ask the stakeholder if they care how long it takes. If they do, I ask for a range and give a best estimate if it's achievable. If the answer is no, I ask why they care how long it takes if it's the most important thing to do. My engineers know that they're expected to do that one project to completion, and we loop in other stakeholders (marketing, sales, QA, etc) progressively as we approach completion. Admittedly I work at a company of 20, but it works remarkably well, despite the absence of a "schedule"
- edgarvaldes 7y ago
  > don't know how kanban it actually is, but that's what I call it We also work with a Kanban-like methodology. Basically a pull system with a hard limit on WIP.
- thaumasiotes 7y ago
  > If the answer is no, I ask why they care how long it takes if it's the most important thing to do. Well... would you rather get $150,000 two years from now, or $90,000 next month? You generally don't want to be making any decisions off ordinal comparisons.
- conradfr 7y ago
  You meet the PM/PO. They want to do Scrum, standups, retros, grooming, poker planning the whole thing. Ask them to prioritize the tickets. Maybe they want some rough estimate to decide between some of them, maybe not (which is, suprisingly, in most case). During the same meeting you can groom the tickets. The developers then start working on those tasks, when they are ready you release them according to your company policy and calendar. By then everyone have forgotten about Scrum, management is amazed you release so much stuff, you can probably put all that in a one hour max weekly team meeting and everyone is happy. I'm pretty sure that's applicable in a lot of pure player tech teams and quite scalable (I managed up to a 15 devs team this way but PR validation etc overtook the management part a bit much).
- turk73 7y ago
  Wow, I wish the Fortune 10 company I work for had this kind of insight! The "agile" process I work under is causing horrible outcomes. It's basically a sweat shop operation is what it really is. I'm a tech lead and am always fielding questions like "why did this take so long?" It took so long because there was unexpected difficult A, B, and C, two of the four guys on team are mid-level devs and not senior level, and so I worked a third night this week to try and pull this off. The sprint plan never makes it past 1-2 days each sprint and then I catch a bunch of righteous indignation with phrases like "you committed to this" and crap like that. "Why can't we better estimate these things?" Because when I give honest estimates I get threatened by my boss. Your process is not reality driven. "Can we break this work down into smaller stories?" No, I can't break down the final integration of all the parts into a smaller story. Or more commonly, they told me we have "too many stories" and can't keep track of them all when we break them apart. The best is when a Product Owner or other business type says "I'm not a technical person." Then why the hell are you working in a such technical business and calling the shots on stuff you don't even understand?
cocoa19 7y ago
Most maddening thing I've seen is PM translating agile points to man-hours because that's what upper management requests. Same people: you must complete assignments in the estimated time, or else, be prepared to work overtime including weekends. It drives me bonkers.
- metamet 7y ago
  Quarterly planning is equally frustrating. I don't think we've ever had a quarter where we're on track three sprints in. Something always comes up, we pivot a bit, or our estimates were as uninformative as we all thought they were.
- k_ 7y ago
  I had that too. Also they were negotiating down every last estimate while we were doing "planning poker" which was only a façade and was really us committing to unrealistic man-hours estimates unwillingly.
  - meheleventyone 7y ago
    Or you get someone very senior in the company who rocks up in your planning meeting demanding to know the “real estimate”.
    - Aeolun 7y ago
      The real estimate is ‘as long as it takes’.
- BurningFrog 7y ago
  We have a great labor market. Don't be shy about quitting when things get cray-cray!
  - godzilla82 7y ago
    By we do you mean software engineering in general or bay area? Asking because most people commenting on hn tend to assume the entire universe is just the sf bay area.
xky 7y ago
Similar but I’ll ask for a range which has a built in confidence level. A lot of developers are very reluctant to give estimates for various reasons but if the reason is that they don’t know where to start, I’ll do a thought experiment with them. I ask first will the task take 20 years to finish and they usually laugh and say of course not. Then I ask what about 20 seconds and they laugh again. We keep going on both sides of the boundary until they stop laughing and it starts sounding more reasonable. Then I have something to work with like 3 to 6 months which gives me more options. I can accept the risk or I can take other steps to reduce it or break it into more manageable bites. It’s not perfect but it’s worked pretty well.

danpalmer 7y ago

The trick is to break it down until it’s all trivial. That process takes time itself, but you can estimate that much more easily. I’ve recently found I end up giving an estimate of, say, 2 days to get a solid estimate, and then come away from that with 2-5 weeks of tasks that are no more than a day each. Estimates of a day are pretty accurate (for me). Another approach I had some success with was estimating the 80% likelihood case, I.e. I’m 80% sure I can finish this in the time I’m estimating. Less accurate, but much more predictably on schedule, which is more useful for many stakeholders. A last one is giving rough estimates and being clear about how rough they are and how much time it will take to get more confidence. I was handed a 50 page PDF of API docs for a service and asked what the estimate was for integration. After 15 minutes I said “1-4 weeks”, if you want more accuracy then I’ll need a few days. The answer was “no problem, we wouldn’t consider it unless it was < 1 week”. These examples are all on the weeks to low number of months scale, but the same applies further up. Having a good understanding of the codebase and domain are very useful. Estimating isn’t easy, but treat it like any skill, it can be improved. It requires some flexibility from product managers, but open communication goes a really long way and results in better decisions overall, less wasted effort.

henryfjordan 7y ago
You cannot, by definition, break down a non-trivial project into trivial parts without having at least 1 non-trivial part in there somewhere
- thijsvandien 7y ago
  The non-trivial part might be combining the trivial parts. :)
  - wvenable 7y ago
    This is a good point and something probably not caught in the estimation of the smaller trivial parts.
    - 7y ago

edoo 7y ago

I do pretty well at it. My method is to identify all the components of a system and individually assign how many days I think I could do it in if I was really motivated. Then multiply by about 2-3 depending on your experience implementing previously similar modules. Then multiply by 2. I usually end up with a conservative time estimate where some things take longer and some shorter but overall it generally works. On this project that approach would have been... i can do it 3 weeks, give myself 6, and double it = 12. People love it when you come in at or under estimated time and really don't like it when you are late. Give yourself a buffer.

twothamendment 7y ago
That is pretty close to how I do it and I'm not the only one who thinks I'm good at it. This only works on a stack and team that I'm familiar with. It works with projects that are days, weeks or a year long. If you can't break it down you don't understand it and if you don't understand it you aren't ready to estimate it.
r41nbowdash 7y ago
i ran analysis on our codebase, most of the files had 40% rewrites, with some outliers being 90% rewritten. the file sizes followed linear distribution, usually from 100 to 2000 lines of code. when the 90% rewrite hit a larger files, it accounted for almost 50% of total effort put into development. what i got from this, for a single component i take the ideal estimate then multiple it x2, and do the same x2 project wide. there's additional friction when integrating outside components, but i'm rarely blamed for it, so i don't care that much to put it in estimates. now the hard part is selling the idea to the management, like "here are our ideal estimates, lets multiply it by 4". when doing freelance work i usually bill for the ideal estimated time multiplied by 2, the rest being my risk, on the other hand any changes in the requirements, or miscommunication is a risk of the client.

davnicwil 7y ago

OP here - it's just (somehow, repeatedly) surprising the magnitude to which you can be wrong, even when it's just you and there's no pressure from anyone else to get it done quickly and it's really just an honest guess. I see this over and over again with people I know bootstrapping projects - the over optimism I think is just part of being a builder. Sometimes in startup circles there seems to be this meme of how you should 'throw together a prototype of the tech in a week' being the standard way to get going with an idea. In practice though, seems so impossible that you could get anything even useful shaped built in that amount of time. For me when I get down to work on something, even just plumbing together the vague structure of an app takes longer than a week full time.

iainmerrick 7y ago
Have you tried to track data for multiple projects? For the specific case you wrote up, is the lesson simply “multiply my estimate by 4 next time”?

a_wild_dandan 7y ago

I think this is due to people adhering to a bad implicit analogy: "Estimating software construction projects must be like estimating other types of construction projects, e.g. bridges or cars." The problem is that most software projects don't have a myriad near-identical existing solutions from which to source a project's duration. We aren't making a building with the exact same floor plan, using the exact same crew size with the exact same skills, in the exact same regions, using...You get the point. It's just a bad comparison. Most software projects are more like R&D than construction. For the adventurous analogy, software is like hiking an unknown trail. You might generally know where you're going, but you can't foresee the river, detours, and feral hogs you'll have to battle to reach the end. You simply can't estimate software the way you can more tangible products. You can do Scrum planning poker and pretend your're not playing Numberwang, if that makes you feel more in control.

wvenable 7y ago
Construction projects have detailed blueprints used to construct the estimate. Developing the blueprints is much more like developing software and probably has similar issues with estimating the time it takes, effort, etc. But nobody ever compares that. There is no construction phase in software (except compiling); the entire project is the planning stage.
- meheleventyone 7y ago
  I also think this comparison is made by people that have never been involved in construction projects. Even something reasonably small in scope like rebuilding a house is still an exploratory process. Redoing ours we found the frame was no good and had to go back to get planning permission to build a new top structure. Even now we're getting our lower outer wall repaired (basically the only part of the structure that's actually original now) and the initial cleaning showed there was more work involved. So we renegotiated the cost with the builder. Then you look at big civil engineering projects that seem to always be over-time and over-budget. The treatment of estimates in project management for software is way more like the assumption we have an assembly line where even if there are issues these are routine enough that they can be padded in. The problem is that software is an exploratory process and not an assembly line. It's even worse the more creative the project is. I've worked in games for fifteen years and I don't think it's possible to estimate when a game will be 'good'. Making one is a process that requires a lot of feedback, iteration and scope management. It's part of why we see so much reflexive crunch as the reality of making a game hits poor project management strategy based on this assembly line thinking. The words Gantt chart make me shudder.

pas 7y ago

Estimation needs a baseline. Predicting the time needed for a greenfield (from scratch) project without some experience working on that project with a fixed team ... will lead to misery.

seph-reed 7y ago

It's magic, but I'm actually pretty good at it. Pretty much every time I'll say the number, my boss will be unhappy and get me to say a lesser number, then it'll be what I predicted. I have a method, but I'm pretty sure it's just magic.

eyegor 7y ago

I find I can "accurately" estimate it by estimating the time for each major feature, and then tripling that number. Typically I ship ahead of schedule, even with glitch ups. Of course if you're in uncharted territory you should spend more time making sure your funding is secured regardless of ship date. Nothing worse than having the rug pulled out beneath you one day.

drawkbox 7y ago

There is also too much given to the importance of hitting the date over hitting the product/market polish, value and fit needed for success. People forget a project was late if it succeeds, they never forget a project on time that failed because it was rushed, buggy and not polished production. Discipline and time estimates are important, but not more important than a product setup for success. One that is easy to sell and market because it has value, is polished and a good experience. Game development notoriously is late, and as long as the developers have time to finish it right people forget. Everyone knows when a game company and the business/marketing/financial side pushes out an incomplete or buggy product, it can permanently harm perception. Valve Time is something that is really common game development where engineers/developers/designers/product people are still in charge and making good solid product. [1] Technology, innovation and especially game development needs time to make it fun, a good experience and a solid product. Creativity can't always be rushed, there must be "open" and "closed" modes of development, not crunched in "closed" only modes. John Cleese has an excellent talk on managing creativity and I recommend all people I work with watch it, very valuable insight. [2] [1] https://developer.valvesoftware.com/wiki/Valve_Time https://developer.valvesoftware.com/wiki/Valve_Time [2] https://www.youtube.com/watch?v=Pb5oIIPO62g https://www.youtube.com/watch?v=Pb5oIIPO62g

jammygit 7y ago

How do you do estimates for contract jobs then? Clients are very uncomfortable when you say “between X and 3X weeks”

meh2frdf 7y ago
Often it’s the assumptions that go into an estimate that are critical, and defining them along with the estimate. Often it’s problem and delays at the client side that delays things or makes them harder.

buzzkillington 7y ago

I can. Do your estimation normally. If you've done it a dozen times multiply by sqrt(pi), if you've done it a couple of times multiply by pi, if you've never done it before multiply by pi^2. I'm not off by more than 20%.

jacobolus 7y ago
Your heuristic that someone who has done a dozen previous software estimates will not take more than 177% of their current estimate to finish a “non-trivial software” project seems wildly optimistic to me. Consider that many software projects led by experienced software engineers go so far over time that they are never finished.
- buzzkillington 7y ago
  No, that's category 3, pi^2, or roughly 10 times the estimate. Category 1 is >I've written a script to get the data from tables 1 to 24 of this database, now I need to write one for table 25. It should take me an hour. >Oh look, it took me nearly 2 hours because I forgot that table is owned by a different user to all the other ones and I didn't have the right permissions.
  - jacobolus 7y ago
    So to clarify: what the top-level poster here is calling “non-trivial” you are calling “category 3”, and heuristically estimating that it will take 10x longer than anticipated. But this (a) is still quite optimistic, and (b) ignores variance. The potential time a new research project could take is unbounded.
    - meheleventyone 7y ago
      Yup, padding estimates is akin to what you might do if you had a repeatable process but there was some predictable variance (e.g. illness, machinery maintenance, holidays) rather than a bunch of unknown and exploratory problem solving.

dboreham 7y ago

Deluded people are everywhere.

mathgladiator 7y ago

I do it well, but only after I completely understand the problem. For instance, I wrote out a series of design documents, then gathered buy in for management to start hiring. I told them that this will take 2 years to complete, but we can start realizing value in the first six months. Every timeframe was hit without crunch, and everything landed roughly on schedule. The problem is that most people I've met dont really understand what they are actually doing and/or have the leadership to grow people to achieve. It is not trivial in the least and requires a great deal of lead time to even understand the problem(s). This field is at its infancy, and I dont yet know if my insights can be replicated yet. I'm thinking of writing a book where I illustrate thought exercises and career challenges that help people grow from junior to senior principal, but it is proving difficult.

jdc 7y ago
How long does it take to understand the problem and write design documents?
- mathgladiator 7y ago
  3 to 6 months... maybe longer. The key is to focus that time towards collecting data to help sell to stakeholders.
- commandlinefan 7y ago
  According to every project manager/“agile coach” I’ve ever worked with, that would be part of a one-hour “grooming meeting” and if it takes longer than that, you must just be an incompetent developer, in need of more “coaching”.
generatorguy 7y ago
Isn’t The hard part understanding the problem and writing the design documents? That is the task which takes the unknown amount of time. Once the roadmap is in place and people are assigned to build the things that have been designed the problems that occur are much more concrete. Unless there is some oversight or omission in the design, change in the requirements. Etc. How long was the discovery and design document phase on the 2 year project?

tomelders 7y ago

Developers are optimists.

mc3 7y ago

I feel that to get accurate estimates you need the same people using the same tech stacks producing roughly the same solutions week in and week out. I imagine something like making slightly interactive marketing sites using Ruby on Rails every time, Active record every time, etc. These estimates will be perfect. On the other hand, for a complex SaaS back end and front end doing something unique, a complex system to which you are being asked to add something groundbreaking, where you need to pay off various tech debt as you go in order to get the job done, where you are negotiating the requirements as you go along, and finding dead ends and impossible things that you can't do that you thought were simple and vice versa - I think it is hard to estimate. I think in that case estimation is a waste of time and it should be thought of like a "value train". If there is a genuine deadline (rocket launch) then best to manage it well with appropriate large buffers and dependency management. I don't see this being done anywhere, it is usually the business trying to haggle down the engineers on their estimates (even though the engineers are paid a salary so ???).

markburns 7y ago
The issue with this is that if you’re doing cookie cutter websites. At some point it’s going to be more efficient to abstract out the shared functionality and build a framework of some sort. You’ll become more efficient but you’ll either lose predictability or you’ll just be padding estimates to whatever you were estimating before. Not a bad position to be in but you’ll always be somewhere between predictable and inefficient or efficient and unpredictable.

paggle 7y ago

Many people have the ability to estimate non trivial software, given the number of software products which ship on a schedule and don’t slip. Things like features announced at big conferences. Granted, the companies that do this can add people to projects as necessary, so they can work with months rather than man-months.

paggle 7y ago

The much-derided “execs” who demand time estimates don’t do so out of spite. They do so because their costs are measured in man-months, and a business needs to know how much something is going to cost to decide whether it’s worth building. Also, they may have partner companies who they need to coordinate timelines with. I’d guess that freelance developers who are paid per project, and thus have to own their P&L, are very good at estimating.

jdlshore 7y ago
I don't know about freelancers, but typical fixed-bid RFP responses are lowballed in order to get the work, then they make their profit on the inevitable change requests. So accurate estimates aren't as important as you might think.

navinsylvester 7y ago

Its hard to estimate without breaking it down to smaller tasks and this process is laborious. This process assumes we are tackling stuff in which we already have expertise. The rule of thumb i use - anything which takes more than 3 days needs to be broken down further into tasks. If any task takes more than 3 days during execution then it needs to be broken down to more tasks.

teddyuk 7y ago

I was taught it takes about a quarter of the time to estimate work so if you think it will take 1 day you should have spent 1/4 day estimating. If you think 4 weeks then 1 week estimating. Whenever I’m asked to estimate I tell them that I’ll take a week to estimate a 4 week piece of work they almost always say don’t bother - then when the made up estimates are wrong we can discuss the fact that they didn’t bother estimating. It is a funny thing but works every time (in corps).

username90 7y ago

It is possible that a project is non-trivial to you but trivial to someone else, then that someone else could properly estimate it. Also most software projects are trivial so I don't see why estimations would be impossible, it is not like your typical react app is going to push boundaries on research topics. They might push boundaries to mediocre developers though, in which case it is a non-trivial project for them. I think the real reason estimations are hard is that basically every developer is working on projects too hard for them. Like, if you are so good at your current job that you can reliably churn out good solutions with ease then instead of just producing you would move on to do harder things for better pay.

Aeolun 7y ago

Estimating non-trivial software is easy. Making those estimates any kind of accurate is the problem. I was talking with my project manager today, and he was asking me if we could finish on time if we got twice as much time as I estimated. My reply was that we’ve tried that 4 times now, and we’ve never reached the point where we actually finish within the time estimated. So increasing the time would just mean we fail later, not that we suddenly succeed. I’m firmly starting to believe that work expands to fill the time allocated to it.