Tag Info

Hot answers tagged

105

From The Pragmatic Programmer: From Journeyman to Master: What to Say When Asked for an Estimate You say "I'll get back to you." You almost always get better results if you slow the process down and spend some time going through the steps we describe in this section. Estimates given at the coffee machine will (like the coffee) come back to ...


80

I think one of the main advantages is that humans and developers specifically are actually pretty bad at estimating time. Think of the nature of development too -- it's not some linear progression from start to finish. It's often "write 90% of the code in 10 minutes and then tear your hair out debugging for 17 hours." That's pretty hard to estimate in the ...


54

Software estimation is the most difficult single task in software engineering- a close second being requirements elicitation. There are a lot of tactics for creating them, all based on getting good requirements first. But when your back's against the wall and they refuse to give you better details, Fake It: Take a good look at the requirements you have. ...


46

Long reply, but hey, I’ve got a summary on the end, so just skip to summary if you can’t be bothered reading the entire thing! As a developer I had to deal with the situation literally every other project, but it's not until I moved into project management that I learned how to deal with it effectively. For me dealing effectively is about two things: ...


43

Ask him how long it would take to find his way through a maze. Not any particular maze, or any particular size of maze - just "a maze". Programming is in some ways similar. You can't be sure how long it will take until you have fully explored the problems you'll need to solve. The only time you can be sure you've done that is when you already have the ...


37

If you're using Fibonacci numbers (or something similar), it limits the number of options when estimating a story. I worked with a group that used low numbers only: 1, 2, 3, 5, 8, and 13. We had a reference story that was a 5. This enabled us to easily make snap decisions on a story's complexity while doing Planning Poker. The other side effect was that ...


36

Our host Joel recommends evidence-based scheduling, which includes methods to account for inaccurate estimation, interruptions and distractions, and all the other usual suspects. The biggest bang items: The person doing a given piece of work has final say on its estimate. No managers, leads or committees are allowed to overrule estimates, only re-assign ...


36

Before I get too far, let me say that Software Estimation: Demystifying the Black Art is an excellent resource for people looking at and thinking about estimations. Both of the images below are from that book as are the core if the ideas presented following. As you've noted, estimations are an important part in being able to accurately predict and plan ...


26

I did development for a guy who was very adamant about wanting accurate estimates. What we settled on, which worked very well, was this: I billed for all the time I spent estimating. It came to around 20-25% of what I billed. I did extremely detailed examination of the tasks. No shooting from the hip. I went into the code, figured out what lines needed ...


25

It depends on what the estimate is for. For an initial, high-level estimate for a business case then the key things are: Speed. Whatever method you use it needs to be quick. The whole point is the stakeholders aren't sure if it is even worth doing the project - which is why they need the numbers for the business case. If the business case was solid they ...


24

Of course they're necessary but they're not intrinsically evil, they're just done badly. The basics of a good estimate: 1) Developers, ideally the ones who will do the work, have to be involved in generating them. 2) An estimate is a range (usually best case, worst case, most likely case), not a single value. You may use the range to approximate a ...


24

The trick is not to avoid there being blanks. The trick is to fill in those blanks as early as possible in the process of development. You are correct that, if developers make assumptions, they will invariably be wrong and that will cost time redeveloping the software later. But, equally, if business people are expected to do a full up-front design when ...


23

It's impossible to predict the future. Requiring a prediction ("estimate") is simply asking for trouble. Everyone does it, and everyone gets it wrong. Your judgement of "out by 500%" is probably just as wrong as the architect's estimate. After all, "...to date the project is still unfinished..." There are no facts available here. No one knows the ...


23

You may want to approach this backwards: Find out the realistic deadline (e.g., is it OK to deliver this in 5-6 months?). All the #s in this example are somewhat relative to this #. Set milestones for tasks that need to be achieved based on that deadline. E.g. 1 month for req gathering and building up skills/experience on SDKs/hardware/etc.... 2 months for ...


23

Best thing to do is not to throw the new developer into the fire, but instead carve out some functionality and/or bug fixes that the developer should have no trouble jumping in to. Find an area that needs work that doesn't require a person to know the entire architecture, requirements and code-base all at once. Maybe have him or her work on documentation ...


23

It would be better to say "I think that can be done". or "I'll check and get back to you". I've had times where I've said no or counter proposed something. If the customer wants "a browser based application that works without ever being connected to the internet and uses tactile feedback", it probably is possible. But it is expensive and it would be more ...


22

You answer the question honestly. You tell them it's a difficult problem, the solution is not obvious, and you are not sure how long it will take to resolve. Promise to update them on your progress every [time frame], so they know you're working on it, and of course, actually send them the updates.


21

We're often asked for an "ballpark estimate" during meetings where we're given very broad and vauge ideas of what they'd like to do. I always say, "if you want an answer today it's a year and a million dollars. If you'd like to give me a lot more details and some time to review them then I can refine those numbers for you." They almost always get the ...


21

The housebuilding analogy comes to mind: how long does it take to fix up a house? You won't know until you know what shape a house is in, what kind of work needs to be done. Is it just painting, or do you need to rewire the place, knock out walls and stuck up a new roof? I do however think that if you take an inventory, (and based on the lines of code you ...


21

You need to ask for some time before you give an answer back to management. Go back and study the task: Write down an overall approach Maybe do some exploration of the code for a few hours Break down the task in steps in an excel (I would suggest Microsoft Project, but that may be an overkill) Against each task try to assign your best guess of estimate Add ...


19

If there is not enough time, there is not enough time. There is no magic solution to finish the project anyway. In my opinion you have done what you could be stating it out. Turned out they had to find it out the hard way. That is how it usually goes. Hopefully the architect and the management have learned from their mistakes and don't do it again. If this ...


19

First, congratulations on your contract! Ok, enough celebrating, let's get down to business. ;) I've been a consultant for over 15 years -- here's my advice. In project management, what you are talking about it "contingency" planning -- and you absolutely should do it, else you are likely to disappoint your client (and make yourself unhappy throughout the ...


17

The best book is Steve McConnell's Estimation: Demystifying the Black Art. It presents excellent researched based methods of software estimation.


17

This is the second question in short succession triggered by that article. Good programmer: I optimize code. Better programmer: I structure data. Best programmer: What's the difference? There's another name for this: premature optimization. Never use early exits. That's the "single point of entry / single point of exit" rule. It's a patch over the real ...


17

Short answer--you can't. As soon as you expose an application over a network, you've introduced an infinite number of possible variations and conditions that you cannot possibly predict to 100% certainty. What happens when a user does something incredibly stupid or unpredictable? What happens when a malicious user works out your processes and comes up ...


16

I'm still not great at it, but I have found that tracking how long you estimate for tasks and how long you actually take can be a big help. That way you can get a solid idea of how far off you usually are. Issue management software with time tracking (Jira in my case) or a spread sheet can be a big help with this. I think more than anything it's an ...



Only top voted, non community-wiki answers of a minimum length are eligible