Slashdot Mirror
Ask Slashdot: Are Accurate Software Development Time Predictions a Myth? (medium.com)
New submitter DuroSoft writes: For myself and the vast majority of people I have talked to, this is the case. Any attempts we make to estimate the amount of time software development tasks will take inevitably end in folly. Do you find you can make accurate estimates, or is it really the case, as the author, DuroSoft Technologies' CTO/Co-CEO Sam Johnson, suggests via Hacker Noon, that "writing and maintaining code can be seen as a fundamentally chaotic activity, subject to sudden, unpredictable gotchas that take up an inordinate amount of time" and that therefore attempting to make predictions in the first place is itself a waste of our valuable time?
Try getting a contract awarded with "It's too chaotic to tell"
Take your developer's estimate
Increase that by 40%
Double that
It seems incredibly arbitrary, but I have learned that the 40% covers testing and implementation, while doubling the entire amount allows for the customer seeing the first result and _then_ telling you what they really want.
Try it, you'll like it
I've taken place in many large projects where timetables were set and met just fine. These were projects where requirements were laid out in advance (via requirements documents) and practical time estimates based with proper labor categories were known (gantt/waterfall charts). The product was finished as described in the requirement documents, but generally didn't work 100% like the customer expected.
I have also worked on projects where estimates were given and then blown by. These were projects where requirements were not laid out in advance in detail, where under-qualified individuals were stuffed onto jobs as "80% fits", and time tables were adjusted to appease a customer. These products were finished late but generally 100% to the customer's expectations.
it's a classic
"folly" - a suitable description for the majority of software out there.
Sure, there has been some good things that happened in computing: like when Mr.Trump invented the internet, or perhaps the BSD OS's, but the majority of development lately has been crap.
Mr Scott, have you always multiplied your engineering estimates by a factor of four?
Oh, laddy, you got a lot to learn!
Writing software in the wrong paradigm to start with.
eg. Oh you want a flat file system to store simple data from your fishing expedition. Ans is to put all your data in the base object while similtaneously adding these two fields together and making it the derived class then deriving another object from uncertainties within your expedition.
These sort of things go on all the time and must be stopped. Do the job not what you might think is the job.
Even with known and well understood languages/technologies/frameworks, you can and will run into glitches that can take days to complete something that was supposed to take hours - or even longer if the developers are not skilled in debugging and isolating problems!
StackOverflow has helped the industry in this regard, because now a lot of times you can reduce some mysterious problem to a fifteen second StackOverflow search which instantly answers the issue. But not always, and there are always issues when actually programming any design that you can uncover hidden flaws and need to correct them.
What I would love to see is some kind of approach that instead of a time estimate, gave a time along with a percentage of confidence. Two different tasks may seem to take about five hours, with one you are 90% sure it can be done in five hours, with another (like brand new code) it can be more of a 50% five hours. Then you could use this percentage to determine the actual areas of coding likely to cause schedule issues and monitor them more closely. The other nice benefit of this approach is that it factors in the actual developer understanding and abilities more than just a straight hour estimate. Maybe you even put a cap on how high a confidence level a developer is allowed to give until they have met given estimates a number of times already...
Coding is a chaotic system, yes, but it's not like it's fully chaotic, and there are patterns within the chaos I think you could determine over time.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Betterage says no.
Hmm, could his rule be applicable here?
Give your favourite band a year, and you can expect a decent new album. But an album can be recorded in 60 minutes. Software development usually falls in between, you need something more than the baseline (which has zero features), but you never get a masterpiece.
I'll let you know tomorrow.
...estimates of resource requirements (including time and budget) for software projects.
However, making estimates of Resource Requirements that will be acceptable to Management...that's impossible. It's amazing how so many people who've never tried can make such ignorant demands...and think they're being "fair."
I've done many project plans for clients, and when I give them the results, they always bitch. But, when the project is actually delivered, they finally agree that I was right in the first place. After that, it gets easier...which THOSE clients.
Fortunately, I'm now retired, and no longer have to suffer these dolts. And, MY projects are quickies that work within a few days, and I love to tenderly "evolve them" over multiple successive iterations, adding new features as I go. My latest one is about 15 generations into development, and I may bring it to market if I can find a suitable partner. It's a novel approach to easily-recovered 100% daily computer backups. it's a much more practical methodology that doesn't require prescience before the first build is done to know every detail about the final product...it naturally evolves.
Like any "process" you can do better but a couple of things have to be true...
1. You had better KNOW what your development process IS (not what you document, or what you want but what it actually IS). Until you know how you develop, test and deliver software from start to end, there is no way you can estimate how long it will take accurately.
2. You need to develop a method of coming up with your educated guesses that is repeatable. The process must allow you to estimate every step of your development process and how much each step is estimated to cost both in time, materials and labor.
3. You MUST collect metrics that allow you to track actuals to estimate for each individual step in your development process though how ever far you get (hopefully to completion).
4. Next time you get a contract proposal and you start though this process again, when you get to step 2, do your estimates, but then compare past projects data from step 3 and see if you need to add or subtract some fudge factors based on past history. Rinse Lather and repeat.
Eventually, you will get better at the estimation and have more confidence in your ability to bid contracts....
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
I'm able to accurately deliver 2.6 features per week, as long as you let me choose the features.
and Apple hasn't allowed a memory uograde in over seven years, they are here since every compile and test takes so damn long.
If you can't estimate the cost of your product... any product... you won't stay in business very long. Will you get the estimate right every time? No. But having a plan that changes, is better than no plan at all. With experience I've gotten better at estimating software. Put thought into it. Your job depends on it. No investors will support a venture without some business plan, and business plans depend on cost. We'd all be destitute if we blindly handed over cash without asking for estimates.
Yes.
The title is one of the few instances where Betteridge is wrong.
Quality of prediction comes down to quality of the information fed into making the prediction. Given all information up front with good BA work up front and requirements and scope that don't change I can generally provide good predictions that are close or that even come in under budget for our projects (good predictions always have some buffer built in for staff and technical problems).
Until an even somewhat accurate time is reflected in with the estimated time remaining progress bars there can be no hope for predictions of software development times.
But file copy time predictions are a myth also. Seems to go with the territory.
“He’s not deformed, he’s just drunk!”
That's similar to what I've experienced and seen reported in studies. When I say "10 hours", that really means "10 times X hours", but that X factor is relatively consistent. Each of my teammates are similar - they are always wrong, but normally by the same multiplier each time.
Developers tend to be reasonably good at estimating the RELATIVE amount of work, they can say "job A will probably take twice as long as job B". This assumes the work is broken down into pieces small enough to estimate. What they tend to NOT be good at is saying how many hours, days, or weeks.
That's where Scrum "story points" come in. We assign each task a number of points. Historical data shows that we can complete 65 points in a two-week sprint. That's relatively consistent.
Some tasks will take longer than expected, some less, but that tends to average out over two weeks of a four-man team. The four of us complete 65 points per sprint.
I'm able to estimate fairly well how long something will take for me, but with a bunch of proviso.
Sadly most projects fail one or more of the points above--which make most estimates absolutely worthless.
I've done many project plans for clients, and when I give them the results, they always bitch.
Oh man this 1000 times, but in my case it usually tends to be management that does this. They ask for an estimate for something, you tell them 100 hours, they say that's crazy and change it to 40. Then when you end up getting it done in 80 (which is better than the original estimate), they complain about it taking twice as long as it what they budgeted. This appears to be pretty common, it's not just a single organization I've been at that is guilty of this (of course someone on here will say maybe the problem is with me, which hell it may be true now that I think about it :-)
My gripe though is that if you already have a number in mind, why bother asking me to provide an estimate?
If you post as Anonymous Coward, don't expect a reply.
Performance predictions have an optimistic bias.
It's known as the planning fallacy
It amazes me how people who should really know better fall for this.
For example, if the last time you did it, it took 3 weeks, a good prediction is that this time it's going to take 3 weeks.
Yet most people will predict less than 3 weeks - even if you point out the planning fallacy to them before hand.
I can almost here the rationalizing; "It's not going to take 3 weeks again, because we aren't going to make the same mistakes again."
But it's far, far, worse than just an inability to predict accurately.
Frequently schedules are determined by need rather than reality. As in, we need this done by Tuesday - make the schedule accordingly.
This:
I always provide my managers with confidence interval estimated times
50% 10 days (assumes *nothing* goes wrong, no interruptions, and high code reuse)
90% 15 days (assumes no catastrophic issues, no interruptions > 2 hours and only 5 of them, moderate code reuse)
100% 55 days (the wheels fell off, severe schedule impacts of interruptions non stop, no code reuse)
My boss laughed at my 100% estimate until it actually happened.
A lead dev (who could be counted on for sound advice delivered in a belittling way) was struck down by lung cancer and ceased to exist. Another lead dev who was even brighter, and much nicer to work with was poached by a competitor, both within days of each other. The code was cutting all new territory in the system, so maybe 15% reuse? *and* some panicky manager started having $deity damned _daily_ meetings about it.
We almost missed my 100% date, made it by about 16 hours.
whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump
Our estimates are generally pretty accurate; then we sharpen are pencils.
I write embedded software. I always run into hardware issues, some of which can take weeks to prove it's the hardware, not the software. There's no way to predict that kind of thing.
My claim to fame was an Intel Ethernet chip that came out in 90/91. It had a bug, I found a workaround. I sent a bug report to Intel, it was in errata for the chip. 3-4 years later I was introduced to Linux. Out of curiousity I looked into the driver for this chip, they had my workaround line for line.
The problem? You could build linked lists of packets to be sent. When you built the first packet you put it on the list, then set a bit saying "I got a packet to send". Problem was, that bit didn't work until a few hundred ms later. When you built the first packet you could link to the second packet, that linked to the third packet, etc.
My hack? I had an available packet of 0 bytes at the front of the queue. Chip kept spinning looking for something to send. I built my first packet, stuck it at the front of the queue, chip sent my packet immediately.
Finish in 3 weeks: "it was an easy project after all! Your estimate cheated us"
Finish in 5 weeks: "you're a crappy engineer! you cheated us by pretending you could do the job"
Finish in 4 weeks: "that's suspicious! you obviously finished early and then goofed off. You cheated us"
Moral: you can say how many or how long but never both! Or: it'll take between 2 weeks and 2 months, depending.
So you can have another pointless meeting with your PHB, instead of sitting through another pointless Powerpoint presentation, on how to make more accurate estimates.You know, if there is a Powerpoint presentation, there should be a Pointless presentation as well.
I find that if I use accurate="correct order of magnitude" then yes, 80% of estimates are accurate.
For examples:
- bug equals "Misspelled company name on splash page of app by dislexing two letters" -> about an hour(+/- some hours) to fix,
plus whatever testing/regression/bundling up for marketing reasons/etc apply.
- bug equals "Company bought out, change name everywhere it occurs, old name=foo, new name=foo, Inc" -> about a day(+/- some days) to fix, plus...
- bug equals "Company bought out, change name everywhere it occurs, including I18N implications and other localization efforts, oh, and logos too" -> about a month (+/- some years because of the weasel words "implications", "other" and "oh" in the bug description).
But sure, if you want to define accurate to be to the nearest dollar, waste of time.
And everyone is pissed off if everything isn't perfect, so... waste of time.
It's a skill you need to practice, just like every other skill you've learned. It's simply no one puts in the time to actually practice it. Randomly coming up with time estimations is not practicing, just like randomly swinging a golf club around isn't practicing golfing. You need to:
A) Think about what the task actually is.
B) Compare the task to previous tasks you've completed.
C) Make your estimate (and estimate range, confidence value, or whatever other metrics you want to use).
D) Do that task, tracking the time spent on it. If the task can be broken down further, then you make new estimates on each subtask.
E) After you've finished, you go back and compare your estimates to your actual times. Use your brain to determine why your estimates were off and think what you would have needed to do to have foreseen those estimate off-setters before making your original estimate. (Most people skip this step and are thus forced to make gut estimates instead of intelligent ones)
Z) Bonus: Re-evaluate your estimates while you're working on the task rather than just after you've finished it.
--- Rant Subsection ---
That's why college is important. If you earned a Software Engineering degree from a decent school you'll have covered all aspects of software engineering and will know how to advance your skills in all areas (as well as where your gaps are). If you're only self-taught (or have a CS degree from an average to poor school), you don't have the foresight to know your gaps and will simply assume everyone else has the same gaps because of the excuse: "SW dev is hard". Anyone who doesn't also struggle in the areas of your faulty assumptions is seen as a superstar rather than properly educated. The education most programmers have is appalling.
--- Bonus Rant Subsection ---
You can take steps A through Z and apply them to near everything you do in your life. You will advance your abilities in those things far, far faster than if you only mindlessly performed them. Self-reflection matters if you want to have a good self.
Yes. Accurate software development estimates are a myth. Calculate the estimates then add 25% to avoid going over your budget.
What he wrote:
What's he's hoping people read:
Unfortunately, version 1.0 typically falls under the thick veil of he said, she said.
Here's the exact point where he wanders off into the weeds:
It doesn't take a 4-Sigmund review to spot the out-of-school litigation here. No one in a state of conflict appreciates the lateral spread of subtext.
I know estimation is often used as a management bully club, and I've had some pretty dark thoughts about some indivisuals who have chosen to behave that way, but sorry, I'm just not feeling the sympathy in this instance.
TFA has an update suggesting the author got fired for writing it
UPDATE: as a direct result of “the views espoused in my engineering article on Medium” I have been terminated from my contracting position at my current employer. Still figuring out what my rights are in this sort of situation so any guidance, advice or employment offers are appreciated. I will be adding a GoFundMe link and a more detailed postmortem shortly.
https://www.joelonsoftware.com...
This is one of his blog posts that is almost an infomercial for his product, but he does describe the concept well enough that you could roll your own if you wanted to.
See that "Preview" button?
As lead video game tester at Accolade/infogrames/Atari (same company, different owners, multiple personality disorder), I was responsible for getting ten titles through QA. The schedule set by the producer, developer and marketing teams were always based on milestone bonuses. Everyone got a little something extra in their paycheck if the schedule estimate was accurate. As a lead tester I got no bonuses and cared less about anyone else's bonuses. I typically added six weeks (+/- two weeks) to the schedule estimate. Nine out of ten times, my schedule estimate was the most accurate and everyone else didn't get their bonuses. The exception to the rule was a developer who submitted a detailed, 256-page design doc (most design docs are ideas on napkins to get money).
Yes, this. Good management knows that you know your trade and accepts your estimates. Bad management thinks they know better and try to negotiate on estimates.
Over the years I've found that feature development, particularly adding to existing systems, will get better estimates if we're allowed a spike to review the affected areas up front - this is when you discover unexpected dependencies or just sheer awful spaghetti. When you're not allowed to do this up front is when you come across the unexpected gotchas that blow out the best estimate you could provide at the time.
My gripe though is that if you already have a number in mind, why bother asking me to provide an estimate?
It's just a simple bargaining tactic. It works really well on non-intellectuals. First they need to find out what you think is a reasonable amount of time so they can make you feel bad about it. They have no idea what a reasonable amount of time for the task actually is but they'll vehemently insist that it's less than 50% of whatever you tell them.
The idea of course is that it'll put you on your back foot, then they'll be able to make any demands they want of you about extra features or lower prices later, by leveraging the notion that you're already not delivering fast enough before you've even started on it.
And these people wonder why they've needed to cheat and twist government regulations to find foreign indentured servants willing to keep doing this crap. It's pathetic really.
One incredibly smart person told me early on in my career, to take my best estimate and double it. Over the years, I've found that this estimate is usually closer to the truth, than the "best estimate" that I doubled.
Remember Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
We converted to Agile Scrum. We spend about 8 hours a week on sprint planning or backlog refinement. Every minute of every developer's day is planned out for each sprint.
Then we spend 4 hours per two-week sprint in our retrospective discussing why our estimates are totally wrong and how we can estimate better next sprint.
We've only been at it 6 months. Our Certified Scrum Master and Certified Scrum Trainer say we just need to keep working on it. Before you know it, we'll be 100% accurate in planning!
As I said in the subject line, this sounds like a comment from someone who lacks a good deal of experience with coding.
The biggest thing to understand about coding is this - if you think you're working in an isolated environment where all the variables are tightly controlled, you're wrong. Which as any good coder or consultant knows - you come to acquire two things important to any coder's toolbelt of skills.
First, you understand and develop people skills. When you're dealing with Project Managers, Managers, Directors, Analysts, QA - they'll each and every one of them prepare information in ways that have inbuilt bias. This bias is where much of the chaos begins, and the source of things like scope creep and the heart of translational and interpretive errors for delivering what the customer wants versus what the respective silo'd anaylst things they want.
AS a developer - IF you manage your time based strictly on the input of these individuals who serve to isolate you from the actual customer, chaos ensues. HOWEVER, if you manage your time based on both MANAGING these resources AS WELL AS direct and periodic interaction with the customer, which because people skills is typically not a personality trait that most managers expect of developers, by and large they'll be supportive particularly if you position it as "I'd just like to make a better product and would like to sit down and get to know what they're doing now and if I - as a developer - have thoughts on how to improve it that everyone else may have missed".
ANY well seasoned developer maintains constant contact and balances his or her or its time between the interpretive representatives and the customer themselves. This is to mitigate the risk of scope or feature creep which invariably winds up making you - as a developer feel like you're being pulled in a million directions and incapable of managing your own time.
Going hand in hand with customer interaction is padding. ONCE you learn how to manage your partners, you provide yourself padding, and build that directly into the estimates. I myself would consistently build a 20% increase in expected time to complete any project, large or small, into my estimates for the 'gotchas' that would inevitably occur.
For things I really didn't like or want to do, I knew my productivity would be even less, so I estimate two to five times more time for these projects than normal. This ensured the crap I wasn't interested in wouldn't be handed to me, and with all sincerity, the often brain dead nature of work associated with things I wasn't interested in was a viable estimate - if I am not engaged - then my interest will show and I find it hard to focus. No lie. Total truth. And since - as a developer - we're not machines who can just spit out code at a predictable rate - pushing back or incentivizing management to hire less experienced coders who MIGHT enjoy what I formerly did might achieve more 'efficient and predictable output'.
Programming isn't chaotic. But the processes and support systems for those managing developers - at least in my opinion - don't understand development. Sure, they may know how to create a few scripts and/or might know basics and how to create a hello world app, but give them something more than that - and invariably, their brains will melt.
In my opinion, it's the job of Senior Developers to manage the junior developers and the entire staff above them to set realistic expectations and provide engaging work, which requires - absolutely requires - that developers become acquainted with customer service skills and that management encourages this. In the end. It makes for a far superior product, and keeps not just the developers happy, but everyone else because..
chaos doesnt happen.......
and timelines are managed better all around.
Time estimates and naming: the two hardest problems in CS. Why? Because they both require the most human thought and no clear right or wrong answers.
Indeed. Many PHB's have to learn the hard way:
"Who knew healthcare would be so difficult?"
Table-ized A.I.
The solution is not to *impose* a schedule, but let the developers who are going to do the work make the estimate, and don't argue their estimate down. Others who have suggested multiplying by some factor might be a good idea as well-- but unless the developer has his own credibility on the line for the estimate, he won't put in the extra work to try to make up for a schedule overrun.
If the problem is well-defined and the developers have worked on similar projects before, they can probably give fairly accurate estimates on how long it will take. Mostly with mid-sized projects, I've found, because any delay is disproportionately large in a tiny project, and large projects are more likely to have significant managerial interference after the project goals were supposed to be set in stone.
If you're looking as something novel, then estimating the required time becomes more of a dark art. You simply don't know what issues will come up that you've never encountered before (and therefore you also don't know how difficult they will be to code around) when you're in unknown territory. Sure, if the problem is well-defined and the project manager successfully resists scope creep, this can be limited, but it can never be eliminated. Eventually, the UAT group is going to identify a problem that wasn't on the coder's radar, and then delays begin.
I usually double my gut feeling then inevitably have a few instances where I'm under stress trying to keep to that when something's gone wrong. Dark art.
they are.
Yes when clients and managers choose often it speed and low price in the preparation then demand quality at which point the speed disappears. to maintain the price which rises anyway due to the extra time cost but this isn't passed on leading to failure.
Your'e all thinking it, I just said it for you
I used Function Point Analysis weighted for web based applications. But this presupposes there will be no major increase in scope, or increase or decrease in staffing. It also worked well when I had close contact with customers and could understand their needs directly.
In fact as soon as I saw velocity in the Agile, or related, Scientific Software Management practice I immediately "got it". One number to calibrate on to embody a host of factors internal and external and measure complexity.
The problem comes in when you are not allowed to calibrate due to things such as scope creep. People also do not like to hear your answer either. For example I one predicted that it would take four months to complete some features, the naysayers said 3 to 4 weeks. I was looked upon as a "gloomy Gus". The actual time was 3.5 months.
People want it now and try to push for more. The only way to do so is to cut scope and the quickest way to do that is to cut corners on quality.
putting the 'B' in LGBTQ+
I've been using Fogbugz for years
It is from the same folks that bring you StackOverflow.
Fogbuz uses evidence based scheduling. You estimate a task, and actively track how long you took to complete each task by clocking in and clocking out of the task. Fogbugz learns a statistical model of your individual team member's estimation accuracy and then gives a realistic project completion date using probability and confidence intervals.
In practice, it is hard to remember to clock into the task that you are working on, and to clock out of the task you are working on. But, when I used it properly, it was actually pretty good at estimating when I would be done.
You should never give an estimate with a closed answer, makes people fixate in that it will be done on date X. What you need to use is a range and depending on what information you have on the project use Rough Order of Magnitude Estimate (Variance of -50% to +50%, or -25% to +75% depending on preference), Budget Estimate (Variance of -10% to +25%) or Definitive Estimate (Variance of -5% to +10%). The only time you will know when a project will be done is the date your client signs off for it.
(I am the OP)
TLDR: lost my job for writing this article
you can donate here: https://www.gofundme.com/lost-...
While I list my title online as the CTO of DuroSoft Technologies, I am a part-time graduate student, and the vast majority of my income comes from a contracting position I (until just now) held at a popular SaaS company. I am not going to leak the name of this company, and I would politely ask people who reply to this thread not to speculate about about which company this might be, or otherwise go on a witch-hunt at this time.
Effective immediately, I have been terminated from my contracting position at X explicitly because of the views I express in this article, and the article's subsequent popularity on HN, Reddit, Slashdot, Hacker Noon, Medium, and other sites. Earlier today the article was posted and discussed in my employer's private engineering Slack room. A highly positive discussion ensued in which a number of our senior developers identified some key points and takeaways we could use to improve our effectiveness as a team. The CTO intervened and put an end to the discussion with little explanation, even though it had been a very constructive conversation with zero negativity. Despite this, I was floored by the words of praise and encouragement I received privately from other developers, and fully expected my article to become the topic of our upcoming team-wide engineering lunch. Several hours later I was called into my supervisor's office and it was made clear that "your medium article goes against some of the core engineering values of our organization", and that my decision to publish this article was the deciding factor behind his decision to terminate my position. Within 5 minutes, I was kicked out of GitHub and slack, and escorted out of the office of a company where I had worked for the last three years.
I am scrambling right now to figure out what my options are, my main concern being that I am already in debt, supporting my fiance, etc., and need to get my financials figured out ASAP. I just sent out about 20 applications to various senior software engineer jobs, but I likely will go negative well before any of them gets back to me. If you would like to support me while I figure out my options, and potentially help me fight for my right to intellectual freedom online, please consider visiting the gofundme link at the top of this comment.
No, not a myth.
I worked in a CMMI-5 environment. We were extremely accurate on all our estimates - +/-5%. But we were asked to make perfect code regardless of the time. Schedules would be built around our estimates.
We reviewed every estimate after each project and tweaked our estimate tools to get better. Every hour of a project was tracked too, so we had good data to base the comparison of predicted and actual costs.
The SW program was 20 yrs in when I joined. I was there for 5 yrs. Every estimate anyone on the team did followed a 12-20 pg estimation process, to be certain nothing was missed. This was multi-threaded, highly complex, real-time, code for billion $$$ vehicles.
Our entire process was extremely rigorous.
Funny thing is, the lead claimed that he could use a ruler or a scale to estimate just as accurately as our 12+ pg worksheets did. I believed him. The size of the requirements (which were all written), were a good measure. Some estimates would take 2 hrs, others would take multiple weeks due to the total project size.
I've worked at many other companies since then. None of them really had much process around their software estimates. Each was basically 1 question - "how long will it take?" That's it.
I was able to bring some ideas about better estimation to 1 of those places. Basically, asked developers to estimate in 4 hour buckets. Their first estimate, I'd go over with them, individually, asking questions along the way.
The first rule was to stop being optimistic. Developers are always overly optimistic in their estimates.
2nd rule was to assume 6 hour work days. Most devs at that place were doing 10+ hrs a day and I wanted that to stop. They needed outside lives to get their minds refreshed. We formed a soccer team since most of the employees were from outside the USA, but very few South Asians.
3rd rule was to track their REAL time working on each effort, even if they didn't want it on their official timesheet. We were all salaried. I explained that it would be a little more work at first to do this, but in the end, it would prove that we had way to much on our plates.
All of this worked, but it didn't change all the last minute marketing demands to fit "just this tiny thing" into the release. After 3 yrs, I left.
At the next place, I didn't do software anymore, but I watched those "consulting companies" - you know the $300/hr teams of 50 - do their estimation. They'd make a presentation about why it should take 3x more time than I'd guess using my pessimistic estimation process. I'm positive it was just to pad their billing. When we offshored most development work to India, it got worse. They'd triple the time AND triple the number of people. I got into trouble laughing at their estimates on conference calls. Remember a multi-year project that was cancelled after 18 months - completely cancelled. Think they'd blown $500M on these consultants. Those teams were flying in every Monday and out every Friday for all that time. We were paying for all their hotels, cars, flights, in addition to the $300/hr bills. It was crazy. Most of the team leads didn't actually have any software background. All the developers were fresh out of school or had less than 2 yrs experience. I did find some local guys who had been on our normal contract that were very smart, experienced and efficient. It was just the fly-in teams that were blowing through money like only most govts do.
Or ... the easy way to estimate is to let developers provide their estimates for everything, then triple it to get documentation, testing, rework, those little "extras" that weren't in any requirements. Just don't tell marketing or management what you've done - and don't cave when they push back.
It depends on what you're doing. If you ask a 12 year old to predict how long it will take to disassemble and reassemble a car, he'll give you a wild figure. After he's done it 100 times, he'll give you a very accurate estimate.
Over time I've found my estimates getting sharper and sharper, with a tighter range on the min/max (not really a "max" since it's an estimate), even with unknowns. Though no matter how long you do it, there's always surprises. It's about mitigating that in your estimate and communications.
So I wouldn't say it's "inherently impossible" but rather, a spectrum of accuracy based on familiarity with the task, past repetition of said task, and the information going in - like anything, really.
I run into the same problem. The funny thing is my manager knows my estimates are off. My manager told me once that when I give him an estimate, he takes it and multiplies it by 2.5 so a 2 day projects becomes one week and a one week project becomes one month. The problem with this is if I give him a realistic estimate, he multiplies it by 2.5 and balks so I'm stuck basically giving him low ball estimates with us both knowing it will really take 2.5 times longer. So in a weird way, My estimate is actually pretty accurate.
is that it's perfectly acceptable for the customer to change the requirements but not the least bit acceptable for the schedule to change in response to changed requirements. Worse, it's very rare that I start with solid complete requirements. Under those circumstances, schedule failure is pretty much guaranteed.
That's pretty interesting - I had heard about Fogbugs for years even before StackOverflow but had never used it.
Clocking in and out of a task is annoying, but if you make it easy enough it is not too bad.
Sadly one of the main systems I use at the moment is the execrable TFS, with no change the company will switch from it.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I always provide my managers with confidence interval estimated times
That is a great idea - I did the same thing years ago at a past employer - sadly the manager knew not what to make of it, so I only did it once. It was more accurate than the "real" numbers then ended up going with.
But I think giving a range of timeframes with percentages is probably the best way to go, if you have to give estimates at all...
"There is more worth loving than we have strength to love." - Brian Jay Stanley
MAKE IT HAPPEN signed your PHB.
Just always promise the world to the client and it will magically get done without input from the team of course.
http://saveie6.com/
"Good investors don’t need to know when a feature will be done—rather they just want to know that it is a priority and that it is being worked on—and if they are smart..."
In the corporate world, schedule and predictability is everything! That statement made me LAUGH OUT LOUD.
Also, clients aren't smart. That's why they hired you.
Here's what you need to do:
1) Make sure that software-delivered idea is novel, useful, fits a strong need, and is going to be usable easily.
2) Hire the smartest developers you can who also are friendly and have a good work ethic.
3) Have a good process (e.g. OKRs) for ensuring focus (prioritized but adaptable focus).
4) Have a good process for exploratory development and iterations/sprints with re-prioritization after each version.
5) Have a good process for eliminating technical debt as you go.
Then you just have to trust that you'll get the best thing you could have got, in the time and money you allocate.
You have to hope that it's good enough to be a minimum viable product. If not, you simply couldn't afford to put together a software product in the first place, and no amount of estimating would have changed that.
Where are we going and why are we in a handbasket?
This isn't any thing new. People are bad at estimating how long a task will take, wether it is developing or building a skyscraper. There is a lot of literature on why people are bad at estimating the time it will take to perform a sequence of tasks. Development is simply the next in a long line of activities that people try to estimate, and do badly.
I'm a consultant - I convert gibberish into cash-flow.
I have have pretty good success with this process:
Tasks: write down all them thar software bits that need to be coded.
Effort: How much time will each task take.
Complexity: Complex things take more time - make up a coefficient. GUIs are always complex.
Risk: How possible is it that something wont work? - another coefficient.
Now put them all in Excel, and then adjust the complexity and risk coefficients till it matches with how much you want to charge the client.
The alternative to limited government is unlimited government.
I've seen some really interesting results with Cocomo models once we were honest with team experience, problem knowledge and technical expertise.
Of course I have NEVER worked on a project where the models were accepted because model calculated cost was NEVER the number management wanted to hear. All of those projects ran over the officially accepted estimate by 2-3X.
Sometimes management does this on purpose. Many projects don't get serious until they are 1/3 of the way into the project. This leads to shortened schedules in order to force activity earlier. Sometimes management does this because their even more senior management just won't accept the right answer but will pay for cost overruns once they are afraid of losing the sunk cost work already
No, but they do come with a "cone of uncertainty" that gets larger the farther into the future you predict.
Software development predictions also come with a cone of uncertainty. You can predict pretty accurately how much you can get done in the next week or two, but those predictions get less accurate the farther into the future you look.
My third job, a contract with a, well, sort of a utility company. I was originally hired to work on the implementation of a new accounting system, which did so poorly that the Major Accounting Consultant Firm was fired one afternoon. But I was personally doing well, and so got a new assignment, to be project lead to convert a system written in COBOL that called multiple FORTRAN subroutines (doing scientific computations) using VSAM files to use DB2 databases instead of flat files.
Lots of screens to update the files/databases. But it was relatively cut and dried. I worked out how long each revised program would take, counted the programs, did my homework, gave the estimates and background data to my manager, who said "That's too long... make it shorter!"
So I make it take the length of time he wanted. Then one of the contractors finished his first big task, it was horrible. Barely functional. We let him go, I gave that task to another guy. Most of my guys were in another state, which shouldn't have mattered. But of course it did!
Anyway, when we reached the time I "estimated" as instructed, we weren't done, and I was moved back to that horrible accounting project that had died a year ago. The people who took up my "failed" project finished right on time - that first estimate that was "too long"... using my specs and designs.
TL:DR Even if you do a good estimate and hit it right on, it still won't be right.
Think of the Irony!
Sure, coding this up should be pretty quick, since I just need to plug A into B using X. .NET does W, Y and Z, so it should do X.
Me: Wait, where is X? .NET won't allow you to do that with X for security purposes
Microsoft: X has been deprecated in 64-bit.
Me: Wait, why? W, Y, and Z all work, why not X?
Microsoft: Nobody uses it.
Me: It's listed as a feature in your docs! It's the recommended method! If people are doing W, Y and Z, they are definitely doing X!
Microsoft: Whoops, wait a sec... There now they say NOT to use X as it's deprecated.
Me: Fine I'll write a 32-bit shim
Microsoft:
Me: Holy cow I need to write a friggin' service and pipe crap to it just to get X to work?
Microsoft: Or write your own implementation
Me: The whole point of X is it's a pain in the neck to implement properly and I'd rather be spending time on user-facing stuff, rather than become an expert on X, which I'll only be using for this one particular feature. Fine I'm re-implementing, my original estimate has now increased 10x.
Six Months Later:
Microsoft: Good news, X has now been implemented in 64-bit! Download it here...
My Other Computer Is A Data General Nova III.
I've used Fogbugz. I totally agree with this:
> In practice, it is hard to remember to clock into the task that you are working on, and to clock out of the task you are working on
What has worked much better for us has been tracking what we actually accomplish in a two-week sprint. We estimate each task using "points", which are a completely artificial construct designed solely to indicate one job will probably take about the same amount of time as some other job, while a third one will take twice as long. At the end of each two-week sprint, we can see that we usually accomplish about 65 "points" of work. So we can assign points to a group of tasks, divide by 30, and that's how many weeks. But we don't think about weeks when assigning points - a task is a 5 point task if it should take about as long as previous 5 point tasks.
Make you best estimate of the time required, say 1 week. Raise to the next higher unit of time, in this case a month. Double that. Thus, 1 week becomes 2 months. Do not tell this to management, of course. When management says you can do it in 1 month, then you don't have to whine and bitch too much.
It's impossible to give an accurate time without a nice padding estimate. Well you can get close, you'll never get good enough for it to really matter. When estimating a software project always add an extra 20% on top of the original estimate to get something realistic.
> I don't know any easy solution to that: mind-reading machines don't exist.
I came across a solution that works really well, whenever you can possibly do it. First, let's be clear about the most common method, which does NOT work. Most commonly, the users' boss talks to someone, maybe a product manager, about what they think the users need. Then the product manager or whoever talks to the developers about what they think the users' manager said. That doesn't work very well most of the time.
Most of the time, new software is needed to handle a process that is currently being done by hand, perhaps on paper or in Excel. Maybe you're replacing legacy software. Normally, the job is getting done *somehow*. So go *watch* the job being done. If it's being done on paper, watch thr person do it on paper. Follow the piece of paper as it is filed with another department and they type the information into some computer system. While watching the person do the job manually or via the legacy software, ask questions and take notes. Then if possible try to do it once with them watching you and correcting your mistakes. Now you know pretty much exactly what's required to get that task done, because you've just done it by hand. Ask what kind of exceptional conditions come up - what kinds of weird things happen that cause a change in the process? Obviously you'll code for those specific exceptional conditions, but also that lets you know what general *types* of variation there might be, meaning where you should try to build some flexibility into your system. When you discover there are three different types of X, you'll build X modularly, knowing that another type of X may come up.
If it's not possible to actually watch the line people doing the job, at least try very hard to get them on the phone. Talking to the actual users, asking them what's frustrating about their current process, will tell you a lot about the requirements that you won't get from listening to your boss talk about what their boss said.
Most of the estimation problems I've run into are because (a) the people doing the estimating have never designed/implemented similar software, and (b) they don't make explicit the assumptions on which their estimates are based.
I've used wideband Delphi estimation on tasks with a design/implementation team of 6 people who *really* knew what they were doing and it worked very well. It really helps to assign tasks to people who can do them.
When the assumptions change of course the estimates go out the window -- yeah, I said six weeks, but that was assuming that you didn't make me half as effective by fscking the network that I depend on.
Here's how to calculate a 100% accurate estimate 100% of the time, when your manager asks you to predict how long it will take to implement feature X:
1. Tell your manager you'll get the estimate for them as soon as you've done the necessary research
2. Go back to your desk
3. Write down the current time
4. Implement the feature
5. Subtract the time you wrote down in step (3) from the current time. This is your 100% accurate estimate of how long it took you to implement the feature
6. Email your manager, and let them know the estimate value. If you're feeling like it, you can also let them know that the feature is now implemented (although this may make them feel like the estimate you gave them is no longer particularly useful, so treat cautiously there)
I don't care if it's 90,000 hectares. That lake was not my doing.
At one place I was at, a strategy that seemed to work for at least one manager was to keep a spreadsheet, listing each developer. He'd record their estimates, the time it actually took for each task, figure out a multiplier, and apply it to the estimate for the next task. After a while, he had fairly accurate estimates of what each of his developers would take for each task, moreso than most other managers. Granted, it takes time and will be highly variable at first, but *does* seem to zero in after a few different tasks.
"The urge to save humanity is almost always a false front for the urge to rule." --H.L. Mencken
As a business leader in a technical organization, I'm pretty sure they had other problems with this stooge before getting a good excuse to can him.
I read the article and from a technical perspective agree with some facets of it. However, the reason time tends to matter is that time is money. No project will ever be funded if it can't be estimated as a $100 or $100,000 project. In the best case will there be a 4x difference between desired and actual cost and time? Sure. Should programers be paid for unlimited toiling? bullshit.
Some painters are real artists. Sometimes I need my fucking house painted.
I.e. if you carefully estimated the time, tell them you need twice that. If needed, waste some time to be accurate. Of course, even this method requires a high level of skill, because the average developer (i.e. not really good at anything) will deliver results with even more delay if given more time.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
*and* some panicky manager started having $deity damned _daily_ meetings about it.
This is my favorite bit when something very unexpected happens and managers make us twice as late by creating a ton of overhead about when/how/why/re-estimating/re-planning and plain old nagging to get it fixed. If what you care about is getting it actually done, let me work. If you need an alternative other than not delivering I can help you find that, but other than that you're not helping. You're slowing us down. This is particular frustrating when you're not 100% assigned to a project, yeah I'm supposed to spend 30% of my time on this... you spent 10% of your time, maybe that made sense to you. But you just spent 33% of your development time on BS, was that worth it? That way we have the same meeting in a few days on how nothing is happening.
Live today, because you never know what tomorrow brings
This topic comes up pretty regularly, and it always amazes me that there is not an appreciation that nearly everyone in science and engineering has to work through unknowns in development on a schedule, and we've all adapted.
I work on developing a product that integrates a lot of different fields. I work with various engineers, physicists, biologists, chemists, and programmers. All of them have tasks that are impossible to estimate time and cost for with 100% certainty. That's an unreasonable bar to set. Many of them have tasks that may simply be impossible with current levels of technology.
We work out a schedule and budget, because otherwise we can't move forward on development, or understand when the amount of resources required to finish the project will be more than the end value of the end product. We have some basic research grants and the government requires a schedule, budget, and regular reports for blue sky research as well. We produce some lab equipment for pharmaceutical companies. Those guys have scheduling and budgeting challenges that make a lot of engineering projects look easy.
My team trusts that I will only change requirements for good reason, and will adjust resources and schedule to reflect reality as we progress. This adjustment for reality works the other way too. I trust them to understand that there are finite resources and time available to attempt a project, and if something isn't working out, it's getting cut.
"7 minutes, 26 seconds, and the Fundamental Theorem of Agile Software Development" ( https://vimeo.com/79106557 ) :-))
JB Rainsberger explains how we usually do our estimates based on essential complexity, although the dev time is often being dominated by accidental complexity (at least, it's quickly watched
It takes longer time than you think even if you consider this sentence.
And basically, management only cares about the critical path, so those off the path are actually free to make accurate estimates to hone their skills. As long as they stay off the critical path.
And also, you usually find that people along the critical path are bludgeoned by management to trim their estimates beyond reason, resulting in delays along the critical path. Which actually gives some slack to everyone else.
In order to balance the tension, we development leads used to request an estimate for management induced delay in the project up front, and we would track that delay generated by management weekly until told to shut up about it by at least two higher levels of management.
As a wise man once said, "Projects are 80% complete 80% of the time. The rest takes the other 80% of the time".
I was responsible for project estimating for several years. The more detailed the plan, the more obvious it were the possibilities it missed something. Software expands to fill the available budget.
Management won't want to believe it or accept it.
Project planning is really easy, large civil engineering projects usually come in on schedule (modulo being screwed around by politics), and software can be done on schedule.
A few rules:
Clear requirements
No changes until those requirements have been met and delivered
(Those two are generally impossible to achieve BTW).
Management has no input into the schedule, let the devs set it. (Ouch, havn't see that for years either).
Agile I'm afraid doesn't help these days, it's original objective of being used to wrest scheduling from the hands of less than competent managers has been subverted and what most people call agile now is just an excuse for management changing requirements and schedules under the devs.
That's a good method; unlike simply overestimating the task, it allows you to build in some contingency while still start out with a planning that follows the most optimistic path. Hope for the best and plan for the best. Because another truism of software development is that any overestimated task will stretch to fill the allotted time.
If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
Accurate estimates of time to do a particular piece of development work are completely possible.
Accurate estimates of total amount of development work which will be expected are completely impossible.
If you give someone a definite spec, and then don't talk to them at all until the spec has been implemented fully, the time estimate can be extremely accurate.
But:
- feature creep
- misunderstandings of the spec's meaning
- clarifications
- refactoring in anticipation of the above
these mean that what you estimated originally, are not the same as what you eventually do. So it's not so much that time estimates are inaccurate, as it's not until the end of the project that you actually have something to estimate.
It's amazing how often I've seen projects - even strategic / multi-million buck ones - being planned "on the back of an envelope".
Some dude shits out a guesstimate that's then slapped in a powerpoint and it becomes the target & budget which is handed to the luckless PM and the dev team.
Getting the right people involved, and going into detail on scope, spec and architecture etc. is not "wasted time and money" but instead an investment; these are activities that will have to be done (or should be done) eventually anyway...
Of course, the estimate is often higher than key stakeholders "guessed", hence the popularity (as mentioned in another post) of the cynical "lowball then come back for more time and money later" method.
Then we get posts like this saying "development is impossible to estimate". Bullshit; with a competent PM controlling the scope and a tech team that know their stuff it's not that hard.
I'm not sure what Fogbugz used under the hood, but I had worked in an environment that used the Personal Software Process (PSP) and the Team Software Process (TSP). https://en.m.wikipedia.org/wiki/Personal_software_process
It was a bit annoying, but over time it really did help us with our estimates.
....there are no accurate requirements or no requirements at all. If you don't tell devs exactly what to build they have a tough time estimating. Even when there are requirements, if there is nothing comparable done recently it is difficult. Besides that an estimate implies that it is NOT accurate! Anyone who takes estimates as fact is a fool.
I've been doing development work since before C++ existed, but no contract work. The last 20 years I've been designing and writing mostly device firmware and the configuration and reporting PC software that belongs with it, for a manufacturer of, let's just call them "automatic machines".
It's always been the same: you CAN NOT accurately predict development times, and trying to meet an impossible deadline too often results in poor quality work being delivered.
So after decades of doing my best to predict development times with some accuracy, and swallowing several kinds of unpleasantness when it went wrong (often than not only because the specs kept changing even after the product was finished, but that's another discussion), I have recently ( 5 years) decided to begin applying the Scotty method.
Multiply your estimates by a factor of at least two, aim at finishing in half that time, and most of the time you will be regarded as a genious.
It actually works, some times. I managed to get praise for being fast in situations where I completely missed my own (private) original estimate.
Take a wild ass guess -- just take your first best guess.
Then double it, and move to the next larger unit.
1 hour becomes 2 days.
1 day becomes 2 weeks
1 week becomes 2 months, etc.
You will be surprised how accurate it is. And you will virtually always deliver just a little early.
Ian Ameline
...we were not always shooting at "moving target" requirements that remain in flux throughout the development process.
in the long tradition of "if there is a question in the /. title - the answer is yes" - yes "accurate" software development time predictions are myths
of course "accurate time predictions" are going to be "myths" for any massive project (a google search for "defense project over budget" produces interesting results - like this)
the fact that people tend to get better at "estimating" anything the more experience they get at "estimating" is a big part of the reason why "lead software engineers" make more money than "junior software developers" ...
It ain't what they call you. It's what you answer to. http://mylyceum.us/
Consider a request for a table interface with which to enter some data, enforce some rules, and print some reports.
Automated tools can build that in seconds. A few hours of tweaking and you're done.
Now write the Obamacare website. Wait. That site was entirely data driven and should have never been as convoluted or complicated as it was. Of course the developers were probably getting updated requirements every week right up to the roll out date. THAT is why software estimates are off by so much sometimes.
When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
Hopefully your estimating skills are better than your English skills?
Predictions are not the right way to approach this. You need to set strict deadline when the software needs to be stable for shipping, and any errors at that time need to be investigated fully. You can't predict it, but instead you can instruct programmer to slowly approach certain deadline. If programmer knows the deadline approaching while developing it, he can either declare it impossible to meet or confirm that it'll be ready by that time. If it'll be ready earlier than the deadline, programmers should have slack time, instead of pushing new requirements immediately.Deadlines need to be in regular intervals, like once per half year or something. If the time range for development is shorter, you need to call it agile/scrum and not just deadlines
Also, you should release the software immediately after the deadline -- and not wait 3 weeks afterwards...
Fae away and long ago when FORTRAN was young, I once wrote one-off engineering code for a (non-programmer) manager who micromanaged. Every project had to have an initial estimate and continuous status reports. Because he did not program he did not challenge our initial estimates. No matter, he was known for always holding a sudden "crisis" partway through the project (Mr. Big is visiting or whatever) requiring completion ahead of schedule, requiring a death march. (This being his chosen method of turnip-squeezing management.)
He had driven several coders to quit while others literally tried to hide as the critical stages of a project were reached. My solution was to always under-report progress, cumulatively generating enough slack to negate his predictable self-generated emergencies. With great drama I always managed to meet the artificial revised deadline. He never did catch on that i wasn't putting in the free overtime he wanted.
Alas, most programmers can not contemplate reporting less progress than they have made as too much ego is invested in their progress reports.
Most software development is like Research and Development. When will you have that new Battery designed?
It is not production. When will you have the blueprints for the office complex more than when will it get built.
The real problem is poorly considered and expressed requirements and the resultant feature creep. This is failure of governance, not a short coming in developers. Those saying I double (or whatever) their programmers estimates need to look in mirror and recognise the failure is their own.
So no, I do not have any trouble giving accurate estimates, but then I refuse to give any until the requirements are well defined and understood by the team. I my experience this is norm now for most genuinely agile teams.
I could write a completely accurate time estimate, down to the minute. It would take me three times as long to produce the estimate as it would to just do the work in the first place, but yes, I could produce an estimate of any arbitrary accuracy.
Proud neuron in the Slashdot hivemind since 2002.
Which people are you talking to?
I've found that I didn't become great at making estimates until I had been programming for 20 years.
For years 21-30 I've been great at making estimates.
If you're working with customers hiring programmers from India with only a few years of programming experience or you're working with companies who practice age discrimination, then you're going to find that nothing ever gets done on time.
If you're working with experienced programmers, then your experience will be the opposite. Being able to accurately estimate how long your work is going to take I think is the last skill that a programmer acquires, and in my experience it takes decades of experience.
The biggest folly of inexperienced programmers is that every programming job is that everything is either a 15 minute hack or will take a few days at most. If this sounds familiar then you're not hiring the right programmers, or you're being penny wise and pound foolish in your hiring.
No, bad management sees an estimate they don't like, and ask you to re-estimate. What they really mean is that they want you to say a smaller number so they're not on the hook, you are.
I have, in my 35 year career as a software engineer, had one time estimation rule-of-thumb that has held up well. Take the best estimated time, double that, and add 10%. Never fails!
Sometimes, real fast is almost as good as real-time.
I've developed reliable dev estimates in the past. This relied on us having a single codebase that we worked consistently on for an extended period. We knew our own infrastructure. We knew what we were doing. If there were major areas of doubt, we used a timebox for investigations.
The kicker: however long it took us to write the code in the end, it took us one tenth as long to create the estimates.
That's a bit of a broad question. At a broad level, I suppose the answer is:
Tasks are decomposed into chunks of a manageable size, chunks that will be done be one person, and might take anywhere from 30 to minutes to 3 days to do.
Then based on experience each member of the team says how many points they would say for each, where the allowed values for points are: 1, 3, 5, 8, 13. The "missing" numbers help avoid getting bogged down in deciding whether it's a five or six; six isn't even an option.
Some developers quote by the Ego method. Others quote by the fear method. It's critical to know what kind of developer is making the quote. If by Ego double, if by fear halve... Then add 20% for Q/A, 10% for Technical Project Management. Next, add Client PITA factor, if client always hits you with lots of last minute changes add 40% else add 20%. This works for us :-) A few clients never deviate from spec and have a PITA factor of zero, but they are rare. Denying iterative processes is what kills most quotes in terms of accuracy IMHO.
Murphy was an optimist
My estimates are always perfectly accurate!
- Here's a good rule of thumb. If the discussion itself about an insignificant, super-simple easily implemented requirement takes longer than 5 minutes it's not going to be a super-simple rasily implemented requirement.
On my scrum team, if we were pointing a story during planning poker and the discussion about the pointing took longer than five minutes, the story was ineligible for being a 1 point story. Because you know all that arguing and back and forth about the color of a button won't stop once you've started work on it.
BeauHD,
So much depends on the time and expertise of the estimator. Some bugs are obviously, or soon determined to be, simple coding errors. Other times they reveal fundamental weaknesses in the controlling algorithm. A hunch is often enough for your 1st estimate, but too many times, a real investment of days or weeks is required to determine the scope of the correction. Shooting from the hip: invest as much time as you can get away with in the original diagnosis/estimate. If your hunch is wrong but you are lucky in spite of yourself, you will provide a solution during the "estimate phase" and maybe be a hero. Conversely, if you are too hopeful, you will be a dog (in your own eyes at least).
Note: from those of us who've been around long enough and humbled by particular experience, it can take serious amounts of time to even see the real==fundamental problem. Naturally, this is highly dependent on the complexity of your code base.
do you want to get paid when the project is done?
If you can afford to wait to get paid when the project is done, then become a consultant/contractor and bid your software projects appropriately (sans estimate, if you agree with the article).
But if you like getting paid every two weeks as an employee, then a manager has to be able to at least pretend that the work will eventually get done by a certain time and at a certain cost or the project typically won't get funded to begin with, thus schedules and estimates.
-- Reading the above, you might think I was a manager, but to be clear, I have never worked as a manager. I have worked as a software developer for Fortune 500 companies, tiny startups, and 100+ employees and as a consultant. I hate making development estimates but as long as I don't work for free, I don't expect those that pay me to not request them.
...for estimate time with a complex equation.
Point being software is not being developed the right way, but more like trying to do algebra with the roman numeral system.
its all about abstractions - http://abstractionphysics.net/
If you use a Scrum Sprint/Kanban hybrid system, it is possible to get a more accurate estimate of time. As a project manager I use to rack my brain trying to figure out how to use the Sprint or Kanban style to accurately give estimates. This system requires about a month (or 4 sprints) with of data, before it start to become useful, however in my opinion, pretty accurate.
Most of the developers were pretty good about giving a gut feeling on difficulty on a specific task, but awful at giving an accurate time frame for completing the job. So what I would do is ask the developers to break down a user stories (any task they marked as a 13), then go down the line and assign a difficulty 0, .5, 1, 3, 8 or 13; except I made the numbers more subjective in name,
- "Very Easy" (0 can be done less than 5 mins),
- "Easy" (.5, is a simple task), "small" (1, This task isn't difficult, requires other tasks be done first or time to develop),
-"medium" (3, this is a moderately difficult task, requiring r/d and time to test)
-"large" (8, this is a very difficult task that requires many hours of coding or testing or implementation)
The above titles per task are very subjective to the team of developer or individual developers as a whole. PM or Scrum Master should ask the collective to get an average on difficulty of task, based on who might be assigned the task or how much everyone agrees on the difficulty. Once you've marked the tasks and they've been assigned, you can now take subjective data and mark it against real data, creating objective data that you can use for estimates.
After 4 weeks (or sprints) of tracking time against each ticket, each developer and each team, you can start to pull data that will allow you to give time estimates. For each team and developer you end up with their averages (overall isn't as important as it is per difficult task), which will allow you to gauge how long a specific task or set of tasks will take.
Example:
This last week Bob completed the following number of tasks and it took him 40 hours to do so.
Last week:
Tickets
Easy: 6 Hours: 2
Small: 5 Hours: 7
Medium: 3 Hours: 16
Large: 1 Hours: 15
2 Weeks ago:
Tickets
Easy: 2 Hours: 1
Small : 7 Hours: 9
Medium: 1 Hours: 5
Large: 2 Hours: 25
Bob's Averages (time spent) per task size; rounding up: .5hrs avg
Easy: (20mins+30mins)/2=
Small: (84min+77min)/2= 2hrs avg
Medium: (960min+300min)/2= 11hrs avg
Large: (900min+750min)/2=14hrs avg
(the more data you get per week, the more accurate these numbers will be over time)
As you can see we have some averages for Bob's estimates, which gives us a basis for giving rough time frames. I found this to be quite effective, because some tasks that get marked Medium or Large end up actually being Small or Easy. When creating estimates, I error on the side of rounding up and depending on the developer and how many of each type of task assigned, will add 10-20% more time.
So if Bob has 15 tickets assigned to him, which are all Large difficulty and Bob only works 40 hrs a week, it will take him 5.5 Weeks ( 210 hours) to complete, provided he only works on those tickets. Now practically speaking, I'd NEVER assign that many tasks to one individual, but wanted to give an example of how this can benefit you. I alway try to Under Promise, but Over Deliver. I find this method gives a great metric for estimations and Managers alike. If a solid developer is starting to struggle and needs help or is distracted, we can now see numbers accurately.
Hopefully this makes sense, but I welcome anyone to reach out and ask questions.
I would assign 1 person to do all reporting, meetings, etc and they were not allowed to talk with or bother the hands-on developers. The developers were left alone, and not bugged about reports, meetings, etc .... just give them the goal and let them go. I'd informarmally chat with them every couple days, but the work was divorced from the reporting and vice versa. The work was completed on-time, within budget, as specificied.
For customer estimates, your company should adopt buckets like "small" "medium" "large" etc.
These are predefined in terms of developer and test hours, and any other resources.
A developer only needs to guess which bucket a project falls into.
Internal estimates can't be trusted until pieces have been broken down into days of work, not weeks or months.
Everyone here who talks about having to double their estimates, is working for a shitty boss.
How many other professions are routinely asked to estimate how long it will take to do something that's literally never been done before? And then be castigated because they were wrong. Of course this assumes that the requirement was specified (by the people doing the castigating) in enough detail to begin with, and we all know that's ALWAYS the case, right? Riiiiight...
Moreover, because of the RAMPANT ageism throughout the industry, the people with enough experience to even have a remote chance of spit-balling these tasks have long since been rejected and spat out by those eager to hire only inexperienced (cheap), new grads. Nothing wrong with those, but some kind of balance is the correct way to go.
The referenced blog post is correct only in total isolation, with maximized ignorance, and with zero experience. Most things in life are that way to a newbie.
But that should never be the case for an experienced professional, unless they are entering a completely new domain (which may represent a poor choice by management).
First, we don't want a single work estimate number (say "hours"). We want a range of numbers, or a number with error bars, indicating our uncertainty under varying conditions (team size, resources, etc.).
How do we get this?
First, nail down as many requirements as possible, create a draft WBS (Work Breakdown Structure), then apply the Johari Window to each requirement and WBS item, breaking all "known unknowns" down further, and assigning high priorities (and high risks) to the vaguest areas.
At some point, there will be items representing inexperience or ignorance that will be difficult to quantify in the work estimate. If they can't be bounded, then a separate effort should be launched to research them. I've seen many projects that died horrible deaths because nobody looked deep enough at the start. This is avoidable.
I used to resist doing architecture/design work during the work estimation phase, but I've since learned that strawman designs are a great way to map the current problem to prior experience. To reveal the steps or areas where developers are implicitly required to "make something magical happen".
This entire process requires having excellent historical data, and strictly avoiding SWAGs. Getting that data requires obsessive tracking and data collection on all projects. One key attribute of a great software team/project/product manager is the ability to find ways to get that data without pissing off the entire team. (Defense contractors take this to an extreme, though it seems to be used more to assign blame than to create better work estimates.)
As a contractor, I have walked in to projects, applied the above techniques, and have quickly been able to call "bullshit" on their tracking systems and estimates. I haven't always been able to make better estimates, but I've at least stopped teams from working to (and reporting based on) bad estimates.
I have been on projects that ran 6x to 8x over their initial work estimates. In every instance, project assessments/autopsies revealed "known unknowns" that could have been, but were not, identified and/or investigated at the start.
The above process does NOT apply to the R&D efforts launched to learn about poorly understood "known unknowns" that pop up during work estimation efforts. Any large project with significant "novelty" should plan to spin out some R&D projects along the way to creating the final work estimate. The budget for such work is assigned based on the risk of the specific research item to the overall estimate, not based on the work needed to answer the question. If you can't get a usable answer within the budget, then the entire project should be reconsidered.
I'm always asked by clients for a "firm" work estimate before starting a contract, and about 50% of the time I reply with a request for an initial contract (1-3 weeks) to do the work needed to generate that estimate. If management doesn't understand the need, it likely means this is a client I will choose to avoid.
BTW, creating useful work estimates for difficult or high-risk projects is an EXCELLENT reason to bring in a consultant/contractor, to gain an independent perspective, and access to their "BS detector".
Developers may well know how long a task will take, but we frequently see enormous pushback when we try to give realistic estimates. Too many PMs think the estimate process is a negotiation and that they win if they can get your estimate down. So, we give the estimates they demand, then laugh as the "deadlines" whoosh by.
From a dev perspective, there's little upside to fighting for better estimation.
I would say development time falls within powers of ten:
1) Nation-State scale applications: Windows, Linux, AWS, Apache => Tens of Billions in developer time to a usable product.
2) Flagship applications: Adobe creative suite, Microsoft Office, Quicken, AutoCAD, Chrome, Xbox Live, World of Warcraft => Hundreds of millions of dollars in developer time
3) Applications: Popular PC and Console games, Regular, boxed software = Tens of millions of dollars.
4) Utilities: Enterprise specific tools, Cloudberry, most mobile games = millions
5) Crapware and Scripts = Thousands to Hundreds of thousands.
That works best for when you're just computerizing an existing process, less well if you're trying to come up with an efficient computerized process.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
One of the best directors I ever worked for didn't know anything about software development, and knew he didn't know anything, but figured he could rely on us to fill him in on what he needed to know.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
First time poster here.
I built web apps for 20 years, and have recently shifted to a career in management. Having developers report to me for the first time in my life, I was concerned about the "estimates/actuals" problem, having personally experienced the awfulness of both corporate and agency life.
From an agency perspective,
- estimates were often taken as contracts, ie. this isn't a guess, you *WILL* deliver the functionality in the time denoted.
- this led to a culture of fear/overworking to meet unrealistic goals "committed" to (when in truth, no actual commitment was intended). Rushed/frazzled developers often made more mistakes, making late projects even later, further blowing their original estimates out of the water.
But, from a corporate perspective,
- developers were never asked to estimate (or management had given up asking?), because project failure often translated to "oh, this is just extra clean-up for DevOps"
- this led to a culture of minimal/zero developer accountability. Developers didn't track their time, and no-one held them to any standard. Over time, they took as much time as they needed, while the real (read: Stack Overflow-based) tech industry did laps around them. I contend that they stagnated or, worse yet, lost skill/ability.
For my first development team, I wanted to be sure I did not make these same mistakes, so:
- I *do* ask them to give me estimates, and I have them track their time (we use Trello).
- When I run month end reports, we look at their estimates/actuals (among other metrics) to look at issues where they were **way** off, get into the guts of the task, talk through what they did to come up with their estimate, what might have caused their actual to be so far off, and what they could do to narrow that gap.
That's not enough, however. I also:
- Insist that all task requests go through me, rather than the individuals on the team. *I* own delivery expectations, so I give the customers very wide margins on when they can expect their requests to be completed. It is **vitally important** that the customers themselves never inject their own lack-of-tech knowledge/communication problems/agenda into project management discussions, lest the "your estimate is now a contract" problem surfaces.
- **Repeat like a broken record** to the team that estimate/actual measurement is **not** (NOT!!) about spying on them/finding a way to write them up, but to expand their own knowledge of their tech craft and work to perfect it. This includes setting a fundamental expectation up front: I do not, nor will I ever, expect estimates and actuals to be 100% (which is definitely not the case with the customer!)
I've also worked with a data scientist colleague of mine to build a scoring system that ranks them, month to month, on their ability to be *consistently narrow* on their estimate:actual difference ratio (this is not the only metric, there's about five or six different metrics all at various weights), which challenges them to improve by seeing an actual number, and then doing what they can to increase it.
And yes, often it is like an adventure too.
If you're doing it right, you should never be doing anything twice. Anything you do should become a packaged and re-usable element that doesn't need to be coded again. I don't care whether you call it a subroutine, an object, or what have you.
Software development, done right, should grow exponentially--with a highly fluctuating exponent. No task should be predictable because no task should closely resemble anything you've done before. If it does, you shouldn't need to develop new code, you should just be able to re-use old code.
Well, OK, this is a gross oversimplification, but it does capture something fundamental about software development.
In the past I've found that managers almost prefer to do thing repetitively, over and over, the same stupid way. They love what is conceptually close to a duplication of the essentials of the last job, because although it's highly inefficient, it's also highly predictable. They would much rather have a near-linear curve of accomplishment versus time, then a much faster, but much less predictable exponential-with-fluctuating-exponent curve.
The typical manager would probably order you to recode the same thing ten times rather than "waste time" writing a subroutine.
(To be fair--it's hard to write a truly re-usable piece of code and easy to waste time in the name of re-usability and write code that isn't actually re-usable).
"How to Do Nothing," kids activities, back in print!
Estimating costs and takes time. Better estimates cost more and take more time.
If you want an extremely accurate estimate, build it and note how much money and time it took. This is not normally practical.
So, you stop short of going that far. How much short?
Nobody knows, and it varies from project to project.
If you want to know how much short, you could create a number of estimates, and noting how much money and time each took. And then build it, noting how much money and time it took, and compare that to your various estimates. Then use the estimate that has the optimal combination of accuracy, cost and time. This is not normally practical.
If only there were a better way.
http://duckducgo.com/q=agile+scrum
Of course, you could estimate
There's no time like the present. Well, the past used to be.
Track previous estimates and produce confidence intervals based on that. (E.g. http://help.fogcreek.com/7676/evidence-based-scheduling-ebs) When you do this you'll quickly discover that if a tasks are large (measured in days or weeks) the errors in the estimates are very large. If the tasks are small (measured in hours) there errors are much smaller. The problem is that even breaking the work down into small tasks requires a lot of time and design work, so you won't have a good estimate of the time needed for coding and testing until most of the design work is already done (without a good time estimate). This type of gradual closing in on an accurate completion date is common in many industries. The goal is to work towards having 50% uncertainty in the remaining work, so when you're 90% done, you can end up going 5% over, but not more than that.
Or, you can leave the scope of the work flexible. I don't mean going full "Agile", just have a small set of features that "must" be done, and a larger set of things that "should" or "might" be done. This helps because when you do the initial architecture you can focus on the parts that must be there, since anything else can be dropped if necessary, so you have fewer things to consider which means the design is easier. Then you alternate builds that add features and builds that fix all the bugs found in the previous features (but don't add anything new). As a result you very quickly have something that meets the minimum requirements so you can always meet the deadline, even if the deadline changes.
The reason some projects go from thinking they are 90% done to suddenly being 50% over is that they insist that every feature be included, but they don't even start the design work on the last feature until all of the others are done. This creates the illusion of chaos, when it's really just poor planning. There are always surprises in anything, but there are also a lot of ways most software projects can be better run.
Laconic version - Good, Fast, Cheap - pick two
Revised version - Good, Fast, Cheap - pick one if you feel lucky
--
Pray you will never have occasion to be a hero.