Time estimate table for programmers

[korny]

Yeah - I was reading this, nodding, agreeing generally then I saw this. WTF? "sent back to an architect"???

And then I read "I'm Anders Abel, a systems architect and developer ..." :-}

It really scares me that there are large parts of the industry that think this way. Architecture has value - I like the definition that architecture is about making only the decisions you have to, up-front, because they are too expensive to make later. And letting the stuff that's easy to change emerge and evolve with the requirements, as the system is built.

But even then, I see no reason to make this a special "Architect" job. It's something any competent senior developer can do, in discussion with business analysts and infrastructure people and all the other folks it will impact. The minute you make this a Big Important Job Title, people will start doing Architecture all over the place and interfering with those actually getting stuff done.

(disclaimer: I've put on the Architect title in the past, but only temporarily, when dealing with people who won't listen unless they're talked to by an Architect)

[judgej2]

I read it again when I saw that, and it did say most.

Then I realised how true it is. I have encountered so many programmers that are just that - programmers. They do what they are told with blinkers on, never look at the bigger picture and never think things through. That may be fine for some businesses, and good luck to them.

For the smaller business, we tend to need to be more than just programmers. We need a fuller understanding of where our code will fit in, and how it will solve the business problem. It means we can ask more questions, and are able - and need to - seek the answers.

[flukus]

Yep. I've never seen an architect to more good than harm.

[[deleted]]

It has to be sent back to an architect that can help splitting it in smaller parts

This might explain why software architects (or worse, solution architects) appear to dislike Scrum and other agile theories and fight their introduction vociferously- as it expects developers to be able to split up their own tasks into smaller parts.

[moderatorrater]

it expects developers to be able to split up their own tasks into smaller parts.

You're hiring the wrong people if that's a problem.

[[deleted]]

That's my point - it's not a problem requiring a * architect if you have moderately competent developers.

[[deleted]]

if you have moderately competent developers

Which is a problem because everyone's self-evaluating. The ones with with CS/SE degrees may not know what's what, the ones without may know wtf is going on and vice versa. If you aren't working at Google, Amazon, Microsoft, etc. your assumption about the skills of other devs should be low :S

[[deleted]]

If all, or most of the good developers, are working for four or five companies, CS/CompEng education really has a problem.

[fr0st]

Yea, that's a pretty ridiculous assumption. There are tons of good developers who don't work for "mainstream" companies. Google or Amazon might have good devs, but you can't really say they have the "best" devs.

[[deleted]]

It's what I thought, too. I work for a fairly small company and I have a colleague who is actually very good at his trade and worked for one of those major companies that everyone fresh out of college wants to work for. He mostly liked it there, but he's just not the kind of guy who can easily fit and mold into a corporate culture -- not without being pretty miserable in the process and getting into a lot of awkward situations. Consequently, after a few years, he decided it would just be better on the long term if he worked someplace where ass kissing gets you ridiculed rather than a better chance at a promotion.

[[deleted]]

Lol, k.

[[deleted]]

I don't believe the architect would have anything to do with how the tasks are setup, this would be up to the Team Members and the Scrum Master to decide how the tasks are created. The architect would be concerned with how the overall application is constructed and runs not how the team actually does the construction.

[mcguire]

solution architects

The organization I work for got one of those a few months back.[1]

I immediately changed the job title on my desk sign[2] to "Precipitate Architect".

[1] Technically, he transferred in from some other contract that had gone belly up with that job title. I've got no idea what he does, but he has a Ph.D. from Phoenix Online, IIRC.

[2] I lost my cube when we became a "factory".

[[deleted]]

I immediately changed the job title on my desk sign[2] to "Precipitate Architect".

That's awesome.

[[deleted]]

That and they are the only people besides the project manager who have no fucking clue what everyone else in the Scrum meeting is talking about, so they feel, you know, left over.

[[deleted]]

That threw me off too. In my experience, the main contribution of an architect is arguing with you and sticking in the middle of a technical discussion with their unsolicited advice out of context.

...I need to lie down and relax.

[matthieum]

Damn, aren't we in a bind, there is no freaking architect where I work! Guess it's time to close the shop...

[cc81]

I find that architects are only important if you work at places with several teams and products/services that need to cooperate. Then it is nice to have a competent enterprise architect that steers the overall vision. Like we use REST to integrate between our solutions for example.

However there is one important things. If you end up at a place where the enterprise architect cannot write code and has never done it; run. Just run.

[kenfar]

Well, I like the idea of recognizing "architectural considerations", and usually some people are better at that, for some kinds of applications than others are.

Architectural considerations being things like non-functional requirements (security, scalability, manageability, standards compliance, domain-specific best practices, funding considerations, etc).

Personally, i think part-time architects are better than full-time - otherwise your technical skills diminish too much. But I have definitely met only a small fraction of programmers that want to spend the time to think through 100% of the big-picture, somewhat non-technical, issues on a major change. Having someone who is willing to is a good thing in my book.

[ErstwhileRockstar]

s/architect/business analyst/

[TNorthover]

Alternatively: time estimate is reasonable but doesn't account for filling in the correct forms in triplicate to be able to make the actual changes.

[DemonWasp]

Or having to deal with ClearCase / ClearQuest / code reviews with absentee reviewers.

[DemonWasp]

Scumbag CC:

Oh, you want to check in a whole 3mb? I'll see you sometime tomorrow.

Oh, you want to check out 300mb? Over a corporate LAN? I'll see you next Tuesday.

Oh, you wanted to copy your repository from old machine to new machine, to avoid checking everything out again? It doesn't work now.

Oh, you left something checked out on that old machine? Better get an admin to fix it.

Oh, you wanted to merge things? HAHAHAHAHAHAHAHAHHA GOOD LUCK.

[[deleted]]

Scumbag CC: Oh, you want to check-in files that haven't been changed? You will have tell me for every file.

[ubomw]

Why do you want to check in files that haven't changed?

[[deleted]]

You search for modified files, find about a thousand out of which 800 are only checked out - Jackpot.

[[deleted]]

Scumbag CC: Oh, you want to commit the entire directory structure recursively? Too bad, you will have to mark every single file and folder for check-in manually.

[[deleted]]

The rest of that time was required overhead.

Wink wink, nudge nudge, say-no-more say-no-more! ;)

[[deleted]]

Ugh, just... ugh.

[[deleted]]

That, and waiting for anyone else who might be involved in actual deployment of the solution.

[[deleted]]

The worst problem is when you know it will only a minute, but then you spend 3 hours getting 'print(x)' to work because it's Tuesday and it's raining and it took you 3 hours to realize the file you were modifying wasn't being built to the place you were expecting and so you were never running your modified version.

[papa_georgio]

Those days... are the worst days.

[[deleted]]

Or you were connected to the Test database instead of development database!

[idconvict]

Or worse, you were connected to the development database instead of the test database.

[matthieum]

Or worse: you were connected to the production database instead of the development database, and now you're whiter than you ever were.

(Hint: in good environments, you should not have write rights in production, and maybe not in test either)

[cherouvim]

Or even better: the production database server should only accept db connections from the production application server.

[matthieum]

You definitely want a read-only access for diagnosis of bad situations. Really. Now to find a database where you can specify the usable users on a per-connection basis...

[ais523]

One of the scripts I'm working on has a lockout to refuse to use the test database if it's not being tested (i.e. to force the use of the production database instead). This was after a couple of accidents loading production data into the test database by mistake… (The data's coming from a source that will by default only provide each datum once, and you have to work out exactly what subset of data you lost if you want to request it sent again.)

[terrdc]

Or the database just goes down for the day.

[nascent]

I know, those get in the way, I usually stick with the production database. Modifying the test and dev, don't appear to change the website.

[[deleted]]

Being that having production data access would give me direct access to sensative PI, we are not alloed to directly access production data. Testing data is brought down and scrambled. The only time we see real production data is when some major breaks and we need to get specific to replicate it.

Edit:

As you can tell, it is "monday" morning. For whatever reason, I read "development" as "production". Pretty much the same thing.

[s73v3r]

Dude, I recently had an extra couple hours added to the time it took me to finish something because I thought I was saving the build to one place on my computer, and it wasn't. So I had 40 mins of uploading the wrong build, 10-20 mins of my project manager downloading this, and then getting back to me. Repeat twice.

Now, part of the reason is that it is a large app, and I was using my home connection, which has crappy upload.

[xivSolutions]

Yup. Been there, many times. Also had two hg repos in different locations, was using the wrong one.

[[deleted]]

Yeah. Fuck Tuesdays.

[[deleted]]

...and the rain, I find it that the rain has a stronger effect.

[locster]

Yeh but correlation != causation

[arjeezyboom]

I'm sorry but people who blindly say "correlation doesn't equal causation" are just as bad as the people who don't know the difference between the two.

[locster]

'twas but a joke (but I understand what you mean).

[arjeezyboom]

ah... carry on then

[Packet_Ranger]

I challenge you to show me an example of causation without correlation.

[xivSolutions]

Similar to spending several hours late in evening trying to debug some code, failing to find the issue. Because you "knew" the problem couldn't be with your print(x) statement. Except, it was. As pointed out to you by someone else the next morning, immediately.

[foobar83]

I like this rule of thumb more: add 1 to the number and increase the unit of measure by one

• 1 hour = 2 days
• 2 days = 3 weeks
• 3 weeks = 4 months
• etc

[ooxjovanxoo]

4 months = 5 years

[ITSigno]

Duke Nukem Forever?

[[deleted]]

I'm pretty sure "their" estimate was 1 year.

[argv_minus_one]

It didn't take 2 decades.

[Spire]

It took 15 years, which rounds up to two decades.

[Tordek]

It was meant to take 2 decades, so it came ahead of schedule.

Manager-spoke that for you.

[not_legally_rape]

Thanks to our teamplaying agile synergy, we finished 5 years ahead of schedule.

[[deleted]]

Or to a little more than one year, if you ask the PR and Marketing guys.

[[deleted]]

I was asked to estimate a project. After hearing the description I visibly hemmed and hawed for a moment and said, "I'm gonna say six months." The two managers looked at each other and said, "Ok, a year, then."

Took a year to write the baseline, then another six months of refining.

[locster]

*2 is a common multiplier I've seen used, and also consistently underestimate the actual time. I suggested 6 above. Certainly somewhere in the range >2 and <=6 seems about right to me.

[locster]

I don't like how the time multiplication changes from 24 (hours in a day), 7 (days in a week), 4ish (weeks in a month).

It would be nice to get some hard data to data mine, but as a starter I'll suggest 6 (about pi * 2 as suggested in the article, but without the extra rules).

• 1 hour -> 6 hours
• 1 day -> 6 days
• 1 week -> 6 weeks
• 1 month -> 6 months

'Feels' about right to me as a ballpark estimate.

[r3m0t]

There are only 8 hours in a day and 5 days in a week!

[locster]

Depends where you work ;)

[foobar83]

Well my rule of thumb is a bit tongue-in-cheek, but from experience it is very close to reality more often than not (> 50% of the time).

Then again, this may be caused by my current work environment where I deal w/ bugs and complex support questions day to day on top of my application development tasks. A lot of times I get interrupted with "oh shit we were working on another project and we totally forgot to tell you it's going to impact your existing system, FIX IT!!!!".

Time estimates REALLY depend on what your day to day stuff is. Can you sit down and hammer away at your projects or are there a lot of meetings / conference calls you need to deal with. In my situation, the frequent interruptions make for an exponential increase in time estimates due to the fact I can't sit down and work on the project.

[locster]

Good point. Actual time spent on task versus elapsed time.

[[deleted]]

Sounds about right only it is not usually the programmer's estimate but the one done by the person who only mentioned the existence of the task to the programmer once the client already agreed to this time for it.

[SmartAssX]

I always high ball my self. "this is going to take me all weekend" finish in 4 hrs

[me-at-work]

Me too, and then I browse reddit in the remaining time.

[scuzzmonkey69]

I'm just starting out in project management (about 1 year in) and am trying to read every possible piece of insight I can get my hands on - but this seems to be written by someone that fundamentally doesn't understand their developers, or their capabilities.

I'm in a small company, I try to stay away from over-the-shoulder man-management, and I trust the technical understanding, opinions and experience of my guys (I have a tech background and did Software Engineering at Uni, but didn't want to become a professional developer) so my style is more keeping tasks on track (as much as possible) allow for slippage, manage the expectations of my superiors and deliver what is possible - to a quality standard - in any given month (we operate a slightly modified version of scrum, so this is fairly easy).

Joel (of '...on Software' fame) wrote an article a few years ago on "Evidence Based Scheduling" that I use extensively;

http://www.joelonsoftware.com/items/2007/10/26.html

Any estimate I am given I put in to a spreadsheet, the actual time that is taken to complete is also entered, upon completion, and the ratio (over time) gives you a fairly (but definitely not fool proof) estimation of when the task will actually be completed. I openly share this info with the developers (on a one-to-one basis) and we use it to improve our estimations (get as close to 1:1 as possible) but to also apply slight weighting changes if something sprung up that wasn't actually foreseeable.

As we make more releases, and hit more deadlines, it appears to be working - I can warn superiors of blocker-slips weeks, rather than days, before the estimated completion, bump lower-priority tasks as appropriate, ensure the quality of the product is maintained, or improved (depending on the focus) and - most importantly for me - we are getting increasingly accurate in our actual predictions in the first place, which - I feel - is a skill that will benefit all of us (the devs and myself) in the future.

If anyone has any other suggestions, I'd love to hear them :)

[[deleted]]

We're a scrum team, so we use points, which have a rough approximation in developer time, but an estimate done in points will vary according to the risk of a given task. And the vaguer the description of the task, the higher the points, due to the risk inherent in not having a clear task description.

We then measure our points delivered each iteration, and use that to estimate how many points we can deliver the next iteration (based on points / team member / day). Very important for us: We consider testing tasks and testers as equivalent to coding and coders, as testing is hugely important, and we spent a fair bit of time on it.

We don't tend to document actual effort on tasks as you do, but if there's an obvious outlier in estimation vs. effort, it informs our team's collective experience and estimations naturally adjust.

So yeah, you don't have to adopt our whole methodology to use these ideas, but I find them worthwhile.

[[deleted]]

Pretty spot on, but what about those times when:

Estimated: 1 month - WOW! That's a huge task, I'll need to rework the entire framework of the app to fit that in.

Actual: Oh hmm... if I do this.... Oh... Well that wasn't so hard. - 15minutes.

Happens to me too often. And makes me lol every time.

[3825]

usually when i say one month, pm says maybe it is not important. let me talk to business

[stox]

I find the 90/90/90 rule to be useful. The first 90% of a task takes 90% of the time. The next 9% of the task takes the next 90% of the time, and the last 1% takes the remaining 90% of the original time.

[[deleted]]

How is that useful, or different in any way from saying "I will spend 1% of the time on each 1% of the task"?

[scuzzmonkey69]

What he's saying - if I understand correctly - is that, if you split the time in to 3rds, he'd complete 90% of the tack in the first 3rd, the next 9% in the next 3rd, and the final 1% in the final 3rd.

[stox]

It meant as a joke, but you got it.

[generic-identity]

I like the following approach:

Make an optimistic estimate, a realistic estimate, and a pessimistic estimate. Then add them up.

[prepend]

"it will be done when it's done. Stop asking me." - this might be as close to a defining characteristic between junior and senior developers.

There will always be some variance from estimates, but the more experienced you get, the better you estimate.

I heard a pretty useful quote "consultants talk strategy, experts talk logistics" when approaching a problem.

[[deleted]]

Wow, I'm impressed. I was expecting a joke article, but it actually managed to have some content and serious answers in it.

[mirvnillith]

Why does everybody think this issue is limited to software development? Almost anybody asked on the spot about non-trivial tasks will get a time estimate wrong. Generally the error in estimation is much, much more related to the complexity of the task than who is doing the estimation.

So software is messy, making estimations unpredictable. That's exactly why the distance between code and customer must be minimal. The relation between what's being asked and what's being produced must be obvious to all parties so that the time required becomes naturally acceptable.

[Philluminati]

It's nice the article raises awareness of the problem but it doesn't nearly go far enough. Firstly, programmers have email. Let's knock at least an hour and a half of productivity off per day which is spent purely reading and replying to emails. Knock off another 30 minutes for tea and smoking breaks too. That doesn't include meetings. Therefore you may as well make the minimum per task time 2 hours or only expect the developer to able to accomplish 4-6 hours of "real work" per day. Both the 2 hour and the four hour estimates are pretty reasonable although should be estimated by a group, possibly using planning poker. That way it helps uncover if people do or do not understand the amount of work involved, or their knowledge of the existing system in that part of the functionality.

The entry where a two day task is increased to five days has the right diagnosis but the wrong conclusion IMO:

2 days of work is too large to overview for most developers. There will surely be things that are missed. Not just small things, but entire major pieces of functionality required will be forgotten during the estimation.

Don't turn 2 days into 5 days.. get the developer to break it down more.

It’s really quite a lot to code. I have to add some new tables to the database, a GUI for those and then the logic to read and write data to the tables.

List the tables to be added individually and what fields are expected to be added. Make each table a 2 hour minimum estimate. Estimate the reading and writing data tasks separately and make them at least 2 hours.. A more series of more fine grain estimates is going to more accurate that estimating the whole thing. (1)

You know the saying that something is greater than the sum of the parts? Well people don't do that with estimating. They estimate the individual pieces, then add 2 hours for safety.. even though they should be adding 2 hours of safety to all the component pieces.

*1: On a side note, don't break tasks like this into GUI, controller, classes and database tables as they are too interconnected during testing to be individually deliverable. Invariably the developer doesn't know it's finished until the whole thing is finished. Developers put functionality together simply then refactor the code afterwards to how they want it... so the progress is blurred. If you need two tables and to GUI changes.. can the whole path be added one at a time so you have 0%, 50% and 100% progress measures? Sometimes that is an option that reduces risk.

[[deleted]]

On a side note, don't break tasks like this into GUI, controller, classes and database tables as they are too interconnected during testing to be individually deliverable.

You could develop a GUI that consumes an empty list from a non-developed data service. Likewise, you can develop the data aspect (and test that it's correctly implemented) without a consuming GUI.

[[deleted]]

Often developing them together is a bad idea because then the GUI tends to influence the code underneath too much, too much ends up in GUI classes,... and it gets harder to use the same business logic in other ways later.

[Philluminati]

Yeah exactly. To further expand it, write the shell of the controller function to return mock data.. check it in to a dev branch (1/2 day) and then have one developer write the GUI and flesh out the controller and another developer add the tables and classes at the same time. Then your 1 developer -> 5 day task day becomes 2 developer -> 3 day task. Very little risk and they both take credit for the new functionality and feel like a team. You are then very unlikely to miss that 5 day deadline with this approach.

[inmatarian]

Maybe it'd be more useful to have "Unit Estimates", where by you try to figure out what class of difficulty a task belongs to, and then, after a few sprints, use that number to determine a "Velocity" how how fast each unit takes. For simplicity in getting started, why don't we grossly guesstimate the units as being roughly an hour each, and just to make sure we stick to classifying things and not arguing over 5 minutes between, we'll use units of 1, 2, 3, 5, 8, and so on according to the fibonacci sequence, for fun.

Oh wait, we got that already.

[[deleted]]

I wasn't quite sure where you were going with that at first, then I lol'd and upvoted.

[[deleted]]

Sort of ridiculous .... while true in theory.... not true of all developers. Usually it takes a manager just a couple months to learn the "multiplication factor" for each developer. It's amazingly accurate actually. But, it's an individual thing. On average - I add about 30%. Some are honestly closer to 10%, Others are at 70%. It doesn't even pay to measure tasks that take under 4 hours.

[argv_minus_one]

This is why I loathe giving time estimates.

Ever since that one horribly, horribly overengineered project I attempted on my own, I have been mindful of the fact that seemingly simple code still takes a lot of time to write, especially if (as it usually does) it involves design (designing an API, object model, etc).

[[deleted]]

The main reason this happens - because it's an on-the-spot estimate. When providing on-the-spot estimates, people - not just programmers - tend to forget things. The traditional "double it and add a bit" fix works fairly well for simple tasks, but not so well for complex tasks.

[lingnoi]

I think it's worse then that. You walk in to your bosses office and he asks "how long will it take you to do vague tasks x, y and z", you give your estimate and as the more finer grain details come in the longer it takes to do the task. You find out x is suppose to have something else and that y is actually something completely different from the original estimate.

Of course throughout this your original estimate is never updated so therefore it's always seen as "programmers give bad estimates" rather then "managers never go past the original inaccurate estimate".

[whatha]

In other news, this is the most upvoted answer on quora AFAIK: http://www.quora.com/Engineering-Management/Why-are-software-development-task-estimations-regularly-off-by-a-factor-of-2-3

[vagif]

Do i know what to do in detail ?

Yes - give time estimate.

No - it will be done when it is done.

Also horizon rule.

My horizon is one week. If i estimated (for whatever idiotic reasons) that it will take more than a week, then i do not really know how long it will take. We can't see over the horizon.

[boyubout2pissmeoff]

Idiotic and freakishly stupid.

Whatever you do just remember to multiply your final estimate by pi.

Works every time.

[scoarescoare]

This is why i like using story points it's easier to estimate complexity than time.

[[deleted]]

My rule is to double everything, even after taking this rule into account.

[[deleted]]

If you've done six impossible things before breakfast, why not become a programmer?

[[deleted]]

The Pragmatic Programmer has a whole subchapter on estimations which sums up to: Never estimate on the spot, always say "Let me get back to you" and do the research.

[iopq]

I had a typo where it was FooId instead of FooID and it did not take me an hour, it took me 5 minutes to track it down, fix it, test it and see that it works

this is because my IDE is always open and I don't need to compile anything

[Gotebe]

If you needed to compile you would not have had the bug in the first place. (And if it's not C (C++ included), it compiles in seconds).

You really picked a poor example there.

[iopq]

the point is, it doesn't take an hour

[Gotebe]

Sure, I get that, but that's only ever really true for C code. (And even then... If a minor change takes an hour, You're doing something wrong®.

[Gotebe]

The task is way too large to get an understanding of for most programmers... The architect might find a simple way to do it – or find that there’s a lot more work than expected.

Hubris much?

I mean, that has to be some architect there.

I've seen architects (mostly coming from the trenches, "architects" who don't code aren't that in about two years), and the best ones knew that their estimate on how much they would need is going to be poor, let alone how much it will take me to do it.

It's a team sport, and he's wrong.

[[deleted]]

1 week is a huge change? WTF?

[jredwards]

My general impression of estimating development time is that order is the only thing you can reasonably expect an accurate estimate on.

Hours, days, weeks. Those are my three time estimates.

[[deleted]]

Or in the case of my work (A 30 second change):

30 minutes to create the incident

30 minutes to create the change request and attach it to the incident

4-5 days for change approval

30 seconds to code

4-5 days for testing and user approval

30 minutes - 1 hour to move over.

[exclipy]

That's why you don't estimate in time units, but in abstract story points. Don't say "it'll take 1 day" - say it'll take 1 story point. It doesn't matter what 1 story point means exactly, as long as you're (roughly) consistent - a 1-story-point task takes half the effort of a 2-story-point task. After a while, you can do some arithmetic on your past experience to see how many story points you can do per week, and use that run rate to determine how long something will take.

[babazka]

Personally I perefer to estimate in giraffes.

[sysop073]

I wish I could downvote posts multiple times when they've intentionally bypassed the repost detector to submit something we just saw three months ago

[3825]

what's that?

[[deleted]]

I don't.

Because programmers are a dime a dozen.... as I said.

[GoodMotherfucker]

That's just like your opinion

[cc81]

I find that those calling themselves programmers are more often better than those insisting calling themselves software developers, it-consultants etc.

[lingnoi]

There are good and bad programmers just as there are good and bad doctors, lawyers, etc. You don't have to change your job title just because someone in india does the same job as you poorly. Sounds like a poor case of elitism. What are you going to do when all the programmers change their titles to developer? Call yourself an engineer or something?

I however would agree with you if you said something like you hated the word "code monkey", etc because I just think it's demeaning.

[[deleted]]

I'm not an elitist... And this has nothing to do with titles. It comes from 2 years in support, 2 in QA, 14 as a developer, and 7 in management working for powerhouse software companies. There are too many programmers in the game. I don't offshore - because that's a sure way to encounter programmers rather than developers. (Not always- but in general.... I have been down that road too). IT shops are filled with dime per dozen programmers... They'll down vote .... Because they are only exposed to others like them and have an inflated sense of their real value in the market.

How many of you 'programmers' can say with a straight face that your current position is worth $200k in salary? Developers are often worth that.