What tools or techniques do you use to come up with estimated time of software development?
10 01 Dec 2016 21:20 by u/rms_returns
From what I've researched until now, the EBS (Estimates based scheduling) seems to be a sound methodology used by most in the industry (including StackOverflow founder himself).
Are there any tools or software to track time for EBS? What other methods do you use to come up with the estimates?
9 comments
6 u/ilovepussy 01 Dec 2016 21:45
Software development time formula:
Total Time = (PX)+(CR)+30%
Where:
P = Programmers original estimate
X = Number of executives involved in the project
C = Changes
R = Number of people requesting changes
Usually this results in a 4 month overrun as last minute changes are not included in this formula.
0 u/omegletrollz 02 Dec 2016 15:15
Now do the formula for determining
CxD2 u/tame 02 Dec 2016 18:50
3 u/tame 02 Dec 2016 00:18
I just break the project down into chunks that should take more-or-less a day to implement. Any chunk that I'm not confident can be done in a day gets subdivided. Then add up the chunks and that's how many days you think it'll take. Double that number, and that's what you tell the project manager. Double it again, and that's what you tell the client.
So far it's worked out to be pretty accurate, at least on short ( < 2 week) projects. :)
Edit:
0 u/omegletrollz 02 Dec 2016 15:21
That is a good technique for short projects yes, very interesting but it is unlikely to work if you're developing as a team with complex prerequisites and orders for tasks of various phases (architecture, testing, etc). Not that it can't help but it just seems really simplistic to tackle this sort of scenario.
Finally, it is pretty much worthless for long-term projects. If you even go to the trouble of chopping it all up into day-sized chunks, you'll still come into the scenario, most likely that the client will ask for some changes or someone gets sick, or you find out that a certain piece of the code isn't going to run fast enough or support some of the later tasks in a good enough way, leading to rework. This is why there are scores of books written on management for large projects. It really isn't that simple.
-1 u/tame 02 Dec 2016 19:35
Well, "this sort of scenario" was actually a request for time-tracking tools for EBS, so it's tangential rather than simplistic.
That aside, having read your description below, you've basically called my rough-and-ready yet effective method "worthless" and yet you haven't actually offered any alternative. Sure, we both know that the reality of software development is that usually requirements will change every few weeks, and any estimate on a longer timeframe is pure bollocks and marketing. But when you're dealing with "real" engineers who build big, expensive, physical objects, you have to be able to quote on delivering a large system to spec even though it will take months if not years to build and the spec will change.
If a mining conglomerate comes to you and asks "how much to build a SCADA system for this minesite that we sketched on the back of this napkin" you need to come up with a number to charge them, and it has to be more than your build cost and less than your competitors' quote. If you say "I provide software development as a service" they'll tell you to fuck off, their in-house team does that. These mining lads don't sugar coat it. And you don't want that, because the kind of margin you can get on this job will buy your company a new office block.
So you come up with your best guess (and there's no point going finer-grained than a day's work, because of the inaccuracies you mention) and then you add what seems like the right margin on it, and you take your chances. And speaking from decades of experience (my own and others') a ~4x factor is about right.
Agile is currently very effective across much of software dev because nobody actually knows what they want their software to do. Agile is a benevolent Trojan horse which injects a dose of R&D methodology while looking like an MBA-approved linear business strategy. Don't forget, though, that there are large (and growing) fields of software engineering where you are required to solve well-defined (if complex) problems in a well-defined manner and produce well-defined results. At which point it's no longer a search through unknown territory but a Simple Matter Of Programming and you shouldn't be designing via R&D.
3 u/omegletrollz 02 Dec 2016 15:35
On a larger scale, I do agile methodologies. Any project for me sits somewhere between a week and a month. Anything requiring more work becomes the next phase and a new project of its own.
If the client asks me "but I need to know how much it will cost on the long run" or "I need a baseline for the finished product" then I tell him that I'm sorry I can't help him and that anyone who actually provides him with answers for these questions is either outright lying to please him and get the job or is so ignorant about software development that he actually believes his estimate will work out. If needed, I will show him the annual industry reports from big shots like IBM and Microsoft that prove long-term estimates are wrong most of the time and often by alarming margins - let alone Joe the neighbor guy who my client has talked to before. I also recommend that he never agree to a long-term contract like that because agreeing to a timeline and certain set of features from the get-go often will prevent him from changing ideas midway and modifying the project towards an optimal outcome during its progress. He may get what he wanted but maybe he won't like it.
If the client still demands that I give him an unique price and duration for the project I tell him that I'm very sorry but my work is a service, not a product. You can't go into a store and buy "one custom software, please". It's more like hiring a private teacher and paying a monthly fee until the student is ready. I sure can give you a estimate of what I can do in the next 2 weeks but not anything much longer than that. If the guy still doesn't feel comfortable, good riddance - the kind of guy who wants an immovable price tag is often the kind of guy who will make all kinds of moves on you when you deliver the project. "I know I didn't ask for a print version of the reports but what good to me are reports that can't be printed?!" And will never show you the color of money until they twist and turn everything they can short of you opening a lawsuit against them... or even never pay you, it happens! I know for a fact that is not the sort of client-base I want to build for myself.
Regarding actual agile methods of estimating development, there is a lot of info you can find on Wikipedia alone and even in cheap books that would do them a lot more justice than I ever could here.
0 u/roznak 02 Dec 2016 19:18
Software estimation does not work, it never worked and it will never work.
And the reason that I cannot be predicted is because you are doing something that has never been done before and will never be done again.
0 u/Master_Foo 04 Dec 2016 00:36
My metric is,
Then I toss the tables and tell the marketers to get the fuck out of my Temple.
Schedules are ropes for pointy haired bosses to hang themselves with. Smart programmers don't play that game. The only truely useful metric is
If the answer is yes, then "It will be done when it is done" is a completely reasonable answer. Want it to be done faster? OK, don't worry about how much time it will take. Worry about how much stuff needs to be done. Is that particular module really necessary for a minimum viable product? No? OK, then take it out.