Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).


Comment: Re:Good method for improving (Score 1) 341

by phantomfive (#49143161) Attached to: The Programmers Who Want To Get Rid of Software Estimates

I see this thinking a lot, but I honestly don't understand how you can meaningfully compare something you've done with something you haven't.

Practice doing it, and soon you'll be able to do it accurately yourself. Think of a typical website.....the content is different, but the structure is just a bunch of pages, storing stuff in a database, maybe doing some authentication. A difficult project would be inventing a new algorithm. That's rare, and working on projects that are completely unrelated to anything you've done before is equally rare.

If you're working on a two-week sprint, by practicing and noticing how accurate your estimates were, then within two months you'll find that 80% of your estimates are accurate.

Caveat emptor: if you have a manager constantly pushing to make your estimates shorter, then learning to make accurate estimates is very hard.

Comment: Re:Hard to believe (Score 2) 165

by phantomfive (#49142255) Attached to: Microsoft's Goals For Their New Web Rendering Engine

Can you even IMAGINE Microsoft saying that 15 years ago? 10 years ago?

Yes, think of the standard pattern:

1) Embrace.
2) Extend.
3) Extinguish.

This fits perfectly in the pattern, it is an echo of "Developers, developers, developers!", it is exactly what you would expect from Microsoft when they realize they are back to the Embrace step.

Comment: Re:Good method for improving (Score 4, Insightful) 341

by phantomfive (#49141833) Attached to: The Programmers Who Want To Get Rid of Software Estimates

Good managers are almost as rare as honest politicians.

Then teach your manager to be better. Reject the corporate structure (it may shift many times while you work at a company, even though not much else changes. That is an indication it's not particularly real), accept that improvement can come from even the lowliest programmer, and then help your manager do better.

If you think that your manager is completely bad in every way, you're not going to be able to help him. You need to be honest, recognize his strengths, and help him overcome his weaknesses.

You'll probably also need to overcome some of your own weaknesses, unless you are perfect. I can tell you one way to not accomplish anything: start a twitter campaign telling the world how bad your boss is. That will not make your system better.

Comment: Re:Estimates are for planning - not penalizing (Score 4, Insightful) 341

by phantomfive (#49141633) Attached to: The Programmers Who Want To Get Rid of Software Estimates
When estimates are accurate, projects get done on time. Then business trusts programmers, money is made, and life becomes better.

People do not predict well and it is not smart to use it against them.

You can improve. Most programming we do is boring, and similar to something we've done before. For things like that, you should be able to make your estimates reasonably accurate.

Sometimes projects have large unknowns, and it's impossible to know how long it will take. In that case you need to propagate that information up to the people who need it, either managers or salespeople or whatever.

Comment: Good method for improving (Score 5, Insightful) 341

by phantomfive (#49141549) Attached to: The Programmers Who Want To Get Rid of Software Estimates
Estimating is a crucial skill for developers. If you don't have it, you'll make bad decisions. For example, answer the question, "should I use framework A, or should I write some code myself?" If you can't estimate how long it will take to use the framework and compare it to how long it will take to write the code yourself, then it is impossible to make a realistic decision. Similarly, "should we write the code using method A, or write the code using method B?" If you don't know how long they take then you can't make good decisions.

This is a trick I learned from agile (although I'm sure it's been around longer than that). Each time you make an estimate, pay attention to how accurate it was, then next time adjust and make a better estimate based on that. Estimating shouldn't take much of your time.....if it does, then you're doing it wrong.

These guys seem to be complaining that their managers aren't doing anything with the estimates. Which probably means they don't understand what the managers do (but it could also mean their managers are bad).

It is not for me to attempt to fathom the inscrutable workings of Providence. -- The Earl of Birkenhead