The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
And the ever present issue of staff being given far more urgent things to do.
I've lost count of the times that someone has asked why something isn't done even though the developer said it would only take 5 days for the developer to turn round and point out that he'd so far only managed to spend 1/2 a day working on the project.
If you quote 5 days on a monday morning make sure they know it's 5 days of work and not to expect it complete on friday afternoon if there are going to be team meetings / bug investigations for current products etc involved.
Make sure people know what they are getting too. When you say finished to you mean it'll be tested, packaged in a setup file with CD isos prepared or do you mean compiled and ready to run on a developers machine?
Base timescales on your own experience not what a book says.
I generally allow 2 days for a simple Winform and testing it,
2-3 days to write a reasonably complicated routine with SQL access although with DAL and BL type projects a lot of work is performed "up front" and so later work can be quicker.
Don't forget to allow for unit and system testing and fight to keep that time in a plan as that's the first wasted (in their eyes) time that managers think can be shortened - fools!
He took it all too far, but boy could he play guitar!
Very difficult to do.
The normal sequence is:
Your experience tells you how long it took you to do a similar project in the past. Assume it is going to take at least that long, and add some 10 - 20% for over-run.
Then think it over again, and probably double it - if it was that close to the previous project, you would have done it already.
Then think - "does everybody on the team know everything they need to know before they start?" If not, add training time.
Take the number you just came up with, in man-days, and multiply by the number of people in the team - don't forget the PM and the team management - this is your final number.
Then present it to the management, and see it be cut to about a tenth. Expect to get blamed when you go over that time.
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
Sorry, but I tend to agree with your colleague. Think about what the project in question is/should be worth (which, again, you'll only know once you've been around the industry a few times) and then work to that.
The alternative is finding a workplace where the requirements are always right the first time and you never get interrupted by other projects :P
I don't think it's acceptable in a modern business for a team member to 'not believe in estimations'. A business is going to look to its technical staff to try and quantify how much effort will be required to complete a project so that they can determine whether or not there is an associated value.
I think what your colleague is really saying is that he's not very good at estimation - if it's any consolation, most of us aren't! I've been developing for around 10 years now and have always been required to provide estimations. Over the years I've got better at estimating - due to a combination of experience and practice.
Don't forget that an estimate is exactly that - a best guess at how long it's going to take to complete a piece of work. If the specification changes, the estimate should be reviewed.
In Agile development, there's an encouragement to estimate work in a comparative basis, rather than in hours or days; for example, saying that a piece of work X will take twice as long as a piece of work Y. Again this is more of a trial and error approach but eventually you'll figure out what a 'unit' of work consists of and you can determine your estimates from here. This article[^] contains a reasonable summary of estimating.
If you want to get better at estimating, you need to start doing it! Next time you get a project, break it down into smaller segments and try and figure out how long each of these will take. Review this during the project (e.g. as new requirements come to light) and at the end review how long it took you to complete each task. It will require a bit of discipline but ultimately it's a tool that you should possess as a professional developer.
Sarchasm : The gulf between the author of sarcastic wit and the person who doesn't get it.
1) The time taken per k or meg of quality finished code in hours.
2) The cost per PRODUCTIVE man hour of your company. (Take all the costs for the whole year and divide it up into 40 hour week PRODUCTIVE man hours). You will probably get to around $120 per hour say.
3) The size of the code the product will need. (And thats the hard bit)
You can base #3 on, GUI components, complexity, unknowns (learning curve costs), or competitors products.
Multiple all these together and add profit of say 30%.
Morality is indistinguishable from social proscription
Entry level developers are not really expected to have good estimation skills so I can see why your colleague doesn't do them. Over time you will both learn what it takes. Sometimes it is all experience; sometimes a proof-of-concept is required and in all cases your team lead adds 30% to your estimate and the PM adds 30% to the team leads estimate. That way you only slightly go over.
Always looks good when you buy it, a nice big round of cheese, and it tastes great, but why is it its never finished? Why is it there is always a bit left, unappealing, palid, and dull looking which eventually gets thrown away?
Morality is indistinguishable from social proscription
Because the tiny pieces are hard to cut/grate? Or when the cheese gets that low, you buy another block in advance before that piece gets a chance to be eaten and, out of excitement (or perhaps in preparation for a well timed meal), that new package is opened and the old cheese gets ignored.