Slashdot Mirror
The Programmers Who Want To Get Rid of Software Estimates
An anonymous reader writes: This article has a look inside the #NoEstimates movement, which wants to rid the software world of time estimates for projects. Programmers argue that estimates are wrong too often and a waste of time. Other stakeholders believe they need those estimates to plan and to keep programmers accountable. Is there a middle ground? Quoting: "Software project estimates are too often wrong, and the more time we throw at making them, the more we steal from the real work of building software. Also: Managers have a habit of treating developers' back-of-the-envelope estimates as contractual deadlines, then freaking out when they're missed. And wait, there's more: Developers, terrified by that prospect, put more and more energy into obsessive trips down estimation rabbit-holes. Estimation becomes a form of "yak-shaving" — a ritual enacted to put off actual work."
Business can't plan or talk to customers or have any strategy whatsoever without at least some estimate...that's just the real world. If devs don't give estimates, managers have to make estimates. If managers don't make estimates, business makes estimates. You want devs to do the estimating.
Estimating is a crucial skill for developers. If you don't have it, you'll make bad decisions. For example, answer the question, "should I use framework A, or should I write some code myself?" If you can't estimate how long it will take to use the framework and compare it to how long it will take to write the code yourself, then it is impossible to make a realistic decision. Similarly, "should we write the code using method A, or write the code using method B?" If you don't know how long they take then you can't make good decisions.
This is a trick I learned from agile (although I'm sure it's been around longer than that). Each time you make an estimate, pay attention to how accurate it was, then next time adjust and make a better estimate based on that. Estimating shouldn't take much of your time.....if it does, then you're doing it wrong.
These guys seem to be complaining that their managers aren't doing anything with the estimates. Which probably means they don't understand what the managers do (but it could also mean their managers are bad).
"First they came for the slanderers and i said nothing."
One would hope that a good manager would have enough practical and direct experience in writing software to at least come up with a half-decent estimate, no?
Most shops I've seen lately have the scrum masters spend a part of a planning session simply asking individual contributors "Here's a rough outline of the proposed project [...] now how long do you think doing that will take", and they come up with an estimate adjustment from there... most of the time, it's fairly close. PMs pad things a little of course, but the results tend to be fairly close.
YMMV of course... depends on who is posting the final estimates - is it devs, or is it the MBAs.
(If it's the latter, run like hell.)
Quo usque tandem abutere, Nimbus, patientia nostra?
I've worked on a lot of software projects that delivered the original specified product on time. Sometimes the target changes, and the stakeholders need to be willing to give developers the extra time they request to meet the new objectives. Too often I hear, usually from upper managers, "We are still shipping on schedule. Tell the developers to work harder." Of course, that's not realistic, and the result is a predictable "failure to deliver." Alas, the developers get blamed, when it's really management's fault.
On the flip side we have so-called "agile" development teams who simply define a deliverable as whatever they've completed on delivery day. These developers rarely tell management until the 11th hour that what they're going to deliver is below spec. Agile development has its strengths, but this aspect is a giant weakness. The solution is not to eliminate schedules. It's to adapt them to changing conditions and be proactive about slippages.
People do not predict well and it is not smart to use it against them.
You can improve. Most programming we do is boring, and similar to something we've done before. For things like that, you should be able to make your estimates reasonably accurate.
Sometimes projects have large unknowns, and it's impossible to know how long it will take. In that case you need to propagate that information up to the people who need it, either managers or salespeople or whatever.
"First they came for the slanderers and i said nothing."
...Software project estimates are too often wrong, and the more time we throw at making them, the more we steal from the real work of building software...
...developers' back-of-the-envelope estimates...
From the above two quotes, it looks as if the author does not even know if too much or too little time is spent on estimates.
.
No wonder his managers are frustrating with the time estimates provided. The guy has not a clue.
Programming is basically research and development You are building something which has never been built before. As such how do you estimate something if you have nothing to compare it to?
Actually though I have a limited amount of experience using Function Point Analysis. Some of the aspects of it are old, it was created before web apps became pervasive, but that doesn't matter. The principles are the same and there are dimensionless constants you can use to tune the FPA model to your organization. Eventually you end up with an empirical model of your programming team, development environment, tool suite, management efficiency, complexity of the problem domain, people quitting or dying, etc. You need to avoid over fitting however and recalibrate from time-to-time.
Agile keeps story points and velocity which serve the same purpose as the dimensionless constants of FPA. Unfortunately managers try to translate them to mythical man hours. But if you keep velocity or function points, whether you are using Agile or not, you should be able to get some idea. You have to be a bit scientific about it.
That and 'T-Shirt Sizing' is about as good as it gets.
putting the 'B' in LGBTQ+
I've seen that sort of thing used fairly effectively. If you keep track of how long past projects took, it's fairly easy to estimate a new project based on an estimated ratio of how complex the new project is compared to the most similar past project(s). This takes practice and a bit of a knack to do well, but it doesn't take much time, and it's certainly better than nothing.
What doesn't seem to work well, in my experience, is breaking down a project into microscopic detail and individually estimating each detail, e.g, the "Microsoft Project" approach. I can understand the appeal of that sort of thing, but it's almost impossible to use a data-driven approach at the microscopic detail unless you use some sort of "Personal Software Process" tracking tool - which very few people want to actually do because it feels like you're instrumenting yourself as a lab rat in someone's twisted experiment.
In any event, having a plan and a schedule, though inevitably imperfect ones, helps motivate everybody and helps keep things on track. The more enlightened managers of the world will allow these things to be revised along the way as needed, as their imperfections get revealed.
On the one hand, it's pretty much impossible to do any project planning with no estimates.
On the other hand, some things are impossible to estimate until you do them.
Years ago I worked with a manager who kept repeating that bad estimates were a project risk and we should give good estimates. We kept telling him that an estimate is, by definition, based on incomplete knowledge and before you have done the work and that if he had a time machine we could give him better estimates.
If I knew exactly how long it would take, and what unforseen things I'd be running into ... it wouldn't be a frickin' estimate, now would it?
People treat estimates like you're expected to have perfect knowledge of the future, and then build their world around those estimates.
I have seen a tremendous amount of bullshit and stupidity from people who do not understand what an estimate is, and how it's done.
I don't think you can get rid of estimates entirely ... but management needs to stop being so stupid about how they interpret them.
If we could tell you for a fact exactly how long it would take, it wouldn't be a fucking estimate.
I rank how people do estimates right up there with how some PMs want you to track your time ... once had a PM say he wanted me to account for my time in 5 minute increments. And I told him in no uncertain terms that would mean 2 out of every 5 minutes would be spent documenting what I'd done the last two minutes, and there would be an additional 1 minute of lost time in each 5 minute increment doing to context switch back to what I was working, and that effectively 60% of my time would be wasted on his stupidity.
And then I told him to piss off.
Lost at C:>. Found at C.
Part of being a software professional is understanding how long it takes for you to do things
If you don't know how, go read a book. It's not hard. The money that's used to pay you depends on your estimate being somewhat correct.
Imagine how upset you would be if you asked for your paycheck, and payroll said "we're not sure when we're going to pay you, but it should be sometime soon."
If non-trivial problems could be solved within a guaranteed time frame, then you'd have already have a doorstep delivery date for your starship. Good management can make sure that core features are delivered on a schedule and help ensure that the schedule is not actually impossible to meet. If the schedule is not lenient enough, then the best management in the world can not guarantee delivery while also providing a guarantee for stability, security, and performance. Were this a simple matter, then the service of software development would not be worth so much.
You have three choices. You can give me enough time to finish the project correctly and receive an awesome result, but you will pay for that extra development time. You can give me too little time to deliver a quality result, but you will pay me for patches. You can give me too little development time and opt out of paying for updates, but you will pay for it when there are problems. Choose well.
There's a very old, very over-used saying about technology that people must be forgetting. It comes with three possible qualities: good, fast, and cheap. You may choose two.
No, it's a very common problem in engineering in general, and not unique to software. But the reaction "let's eliminate estimates" appears to be.
As an engineering manager, I learned the hard way many times how estimates turn into deadlines. Your estimate is reported to the manager's manager and so on up the line, and someone uses it in planning their shit.
Your estimate, in which you did not build any schedule margin, then becomes an item in the critical path of someone else's plan, someone who didn't build in any margin either, or —worse— who was pressured to make a completely fictional "plan" which is really just a backwards-calculated paper justification to "prove" that a job could be completed in an impossibly short period of time by assuming nine women can make a baby in one month and things like shipping, reproduction, and quality assurance take place in zero time. This "plan" makes upper management happy. Temporarily.
You, leader of a small team that is working merrily away, accomplishing real work and solving the occasional unexpected problem (OEM pinouts were wrong, widget zeta delayed in shipping, amplifier stage behaving like oscillator, etc.), are asked for a status update. Because of your unexpected problems, your estimated completion date is now two weeks later than your previous estimate.
Now the middle manager, who knew he wasn't going to meet the "plan" he was forced to develop, now has someone to place the blame on. He knows he's going to be in the path of a metric fuckton of shit, but he's placed himself uphill of you.
It's clear even in TFS that the real problem isn't estimation, it's poor program management, lack of requirements management, and often also marketing-driven decision-making.
In other words, the same old shit.
I can see the fnords!
Then something changes and blows the estimates out of the water. But the MBA's think since only one line in the spec changed, the schedule should stay the same.
Holy crap! Are people actually buying into this BS?
Software coding/design is similar to solving a maze -- you just can't give an accurate estimate how long it will take to solve the maze.
WTF? Yes, you can give an ESTIMATE on how long it'll take to solve a maze. Go get a book of mazes; Do 10 of them; Time yourself for each one; You now have min, max, and average times for a maze of that size/complexity. Next time someone shows you a maze, you can make an educated guess about how large/complex it is, then give your best case, worst case, and normal/average estimates. Do the same for programming.
Estimates are good for repetitive or non-creative tasks...
They're also good for creative tasks. I went to college with a major in fine art and worked for years as a monument engraver (etching portraits/landscapes/etc on tombstones). If someone asked about how long it'd take to etc a 5x7 portrait, I'd have a VERY accurate estimate for them. Is that not creative enough for you? How about every single project for every single class for every year of art school? ALL of those had timelines, and every student became quite good at estimating how long each project would take so they could get them all done on time. And you could ask most of them (at least those with higher than a B average) how long it would take them to do a certain thing (ex. sculpt a bust in clay from a live model) and, if they were familiar with that medium, then they could give you a very good estimate.
Estimation in the software world is a scam perpetuated by managers and management to get developers to work extra hard.
If management is asking the devs for their estimate, then how in the hell is it management fault for any of those timelines? Let me put this another way... devs, BE SMARTER. You've been asked for estimates on more than one occasion. Most that are new to development will low ball (stating a best case estimate). If/When you do that, you're just setting yourself up to fail. The best outcome will be that you are on time, and every other outcome sucks for all involved.
If you're not good at estimating, just try, come up with your figure,then double or triple it. If you always come in under the estimate, then you manager may start adjusting your estimates... who cares? Let them. It's their fault if you don't meet their manipulated figure. However, if you're not giving a large enough estimate in order to get your work done, then it is YOUR FAULT if you fail to hit your own estimate!
All that said, there are cases where providing an estimate is unreasonable. On one end of the scale, if a manager is asking for very accurate down-to-the-hour estimates on vague but somewhat small tasks, then it's asking for too much (almost more work estimating doing the damn thing). On the other end of the scale, if it's some grand idea for a giant project with no plan yet, you'll be pulling figures from your ass just as much as he's pulling the project plan out his ass... but it is what it is. Just go big.
A lot of it is just about setting expectations. If you give them high estimates, then you're more likely to meet or exceed their expectations. They may dislike the figure at first, but when you come in under budget they will be very happy and forget all about how high the estimate started out. A high estimate is not "padding", it's setting expectations that you can meet (see the maze estimate above... use "max" and you'll be able to meet or beat your estimate every time, which is what all involved really want out of your estimate).
When I have one of those... I just say - well, if it should stay the same, why don't we just change that one line back. There's no difference according to you.
The cesspool just got a check and balance.
No. That is the whole point, which you have seemed to miss. I'm the software engineer and even I can't come up with a reasonable estimate; why the hell would some manager several layers of indirection distant from the design be better at it?
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
The difference between software and mazes is that with mazes you are doing the same task every time.
I know, for example, that I can take cold iron and have it running most of what makes it a useful production server machine in about 4 hours. I'll sign my name in blood on it. Because I've done that same task over and over.
On the other hand, software is a creative work and creativity implies that you are NOT doing the same task every time and that at best you are guessing.
The problem is, everyone else is second-guessing, and they're guessing wrong. And they often will not accept a realistic estimate. They'll push for a "realistic" estimate, then blame you when you cannot meet it.
Actually developers guess wrong too - they usually think it's going to take half the time and work it really does (based on stats I've seen). But developers could simply allow for that by doubling what they think.
Except that in many cases, as I said, they cannot resist the pressure from outside.
Exactly - that is why there was been a growing recognition that Agile isn't getting the job done. At my last company a bunch of Agile zealots came stampeding my way trying to say that we had to change all our development processes to be "agile" because, well, just because. So I went through a simple requirements exercise with them. The first and foremost requirement is that when sales/marketing sales that they want 100 features in the product and there is no way that we can doo all 100 features, we have to be able to prioritize them. One of the primary factors in prioritization is looking at the effort/reward ratio. Something that is little effort but has a big payoff is high priority. Something that is big effort with little payoff is low priority. Now, please tell me how Agile is going to tell me how much effort is going to be required to complete a particular project when the whole Agile approach is to start coding and figure it out as we go?
silence
OK, here is another requirement. We need to put together timelines because Engineering doesn't operate in a vacuum. We are part of a company with many parts all of which have to be coordinated. Sales needs to be able to set expectations with customers. Marketing needs to make plans for when and how to introduce features to the market place and make forward looking statements on upcoming features. Support needs to plan out how it is going to support upcoming releases, which requires logistics in terms of when to apply which resources to which tasks. So how does Engineering give people these timelines if we don't take the time up front to plan out what we are doing prior to banging on our keyboards?
silence
The big problem with Agile is that it was created by Engineers in a vacuum who failed to recognize their responsibilities to the rest of the Company. Couple that with an increasing number of studies that are showing that software quality is lower now and that it seems that Agile is part of the reason (basically, the idea that somehow the coordination of effort required to make a large project come together would magically happen "organically" is being increasingly debunked) and, well, clearly it is time to re-evaluate how Engineering needs to operate within a Company.
Paint my car black.
So you do all the prep work, car's primed with a dark primer, black paint is mixed and ready to go, then this change request comes in:
Paint my car white.
Well, now you've wasted the paint you just tinted black, and you can't paint white on top of dark primer (well, you can, but you need many more coats), so you've got to redo the prep work. That means waiting while the primer fully cures, so you can sand it off properly; otherwise, it'll gum your sandpaper. then re-prime, then you can paint. Assuming you don't see
Paint my car forest green.
in the meantime.
That was one word. Yes, one line matters.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Sorry bro, but if you got silence in response to that question, those weren't "Agile zealots." They weren't even "Agile newbies." They were ignorant cunts.
Agile does NOT say "start coding and figure it out as we go." Agile says "Take some small subset of the functionality you've declared "the most important," estimate that, and deliver that."
Somebody has a list of 100 features? Great, estimate business value and level of effort - use story points, t-shirt sizes, etc. That alone gets you a pretty good way to prioritize your list - things that are "small-to-medium LOE, high value" go to the top of the list. Then you estimate those specific features, and start working on them - to start delivering business value as quickly as you can. Then as you go down your prioritized list, you continue refining and estimating the other features and pull them into your work queue as they reach the top of the "Effort x Most Valuable" ranking.
If you're a true Agile team, you're cross-functional, which means that proper representation from ALL of the organizations needed to deliver the product is present, embedded in your team. While devs are banging out designs and code, Testers are working on test plans and test automation given the specs that the devs produce, and Support people are building operations documentation and support matrices etc. - all in parallel, all coordinating with one another as the process goes. A team with proper representation from all functions SHOULD be able to provide necessary dates and timelines, because there is no "Dev team" just throwing dates over the wall to Support and Manufacturing.
Agile DOES answer these questions - if you're able to sit there and pretend that you've never heard the answers, then you're incredibly ignorant, or incredibly invested in somehow feeling like you've "discredited" Agile by sneering at it.
I've been programming for over thirty years, and I can't do estimates. At all.
Even when I think something is easy, it turns out to be hard if there's some snag I didn't foresee. If I think it's hard then I may find out it's not so bad after all because there are already tools to help put. Something that seems intellectually easy may take a long time because it involves a lot of tedious programming or detailed testing. Writing documentation takes me forever, I can not do that quickly at all unless someone wants a plain text file (which no one wants anymore). One big problem here is that I almost *never* program something that's been done a hundred times before, it's always something new, something that requires learning a new system, new hardware, something requiring reading through a lot of documents first, something with a huge amount of unknown variables, and so on. I also want to deliver something that works with minimal to no bug fixes required later, as opposed to shipping on time followed by a long sequence of updates.
Now certainly for some things I can say that I'll be done that night, because it's something really easy, like reverting a change, fixing up an obvious bug, and so on. But even then I occasionally hit a snag that's unpredicted.
The big problem is that the people who want the estimates don't understand this. And they come in all types. There's the person who thinks that a little bit of pressure makes people perform better (ya, you gave us someting to do in 3 months that needs 9 months). There's the person who thinks the estimates are accurate and golden and then sells the product before any work has begun. There's the person who thinks that your estimate means you will be working 100% of the time only on that single project and nothing else. There's the person who has a preconceived idea of how long it will take and considers that any longer estimate is "sandbagging". There are the people who will put me on two of the companies most important projects of all time, at the same time.
At one place, I gave an estimate of a simple task to be "two weeks after the main project finishes I will have the integration finished". So the sales rep wrote down a specific date based on that. The main project was late, but when that date arrived the sales guy comes up and asks me for my piece, which I had not started yet and could not start yet, then he panics because he's promised it to the customer (before even the product I am integrating with even exists). Ultimately I ended up with only two days to work on it.
I seriously wish that people would switch to a model where they announce a product after it is finished, and schedules are not based upon when the next conference or trade show is.
I've been programming for over thirty years, and I can't do estimates. At all.
I've been programming for over thirty years, and I'm pretty good at estimates.
It comes from a practice that I learned at Microsoft. Before Microsoft, I did the usual "Oh, about two weeks" estimate for everything that I was shown.
Design your feature or product. Then figure out how you're going to build it. Then break down that build into tasks that are no less than half a day and no longer than three days. Add it all together and divide by the fraction of a week where you're actually going to be productive. At Microsoft, I was using 0.8 because I'd inevitably lose a day a week to 'stuff'.
Caveats? Sure. Unfamiliarity with the problem domain. Unfamiliarity with the development tools. Lack of control over one's own development time. Lack of access to development resources. And many more. If I'm working in an environment where I cannot use the above technique to get a good estimate of how long it will take to build the feature or product I'm responsible for, then I'm either the wrong engineer or I'm working for the wrong people.
Note that when you do the above, you will come up with a shockingly-long period of time. But when you present that number to your boss, you will have the data to show that are a result of a detailed understanding of your tasks. You'll have your ducks in a row. Your boss will love you because the two of you can talk intelligently about how the schedule can be adjusted by altering the tasks in it.
If your manager wants you to alter the time it takes to complete tasks, you're back to "working for the wrong people".