We’ve all been there. Either at the micro level or at the macro level. Business wants to know, “How much is this going to cost me?” And as software developers, we all know the answer is, “more than you were expecting.” We also know that whatever number we give will probably be wrong for a number of reasons. Chief among them is that no one really knows what they want until they see it.
And yet, there has to be some way of providing business what they need and still allowing for unknowns.
So what follows are a few tips on estimating that help you estimate software projects like a pro.
Over the last week, I’ve been helping other programmers estimate the task they’ve been assigned and this has caused me to reflect on how I estimate software. What works. What doesn’t. What mistakes I see people make.
There has also been a move to avoid estimates entirely. The argument goes something along the lines of, “we know the least about a project at the beginning of the project, so we can’t really give an accurate estimate.” Which is mostly true. And yet, there are people who need to know “how much is this going to cost?” What do we do for them? How do we balance the two realities?
And then all of this lead me to think of all the ways we sabotage our estimates, or our estimates are sabotaged for us.
You might think that estimating projects only applies to project managers. But the truth is, most places I have worked rely on programmers to give them estimates, and frankly, most of us screw this up.
We’ll get to Reasons Projects Succeed soon, but I need to do some setup work first.
I’ve been thinking about starting an Open Source project for a while. The only issue was; I didn’t have an idea for a project that didn’t already exist. Now I do. So, I’ve begun the process.
The issue with starting a project like this is that I would much rather just start coding. In fact, I would much rather not even make this Open Source. But making it Open Source has forced me to face project management issues head on.
I’ve been listening to enough podcast recently to know that putting something up on GitHub isn’t going to make a project Open Source any more than it will make it successful. Therefor, I’ve decided to start the project as though it had a team of people already working on it. It is a team of one for now. But, one thing I’ve learned in life is that having the structure in place to handle a larger team now will not just benefit me in the future, but it will actually help my small little team of me today.
I’ve started looking at other successful Open Source projects to see what they are doing and to determine what components of what they are doing I want to include in my project. As I’ve gone through this exercise, the thought occurred to me, “If the organizations I’ve worked for implemented half of what these projects implement, the projects would have been run so much more efficiently and the projects that were in trouble may have avoided the trouble.”
As popular as Node is, I am still finding that many of the people I work with have no idea what it is or if they do, they only have a partial idea and can’t see how it would apply to the work they do on a daily basis.