Ask Slashdot: Are Accurate Software Development Time Predictions a Myth? (medium.com) 222
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?
Yes, but... (Score:3, Insightful)
Try getting a contract awarded with "It's too chaotic to tell"
Re: Yes, but... (Score:3)
With clear, unchanging specifications on what is being built, than sane timelines can be given. When it's "smile and figure it out", than the timeline too is variable co
Depends (Score:2)
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.
Re: (Score:3)
If software development was "chaotic", then it would be overestimated as often as underestimated. But that isn't true. Overruns are way more common.
Here's a way to get better estimates: Instead of asking Bob "How long will it take for you to complete this?", ask Fred "How long will it take Bob to complete this?". By asking a 3rd party, you take away the hubris factor.
Re: (Score:3, Informative)
That doesn't work either, unless Bob is familiar with all the details of what need to be done, in which case your just as likely for it to be a "how long bob thinks it will take him" kind of answer.
I have literally seen estimates of "two days" to write a firmware device driver for a network card from a manager that regularly wrote code. In the end the guy that ended up doing it spent close to a year before it reached the level of "just works"
Re:Yes, but... (Score:5, Insightful)
The problem with software development is that unless you've done that exact same task before, you really have no idea what's involved. And if you HAD done that exact task before, you wouldn't need to be doing it again, as you could re-use most of your previous work. Unlike with, say, constructing a building, once software is well-built once, it doesn't have to be built a second time, at least within the same company, or if its open source.
Management is also to blame on occasion. I put together a schedule for a videogame project for a major publisher, and the schedule was rejected, saying it wasn't detailed enough. They wanted finer-grained breakdowns of tasks, so instead of one to two week tasks, they wanted one or two day tasks. The only problem: the game wasn't even designed yet - only a rough idea of the genre and licensed property we were using. So, someone (not me, thankfully) dutifully put together a bullshit schedule with fine-grained bullshit tasks, and as the due dates arrived, we simply checked off those tasks in our official project management software.
In the meantime, we had our own spreadsheet with our real tasks and timelines that we used internally, although we tried to match up major milestones as best we could. Since it was a hard deadline, we finished the core game systems as soon as possible, ruthlessly cut extraneous features, and still delivered on time. I'm sure the publisher's producers still think it was their detailed scheduling that kept everything on track.
Re:Yes, but... (Score:5, Insightful)
This is exactly right. Unfortunately so many people think that constructing a building is a good analogy for "constructing" software, and think the same methods and ability to schedule in detail apply. It's the worst analogy. A better one is, making a schedule for the invention of a flying car. You know exactly what you want it to do, but you don't know how you'll make it happen yet, and you certainly don't know the exact date when you'll have it all figured out.
Re: (Score:3)
The asymmetry of mis-estimation is partly explained by a sort of optimism.
Our instinct is to plan for no obstacles/distractions/complications, where in reality it's rare for work to proceed in this way.
Another cause is that (as Dutch Gun points out) often in software development, you've never done a task quite like that before, so you can't draw directly from past experience.
Re:Yes, but... (Score:5, Informative)
partly explained by a sort of optimism.
Well, maybe a little, but I think it has more to do with every request for an estimate being something along the lines of, "I'm not really sure what I want, and I need you to estimate it, but the budget only allows for two weeks, so you should probably not say anything more than two weeks." When we're young, this freaks us out, and we try to talk them back from the brink of insanity and get them to see that this is definitely more complicated than two weeks, but they beg, bully and cajole until you break down and agree, certain that you're going to be fired (from your first job!) after just two piddling weeks. So you put together what you can, it doesn't work, two weeks pass, you keep working, nobody fires you, nobody even notices that you slipped the estimate. You keep working on it, the boss keeps asking "is it done yet", you get really good at apologizing and explaining that the network didn't work the way you thought and the new version of the database is different than the old version in undocumented ways, and a few more weeks pass and you get something working, and they say it's shit, and you go back and make a bunch of modifications and they keep asking is it done yet and you keep apologizing, and three months later you actually have a decent working product, and nobody fired you, and the company didn't go out of business because you blew your estimate by a factor of 6 and everybody actually seems reasonably happy.
And then they come you and say "I'm not really sure what I want, and I need you to estimate it, but the budget only allows for two weeks, so you should probably not say anything more than two weeks." And you start to protest, but then you remember last time, so you say, "yeah, sure, two weeks, whatever dude," knowing that it doesn't matter and gradually coming to the realization that you're just playing a game whose rules aren't written down anywhere, pretending that you can deliver anything in two weeks, knowing that they know you can't, but both of you are playing a game of chicken at the end of which nothing happens.
And then after lather-rinse-repeat for 30 years, you go on to slashdot and you tell the young kids, "just give them the number they want to hear, nobody takes estimates seriously anyway" and some loudmouth PHB who figured out how to turn on his computer replies back "they're going to offshore all of you if you don't start producing accurate estimates because there are real-world consequences for missing dates" and you shrug your shoulders and go back to work because you know that the offshore people can't estimate any better than you can and the only people who insist that software estimation is realistic are the people who wish it was realistic, not the ones actually expected to produce it.
Re: (Score:2)
"Here's a way to get better estimates: Instead of asking Bob "How long will it take for you to complete this?", ask Fred "How long will it take Bob to complete this?". By asking a 3rd party, you take away the hubris factor."
That *is* exactly how it's done, which is proof it doesn't work either.
Usually the estimate doesn't come from asking Bob how long it will take to him, but some third party (a sales manager, Bob's technical manager...).
Re: (Score:2)
How do you know overruns are way more common? Your sample set consists of two sources of samples: personal experience (and you might just be a bad planner), and events reported in the press (and 'project finishes on time, on budget!' usually doesn't get reported).
I'd like to see some numbers before I believe that statement.
Re: (Score:3)
It isn't hubris.
I can estimate fairly accurately. But Management/user grimaces and says "It can't take that long, All You Have To Do Is..." and forces me to chop it in half.
Then when it takes twice as long as the accepted estimate, it's My Fault.
I allow a fudge factor in my estimates. Even the simplest projects almost invariably develop complications. Plus I know that a good deal of my time is going to be spent in one small module finding that misplaced comma.
Re: (Score:2)
If the chaos resulted in reduced scope about as often as it resulted in increased scope, then you might well see symmetry in the over-/under-run of estimates. It's far more common for new features or unforeseen requirements to be added to the scope of work than for anything to be removed.
There's chaos in the development process itself that results in some things taking longer or shorter than initially expected. The external chaos of shifting requirements turns what happens during development itself into a
Re: (Score:2)
Try getting a contract awarded with "It's too chaotic to tell"
The other key component of a contract is defining a budget, which gets blown when timelines inevitably become "chaotic".
Perhaps the real myth that is being identified here is defining an accurate budget for software development.
This always worked for me... (Score:5, Interesting)
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
Each dev consistently off by a constant factor (Score:3)
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 ten
Re:Each dev consistently off by a constant factor (Score:5, Interesting)
Re: This always worked for me... (Score:3)
That's pretty close to what I've found too.
Something that will take 2 days really takes a week. (2.5)
Something that will take 2 weeks really takes a month. (Also 2.5)
Even short projects seem to fit this 2.5 number where something that is suppose to take 2 hours generally takes half a day.
The job itself actually only takes 2 hours but the debugging, testing, feature creep, and making it live always seems to more than double the time.
Re:This always worked for me... (Score:4, Funny)
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
HA. You have no experience in management obviously. Here's how I do it:
Take the developer's estimate
Tell them it's too long
Halve it
Tell the customer
Project gets behind
Start the death march (60+ hours for everyone but management, we have families!)
Project gets behinder
Customer is pissed, but doesn't really have any other options
Project comes out OK, but is much later than even the original estimate that was halved
Customer is happy, management is happy, engineers are disposable
Go to Hawaii with my bonus!
Re: (Score:2)
This was modded "funny"; should be modded "cynical but true"; all the contractors around these days seem to use some variant of this technique.
All of them. Onshore, Offshore, the lot.
Re: (Score:3)
I use "double it and add 30".
The nice thing about this rule of thumb is it also works pretty good for converting Celsius to Fahrenheit.
Re: This always worked for me... (Score:3)
My company does something similar.
Basically just triple whatever estimate we come up with.
This comes with a huge benefit: If it turns out we over-estimate, the client is happier with an earlier finish date, or we can put a little extra time/effort into something that just didn't feel as polished, and the client got an even better value for their money.
We also have a policy to not bill over our quotes, so over-estimating is crucial. It holds us accountable so we don't bleed our clients and create bad blood.
Re: (Score:2)
My company does something similar.
Basically just triple whatever estimate we come up with.
This is basically what we do too. The problem I see with this approach is it prevents you from getting better
at estimating. If you as a developer triple your estimate to compensate and the manager then triples that
number, the number is artificially tripled twice. I've tried slowly increasing my estimates so that they are more
accurate but then people balk because when they take my more realistic number and triple it, it looks to be
too much compared to previous projects even though everyone knows the previ
Re: (Score:2)
If you're the kind of person who is consistently late, then your manager already does this without telling you.
Re: (Score:2)
while doubling the entire amount allows for the customer seeing the first result and _then_ telling you what they really want.
You are handling scope creep wrong. Agree the scope then estimate and charge appropriately if they wan't to change the scope you re-estimate (Including for backtracking and scraping existing work that has already been done) and then charge them again.
Rince and repeat
Re:This always worked for me... (Score:5, Insightful)
Back in the old days, we would simply tell our managers; "We will make it and then, we will tell you how long it takes".
Re: (Score:2)
Nowadays, we do team voting on sprint planning stories to come up with a more educated guess as to how long it will take to complete something. We then debate and come up with complexity estimate, which seems to be more accurate than random guessing from management.
Unfortunately, we don't really follow the scrum rules properly in our organization. Management now shows up during the planning meetings, and they chronically undervotes on the complexity of tasks in order to cram more overtime work into the spri
Re: (Score:2)
This is awfully close to the rule of thumb we used. Take the estimate and multiply by 3.
Seemed to work anyway.
I think if you all keep testing this, you will find you converge on PI.
Re: (Score:2)
the Mythical Man Month (Score:2)
Re: (Score:2)
screw around and look busy
I already know I'm going to be doing that ahead of time, so I start out that way.
engineering estimates in the future (Score:5, Insightful)
Mr Scott, have you always multiplied your engineering estimates by a factor of four? [youtube.com]
Oh, laddy, you got a lot to learn! [youtube.com]
Yes, inherently unpredictable, needs percentages (Score:5, Insightful)
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.
Re:Yes, inherently unpredictable, needs percentage (Score:5, Interesting)
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.
Re: (Score:2)
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...
Re: (Score:2)
*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
Re: (Score:2)
Re: (Score:2)
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.
Tracking weeks works better than hours (Score:2)
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 lon
I Have No Trouble Making Accurate and Precise... (Score:3)
...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.
Re: (Score:3)
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 p
Re:I Have No Trouble Making Accurate and Precise.. (Score:4)
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.
Re: (Score:3)
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.
Re: I Have No Trouble Making Accurate and Precise. (Score:2)
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 actual
Re: (Score:2)
Indeed. Many PHB's have to learn the hard way:
"Who knew healthcare would be so difficult?"
You can get close, but it isn't easy (Score:3)
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....
Re: (Score:2)
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.
I was always taught to estimate HOW you are going to do something, not WHAT you are going to build. If you start with a block diagram with 8 blocks and your work breakdown structure has 8 major headings you are probably going to get rubbish estimates. Building those 8 blocks and connecting them up probably involves 20 macro-level steps. Many of the developers I've seen get this wrong don't think through HOW they will build the final state they are trying to get to so their estimates miss a lot of stuff.
Re: (Score:3)
Good point...
In my 25 years of doing this, I can tell you that the most often used way to estimate a project basically boils down to "How much can we get the customer to pay?" Time and time again I've sat though meetings where the sales person kept saying "we won't ever win the contract with that bid" followed by an order from the executives to bid lower. One time the executives took our estimate, subtracted 2/3rds of it and submitted that as the bid over our objections. We won and I quit as soon as I c
Valid Exception to Betteridge (Score:2)
Yes.
The title is one of the few instances where Betteridge [wikipedia.org] is wrong.
depends on quality of inputs (Score:3)
Progress Bars (Score:3)
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.
Sorta, but... (Score:3)
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.
Not just software. (Score:3)
Performance predictions have an optimistic bias.
It's known as the planning fallacy [wikipedia.org]
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.
Re: (Score:2)
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.
Hopefully it will take less, because this time I will be able to take the code I wrote last time and just re-use it, possible with some minor modifications, rather than designing and implementing it all from scratch.
(Or if I can't do that, then either it's a new task and there wasn't actually any "last time I did it", or I did a lousy job last time of designing my code to be re-usable. Software development is mainly about automating previously manual processes so they can be repeated more quickly/easily in
The hardware is the problem (Score:2)
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? Y
catch-22 (Score:2)
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.
preexisting malaise (Score:3)
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.
Fired (Score:2)
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.
Re: (Score:2)
I would've potentially felt some sympathy, but the gofundme part certainly smashed any chances of that. Sad thing is, a highly paid contractor who gets himself terminated from a contract will likely raise 100x more with his gofundme begging than a street bum who actually needs the money will get.
Solved problem (Score:5, Informative)
https://www.joelonsoftware.com... [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.
Add six weeks six weeks (+/- two weeks)... (Score:2)
Hofstadter's Law (Score:2)
Remember Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
The solution (Score:3)
Re: (Score:2)
Scheduling - It depends! (Score:2)
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.
Re: Scheduling - It depends! (Score:2)
Exactly. An Android developer might know something is 'easy', but forget that it's only easy due to a new API that came out 3 years ago, but is STILL 1 or 2 versions ahead of the minimum version of Android for which the customer demands compatibility. Sometimes, it might be merely 'hard' to achieve something with an older version (ex: pdf-rendering, which didn't exist as an Android API until Lollipop). In other cases, it might be borderline-impossible to achieve with older versions... for example, low-laten
Re: (Score:2)
I've made some fairly good predictions (Score:2)
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
OP fired because of this article (Score:2)
TLDR: lost my job for writing this article
you can donate here: https://www.gofundme.com/lost-... [gofundme.com]
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
Re: (Score:3)
Legally, it's a grey area. If your employment contract has morality clauses, for example, you can be punished for things done outside of work. However, usually that is limited to situations where your contract explicitly states it, which usually happens when working for religious institutions (or, occasionally, schools). You can also be fired for actions that reflect badly on your company, but that assumes that A. people know the author works for that company, and B. they have reason to somehow connect
I DONT CARE (Score:2)
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.
Not really a new problem (Score:2)
Re: (Score:2)
It's tough to make predictions, especially about the future. -- Yogi Berra
Tasks, Effort, Complexity, and Risk. (Score:2)
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.
Are hurricane track forecasts a myth? (Score:2)
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.
A Microsoft Example (Score:3)
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...
Yes (Score:2)
This method never fails (Score:2)
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, a
A strategy that seemed to work... (Score:2)
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 d
Can only be acieved with the "Scotty Method"... (Score:2)
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.
what makes software special? (Score:2)
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.
Accurate planning can be done, if taken seriously (Score:2)
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) ev
Yes, because... (Score:3)
My method is infallible; (Score:2)
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.
no plan survives contact with the enemy BUT (Score:2)
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 [forbes.com])
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 so
The problem is feature creep not estimates (Score:2)
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 tea
No, it isn't a myth (Score:2)
Re: (Score:2)
And here it is. I was hoping to find someone saying it.
Back when I was yay tall, I worked for a large web-development company. They'd spend six months to a year to draw-up a spec document that would take us three weeks to build. I quit when I found out that they spent $1.6 million dollars (this was in 1997) on the spec process alone.
Now I run my own small web development company, doing much larger things than they ever did (right from the start), and with good clients, time estimates are never more than
Which people? (Score:2)
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
Good rule of thumb (Score:2)
It takes time (Score:2)
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.
Done right, it SHOULD be unpredictable. (Score:3)
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).
Re: (Score:2)
It's:
a) Betteridge's law of headlines.
b) not a headline per se.
Re: (Score:2)
Re: (Score:2)
Re: (Score:3, Insightful)
Yip, generally it's easy to make an estimate for a clear specification. But, customers rarely know what they REALLY want until they see something in production. This is a very common problem. I don't know any easy solution to that: mind-reading machines don't exist.
One partial solution is for the technical analyst to become a domain expert first. But obviously this is often not pract
One great req solution I was taught, and a backup (Score:3)
> 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
Re: (Score:2)
projects where requirements were laid out in advance (via requirements documents)
Of course, the process of laying out the requirements in advance via requirements documents took twice as long as the actual project itself, and THAT process was chaotic and unpredictable and nobody knew in advance how long that was going to take, but the actually coding part was predictable so in somebody's mind, that was a "win".
Re: (Score:2)
Neither of them are actually CS problems.
I disagree that estimating cost is critical (Score:2)
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 h