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."
Estimates are necessary, so that you can determine project cost and (sometimes) duration. However, most projects succumb to my amended Parkinson's Law which states "work contracts or expands so as to fill the time available for its completion" .
My UID is prime!
The amount of time it will take to complete a project is inversely proportional to the perceived difficulty of the project. This also applies to tasks and deliverables within the project. The project that you think will be easy and fast will be neither. The project that you think is going to be a tangled nightmare will turn out to have some surprising shortcuts and simplifications that make it not so bad.
Part of this is the stupid human trick factor - if we think something is going to be difficult, we approach it differently and with more caution. As a result we're more able to identify things to make the project go smoother. Conversely, if we think something is going to be easy, it's because we've only determined one path to approaching it, and if that path turns out to be non-viable, we have an immediate delay as we scramble to find other solutions that will work.
There's also the psychological factor at play for the customer - if we say something is going to be ghastly and difficult and will take us a long time ( because we think it will) but then turn around and deliver it ahead of schedule and under budget, we look good and feel good. This does not work if you say something will be ghastly and difficult but secretly think it will be easy and fast, however.
Occasionally living proof of the Ballmer peak.
Research into procrastination has noted that people have much less concern about their future selves than their present selves and are willing to sell their future selves down the river for the sake of present ease. But when the present marches into the future, and we are confronted with the work that our past selves refused to do, we pay the price in unmet deadlines, all-nighters and general torment.
http://www.nytimes.com/2015/01...
The result becomes one of people providing estimates that allow them to screw off in the present and postpone the agony of late nights, weekends and looming deadlines for taking it easy today. This seems to always happen in our organization. A current project has had the hardware in place and ready for the teams to load their software on and configure the system for 6 months, but they waited until 3 weeks before the project is due to start and now they are changing the project design to make it easier on themselves in the present as well. Estimates = wasted time. Just do it.
I used to tilt at this very windmill myself. It took me a long time to realize that people really, really need to hear an answer to "how long?". When we were in startup mode a long project was a matter of a few weeks. Everything had to go into production immediately. So we got used to banging stuff out in small chunks and doing it as quickly as possible. Entire project timelines were completed in less time than it takes to draft a proper requirements document.
But as we grew in size, the new people were not happy with our development team. Even though they would ask for a new report at 10am and have it in production before they returned from lunch, they still felt like we were not responsive. It was one of those reports that began to help me understand the psychology.
There was a problem with a very complex Crystal Reports document one morning. The Director of the department called to let us know about it. I told him we were already working on it and would have it fixed as soon as possible. "When will it be fixed?" he asked. Well, I had no clue. We had only learned about the problem 10 minutes before and hadn't figured out what was broken. So I explained this to him and told him that we had this as our top priority and it would be fixed as quickly as possible. I certainly thought that should make him happy. Well, it didn't.
He was rather pissed that I wouldn't give him a timeline. The day before we had made some changes for him that took about 2 hours, but he was upset that we didn't let him know how long it would take. Being an engineering type, when I hear "how long will this take?", I hear a request for a certain degree of precision. The problem with short projects like this is that by the time you have enough information to give an honest estimate, you are pretty much done. Maybe you have 15 minutes or an hour to go, but nothing worth reporting to anyone. Well, after explaining my position a few times and just making him more angry I finally gave up and just gave him a made-up deadline of Thursday afternoon. He was perfectly happy. I had just spent 15 minutes trying to explain to him that we were working feverishly and would be done as soon as we could (which would likely be a couple of hours, but who knows) and he hated that answer. "We'll have it for you in 3 days!" made him very happy. Even though his production was impeded by the lack of this particular report. From a human psychology standpoint he would rather know that it will be done in 3 days, barring delays, than not know when it will be done and have it in two hours. I personally think that is a dumb way of doing things, but I am the outlier, not the director.
After that learning experience we began implementing a more comprehensive SDLC process and providing timelines for projects. Everyone was much happier with the development team after this. Even though their projects went into production much more slowly. They loved the perceived control that having a timeline gave them. We developers know that these things are basically fictional documents - just educated guesses really - but it provides real customer satisfaction, so we keep with it. In fact, we kept evolving this idea into more and more involvement from the business unit as we moved into Agile and SCRUM methodologies.
I would say that unless you are working in an organization of less than 25 people, providing timelines is an absolute requirement from a purely human standpoint. This comes from hard experience - even though I think that everything about a timeline is probably B.S. and all of the effort that goes into preparing one would have been better spent solving problems and building something useful. In the real world you can't ignore the psychological needs of the group.
No, you complain only once, whereas software estimation has to be done over and over for every task... for many years. 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. Estimates are good for repetitive or non-creative tasks that have been done for many years and you know exactly how long some task takes.
Estimation in the software world is a scam perpetuated by managers and management to get developers to work extra hard.
I always get my coder to give me an estimate and I keep track of both the agreed upon and expected delivery based off history.
I always negotiate any changes I make to anything with the coder IN WRITING as stated in the contract.
If I'm changing the spec the coder gets to change his estimate of both time and price.
As a result I make damn sure my spec almost never changes.
It incentivizes me to know what the hell I want and not turn into one of the shitheads I've done projects for.
My coders work with a contractual gun to their head in the form of penalties for failure to deliver. I'm not a complete ass about it but when they fail to deliver they lose a lot of power in the relationship.
I hold myself to the same standard and if I go changing the spec it's lots of extra time and money for the coder.
If you can't estimate a job then I don't want you anywhere near my business. I don't care if your code brings tears to QA's eye.
I was a technically literate manager, having done lots and lots of programming myself. My job was simple: run interference with the client so that my team stayed funded. The team was very happy to let me do that job, which required a lot of travel and unpleasant politics.
In turn I trusted the team. I asked them for realistic estimates to give the client. If the team thought they weren't going to make it on time, I asked them for a heads-up as far ahead as possible, and I would take the news/new estimate for the client. I did not criticize the team, either to them directly or to the client.
They knew they were asked to do their best but software being what it is, they were not held to preliminary estimates. (The only issue was with downright incompetence or negligence, which was very rare.)
It's interesting that I was considered a good manager by the staff and the client, but not by my own management, who said I wasn't hard enough on the staff. Well, sorry, I got results and I kept us funded.
So, was I a "useless manager"? I hope not. I didn't produce anything tangible, and that bothered me, but I hope I played a useful role.
Yeah. Estimating the time to develop a simple web page is one thing. Estimating the time to design and engineer a new enterprise system is another. It seems that there are "managers" who think the first can be translated into the second. I'm sure Cheops asked his engineers to specify how long it would take to build his pyramid... The answer? "It depends!". Depends upon how many workers we can get, how far we have to go to get the stones, what the weather will be like...
A well defined project can be estimated. Change Orders estimating needs to be done properly and BILLED - the cost of re-analyzing is a real cost and the business needs to see it. Once you get that across the number of change requests decreases dramatically.
Software engineering is Engineering... some of the costs are inverted, but otherwise it's the same project management as other engineering projects.
I have a project that was due last week that I haven't started on yet. I got the deposit check the day I handed over the SoW, but didn't get the signed SoW back until last week, 6 weeks later. As per the terms of the SoW, I'll reschedule it when I find time.
Most of the delays I encounter are caused by someone else; either the need to refactor someone else's shit code (that I wasn't allowed to review before providing an estimate, of course), delayed approval for the work, delayed access to resources, any number of external forces. Very rarely do I exceed my estimated *hours* for a project unless changes are requested (but then I'm not exceeding the estimate, either, since I make the client either agree to a new estimate or accept a refund of any portion of their deposit not already applied to the hours I've worked), but all too often I find myself completing projects well past their due date because some resource wasn't made available to me until after that date had lapsed.
Fortunately, I foresaw that unforeseen things would happen when drafting the boilerplate language of my SoW and covered all of those cases. I go over the entire SoW with my clients before starting a project and make sure they know what the triggers are for a re-quote, what will cause the project to be delayed, and under what circumstances they're entitled to a refund of any deposit they pay (e.g. if they back out of the project once I've started work, I'm deducting my hours from that). As a result of that, and perhaps a bit of luck, I haven't had any disputes over project scope, budget, or timeline, and the one client I did have back out of a project simply said they no longer had the budget (they were being sued) and told me to hold on to the remainder of their deposit as they'd be back to finish the project after they lawsuit ended, hinting that, even if that didn't happen, the small sum would make no difference going forward (of course, I'm sitting on that money for now, and if they fully back out of the project I'll insist that they either accept the refund or sign a document releasing the funds to me).
That was one thing that really pissed me off when I was working for someone else; I had no control over external interruptions or delays and it was usually the person interrupting and delaying me who was holding me accountable for all of them. I'm not out to scam anyone, but I always felt like I was when dealing with my previous employer.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.