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.
Right now, of the frameworks I’ve looked at, my favorite framework is React JS. But if I were picking a corporate framework, at this point I’d probably land on Angular 2.0.
But the question you are probably asking is , “Why two different selections?” And, I think a more interesting question would be, “How did you select which one to use?”
But an even more interesting question is this. What factors are essential when picking out a framework. If I ignored these questions, what are the cost?
While there are a lot of things I could respond to, the one I want to focus on today is what I would call, “The fallacy of concepts over terminology.”
While none of the comments actually come out and say this, several imply that knowing the concept but not knowing the proper term for it is enough. In conversations with people I’ve worked with, I’ve received similar feedback. In fact, as recent as three years ago I actually told someone, “If you want someone who can pass some sort of test, I’m probably not your guy. If you want someone who is an awesome programmer, I’m your guy.”