How quickly do you complete your projects, compared to what you thought it would take?

Question

I have recently been befuddled with comments regarding the speed at which some people claim to be able to develop various applications. I tend to feel that there is a definite relationship between application quality, reliability and speed of delivery.

I take Stackoverflow as a good example. I love the quality of the site, (and I think it's going to be the next big thing on the Inter-tubes), but I found it surprising (as did Jeff when he mentioned it on the podcast) that some people thought that they could code this whole site in a week or two. I have no doubt how hard Jeff and his team worked to develop this site into what it is today. And I don't blame them one bit for holding back the release date a couple weeks.

I find that these views about development permeate the developer landscape, thus leading to lower quality applications (ie. bug ridden, despite delivering on time). They also seem to undermine efforts to make sure that at least a certain level of quality is built into the code.

I am curious about everyone's views on this topic? Are people just too optimistic in their estimates? Are they exaggerating?

Answer 1

I really depends on the project, I have one that I have been working on for more then a 2 years, and SEVERAL that I spent less then 1 day on.

Answer 2

I'm horrible at estimates myself (as are most developers I know). I almost always underestimate and it ends up hurting me. Development is hard work.

What we try to do now is break a project into tasks where each task will take less than a day to complete. You shouldn't have a task that spans multiple days.

It's hard sometimes to get down to that level and I occasionally will just write a task like "Implement Feature X." Of course, implementing Feature X might take a week...

Answer 3

In general i have found programmers to be too optimistic in their estimates. That stems from a number of factors, mostly not having a very good idea of pitfalls they might run into, time for testing/debugging, a tendency to dive into the code without thinking out the design first, not factoring in slack time and time lost in communications. I usually assume good faith and assume that they are being honest about their estimates, as in they actually think they CAN do it in that time.

Answer 4

Core functionality and basic features might be some of the things you can complete quickly. However, the details of an application are usually where you are going to spend the majority of your time. Every application has it's own intricacies, and those take time to work out.

Other elements that people gloss over on rough estimates are "polish." Stack Overflow has a massive amount of excellent finishing touches on its user interface and experience as a whole. This takes a lot of time to get right and tune to it's users and community. It is easy to overlook elements like that when thinking about how long it might take to complete a project.

Answer 5

I think the developer considers just how long it would take to write the core functionality. Nothing about how long it would take to glue it all together well, or consider all the various user-interface issues involved. Not to mention the entire testing/bug fixing cycles.

You can spend a couple of weeks planning and designing the system workflows, and still write the code in just a couple of days, but you can't do the whole project in just that time....

It works well in my current situation, because I have a project manager that understands that my estimates are based on the core development aspect, and he knows to add on the extras (generally tripling my timings)

Answer 6

I find that on a lot of projects, the 80/20 rule applies. The individuals that underestimate, largley do not take this into account.

I think that is is possible to throw together a site like SO in a few weeks, but it would be full of niggly little bugs that would take forever to fix and would ruin the user experience.

Answer 7

I never hit my estimates. Ever. On the plus side, it's usually late because it gets delivered with Docs, Tests and Coverage...mostly because I'm a freak like that. It has to have those things for me to be close to satisfied with it, and for me to be able to put it out of my brain.

Answer 8

It depends on who you are surrounded by. Remember Jethro from Beverly Hillbillies? He was a genius with his 6th grade education, but only because his relatives didn't get that far. Likewise, if you are a programmer knows more of some specialty than your co-workers, or you work entirely with non-programmers (eg sales and business types) then with even modest knowledge, you'll be considered a genius and "fast" regardless of where you fall in the world-wide bell curve of your programming peers in the same areas of expertise. That would be you co-workers honest perception. Expectations and context make it hard to even define concepts like "fast", "exaggeration".

Answer 9

I usually severly overestimate how long it will take, then double the result. Never schedule a task for less than a day, even an hour task. Stuff like that.

It seems horrid, but in reality you get 4-5 hours a day of real coding (max) and you generally overlook so many details that it's silly.

If you have 4 tasks, chances are 2-3 will go fine and well under what you'd think, but 1-2 will have some difficult that takes longer, and occasionally 1 will take many times longer. It all balances out.

Always over-estimate, but try to deliver early as well. Review at the end of a project and revise your estimating practices to be closer to what you've delivered in the past.

The people who say they could do a site like this in a couple weeks--you really need to not hire those people. The shortcuts will cost you and you'll never see a 2.0.

Answer 10

My ability to estimate successfully is directly related to how similar of a project I have worked on before.

Humorously, I recently caught pneumonia and got sicker than I had ever been before. On day 3, I thought "for sure I will be healthy on day 4". On day 4 I thought "There is no way I can still be sick on day 5." This repeated for several days.

It turns out that since I have never battled that big of an illness, I had no idea how much time it would take for me to get better. I found this inability to estimate a wakeup call into how software estimation typically works.

Three weeks into a two week project I could easily think "There is no way this could go to four weeks. I've never had a problem take four weeks to solve! Maybe I'm reading stackoverflow too much."

Answer 11

I tend to over-estimate my projects. The IT Director has even taken to asking me (once I provide the time estimate) if the estimate is in 'real' time or in 'Peter' time (which according to him is half the time of my estimate).

To me, I find this humorous.

Answer 12

Time estimation is a skill you acquire the more you use it. If you start estimate all things you do, and do a followup after the project/application/sprint is over, you'll learn and your predictions will be more accurate.

On the otherside, knowing when to stop or when you've done enough is another important skill.

Personally I tend to be a time optimist. In the end I always find my self stuck on a interesting problem longer than I should, because I can not let it go, I need to do it a little bit better that it currently is. I can refactor to eternity...

:)

//W

Answer 13

I have never been good at this but I used to have a project manager that always seemed to be able to nail time frames for our projects. This is how we did it:

1. We (the developers) would think through all the things we knew needed doing.
2. Create an estimate based on that.
3. Pad that estimate to allow for minutiae we might not have thought of.
4. Give this number to our project manager.
5. She would immediately double that number.

It was uncanny how accurate we were.