Christian Mackeprang has a new post to his site with some of his thoughts on why software estimates are impossible in any realistic project development process.

When you, as a programmer, start a new project, you will often not know full well how to do it, for many reasons. But you are a professional, and you’ve completed similar tasks in the past, so you either try to figure it out, or find someone who can, and ask them how, or just google it.

[...] The problem comes down to the difference between tasks which require a lot of thinking, and routine tasks which you already have some practice with.

He gives an example of solving a Rubik’s cube, how most people take a very long time to figure it out but there are some that can do it in a matter of seconds. He talks about unexpected complexity and how that can blow previous estimates out of the water. He points out that complexity can be cumulative (related to the number of tasks) and the difference between creative and mechanical tasks.

Cal Evans has posted a sort of "call to arms" for the developers out there, asking them to be more honest with software estimates and think realistically about the project and its complexities.

As developers, we see projects not as a job that must be done, but as art that can be created, as a project that needs to be crafted. It’s not a spreadsheet of numbers to us, it’s a sketch on a napkin of something we want to build. As such, we see the big picture, but miss the details. So when we tell a customer/client/family member “Yeah, I can build that this weekend”. In our mind, we mean it. We honestly think the project is simple enough to be built in a weekend. It rarely is though.

He goes on to talk about some of his own experience with the "just a weekend" claims and the over-promising that comes easily to devs. He suggests a few things to link about as you're estimating your next project - can you actually do it (not a "learn on" project) and thinking about when it will be done based on availability, not just desire and work in isolation.

Chris Roane has a new post to his blog today talking about a quality he sees as one of the more valuable in PHP developers - leadership. He suggests, though, that if it's not there from the start, it can be learned.

Until recently, I thought leadership was a gift that you either had or did not have. I still believe it is something you can learn and get better at, but I’m now realizing that leadership is something we all have to some capacity. In fact, to be a successful PHP programmer, you have to be a good leader.

He relates it back to you being the "leader" of your own life, you being the one to make the decisions outside of the office too. This can translate back into your work in things like his example - making accurate estimates of development times and how much work it would take to make that happen.

This type of PHP programmer is valuable because they do not need someone constantly babysitting them. They can be trusted and people can depend on them confidently. If you are a manager, these are the people you want to manage because they will make you look good.

On the Ibuildings blog today there's a new article that looks at some best practices when it comes to estimating the time you can tell the customer a "more correct" timeline for when things will be ready.

Our estimating team spent two months thinking and discussing how software companies create estimates; we discussed what works and what doesn't. While the final document itself, along with the accompanying workbook, are available internally only, some of what was learned about the meta process of estimating may be interesting to others. Here are four Best Practices that came out of the process that we want to share with everyone.

He looks at "rightsizing" your estimations to fit the project, using only qualified people and constantly monitor your estimates and those doing the estimates (to ensure things are progressing as they should).

The estimate is what it is; if the amount is too high for the customer to accept then the price per hour can be adjusted or the feature set can be reduced. The number of hours that the project will take, however, should never be arbitrarily adjusted simply to meet a client's budget.