Day 16

Estimating a large project can be a very time consuming endeavor. Today Micah and I were making estimating how many man days it would take to build up a project for a possible client. First, Micah spent several hours splitting up the project into groups of stories, organized by topic and possible release points. Then we sat down and estimated every single one of the stories, first briefly discussing what it would entail, and then sticking both hands out and giving some estimates. I believe I have discussed the optimistic-realistic-pessimistic estimate strategy Micah uses, but what I would like to discuss is how long it all takes.

Some stories are easy to estimate and take 30 seconds to a minute to figure out. Other stories can take a few minutes if we have to discuss, in a fair amount of detail, what it will require. When you have a lot of stories to get through, this process just takes too long. I would imagine the same danger comes in with SAT graders who, after spending the whole day grading, might start to rush a little bit. Near the last few stories, the estimates begin to come off a bit faster. Given, these are just estimates and not hard contracts, it could still be a concern. It might be better to do just a few estimates at a time, or perhaps to charge a small fee to get an estimate since it takes so much time.

"90% of confusion comes from bad naming" - Eric Smith. Its funny that he said this today, because I also got a text from a previous co-worker today quoting some of my code:

be_in_the_tab = !conditional_not.nil?

Its pretty awful... I spent a few minutes myself just trying to figure out what I meant. The issue is the name 'conditional_not' which was actually a boolean meant to represent if the word "not" was in a string. This was for a cucumber step definition, which had an affirmative and negative version, so I wanted to keep the same logic but just reverse it if there was a 'not' in the acceptance test.

So true it is though. One poorly named class can drastically confound the poor soul trying to unveil the intent of a package. One inaccurately named method can hide the purpose of a class. A single thoughtlessly named variable can transform a simple method into an enigma. Just one boolean named 'conditional_not' can inspire a coworker to remind you of your ineptitude.

If you can't think of the right name for a class, method, or variable at the time you need it, then remind yourself to change it later. You don't want to be leaving behind a trail of confusion. Just as a poor name can hide the purpose or goal of some code, a good name can make it clear as day.