What Did You Say?

This says it all. Most of the time research focuses on if new stuff is possible. The real 'Silver Bullet' would be to find a way to solve the communication problem. Click on the image to embiggen.

An Estimate By Any Other Name

Terri Vajdi, a colleague of mine, sent me this response to my post on estimating. She always had the most thorough estimates I've seen in my career, so I have a lot of respect for what she has to say.

Since I drill down to assume the details of the requirements when it's missing, I equate this to all the missed requirements to a certain percentage. I read the requirements and try to envision the amount of code, junits, number of iterations, and unit testing for each iteration, Code Review and implementing the changes based on the Code Review, etc...
So, I come up with an estimate for each of these and then multiply it by the percentage/factor for the missing pieces. Add this the estimate for the missing pieces to my estimate to come up with the estimate that I turn over to my manager. In majority of cases, I break even and come close to the estimate that I have given. Of course, this is with putting a lot of overtime to meet my estimate. Remember we do not live in and ideal world and there are a lot of mishaps. This is just my two cents. Of course, I'm a quality oriented individual and I do not like to revisit my code once it's in Production. I figure that number of iterations after it has gone to Production is very very expensive. I'd rather spent it up front. So far, I've been able to stick to my methodology and have been able to spend my time wisely on other assignments once the code is in Production.

Sometimes I'm too eager and go light on my estimates which would mean even more work later and for which I've been criticized when the unknown issues would crop up and the project would run late. Terri has the right idea. She passed along this link:
http://www.apl.jhu.edu/Classes/635431/felikson/Publications/No_Silver_Bullet_Brooks.html

Anyone else have "Estimation Stories" to share?

In My Estimation

There I was at my first real programming job and my team lead comes by and drops a bomb. "How long will it take to make the change?", he asks. I hope I kept the panic from my face. "Wait a minute!", I was thinking, "Did I miss the class on estimation in college?" No, I didn't. They didn't have one. Hmmm, what do I tell my boss, "sorry, can't help you!", "I have no idea", or even better "they didn't teach that in school"? If I close my eyes and pull a number out of my estimation orifice I could look like a ill-trained idiot programmer by guessing too high or try to please by low-balling it which could easily backfire. Why did I want to be a programmer again, someone remind me. It surely wasn't to look incompetent to a guy that hasn't coded in over 20 years.

Why is estimation still so hard and what are we doing about it?

Risky Words

Taking a break from the book review to post something small but still significant.

Clarity is a very useful tool to manage risk. If something isn’t clear, we’re at risk of getting something wrong. Many times your best risk management tools are your own ears. Nuance in language can be fun when you're flirting with someone at a bar, tossing out double-entendres but when preciseness or clarity is valued, like in requirements specifications, nuance can be a killer.

To Function or Not to Function, That is the Question

Question:
What is the difference between a functional and non-functional requirement?

Answer:
If a requirement uses a verb to describe the feature then it is functional; What will the system *do*? If a requirement uses an adverb or adjective to describe the feature, 'how' will it do whatever, then it is non-functional.

I've almost always been interested in the importance of language in discussing requirements. There are two ways to listen to your customer, literally and figuratively. That the customer has difficulty describing their requirements has been a problem in the software field for so long that it's now a cliche. What some analysts have done in to start reading between the lines to capture what the customer is "really" saying. There can be some benefit to this figurative approach but I would always to to listen to them literally. In many cases this meant inconsistent or confusing descriptions, the key was to realize that those questionable points were just that, points to question. In getting clarification about those requirements, we can get a more detailed understanding of the problem domain. If their choice of words or phrases contradict, ask them about it.

Sometimes we need to listen figuratively or "between the lines" to get the overall picture but listening literally can be indispensable for uncovering the things you need to dig into for more details.