July 2007 - Posts

Doing Justice to V&V
29 July 07 06:40 AM | Earl Beede | 4 comment(s)

One of my secret passions is to kill the man (or woman) who started to use the terms verification and validation in the software world. I know you are hiding out there and when I find you, I will do justice.

I mean, first of all there is this horrible trick of using two words that sound soooo close in English. We don't use many of those 'V' words in this language on a day to day basis so just starting out with a 'V' pretty much means we ignore the rest of the letters. I think I only know about five 'V' words off the top of my head: Valium, (beach) Volleyball, Vacant (my head), and those two nasty beasties listed above. And they all mean the same thing, "time for beer."

And then there are the software related definitions of those two words. Verification: did I build the thing right; Validation: did I build the right thing. Or is that the other way around? I can never tell. I always need to look it up since it is just switching a word here and there. Not that starting the word with a 'V' helps me out much (see previous paragraph). It is like asking if I drank the beer and was it the right beer. Well, by definition, if I drank the beer it was the right beer!

And in the shorter phrase "V&V", which one comes first? Is there a rule on that? Is that rule as critical as the one about not wearing socks with sandals?

Wouldn't it have been better if we called it Requirements Confirmation and Design Confirmation? First of all, we would a nice alignment with the activities that typically produce the needed stuff for the V&V and the V&V itself. Second, we would have words that are completely different and therefore much harder to confuse. The drawback with this solution, of course, is that nobody really gets the difference between requirements and design. (Somebody just said to me the "what vs. how" thing again today and I almost did justice on them!)

There has to be a better way! I will find you V&V instigator! I will vilify you! You will wish you were virtual! I will vanquish the pain you have caused virtuous software developers. Very truly I tell you, vultures will think it vain to feed on the bits left. Victory is ours.

V on!

Filed under: humor, testing, validation, verification, v&amp, v

Worst Companies to Work For, Part All
15 July 07 07:07 AM | Earl Beede | 3 comment(s)

Steve McConnell (my boss) is bragging about his company since it got voted the best small company to work for in Washington State. He is so proud that he needs to do the bragging in three parts!

I have to admit, it is a pretty nice place to work. Did he mention the free beer? Anyplace that has free beer is a great place to work by definition. Not to mention that I am writing this in my private office while wearing shorts and listing to the blues. Unless, of course, I get too distracted by trying to decided how to spend my many weeks of paid time off. (I am thinking August is no longer good for me.)

Now that I have you all jealous, of course Construx is a great place to work. There are only sixteen of us and we are all contributing professionals. I think you can do things as a small, flexible company that you just can't do other places. What may be more interesting are the common things that make a company a worst company to work for. Not the weird things done by a psychologically disturbed pointy haired boss but the irritating things that happen day in and day out that can make a place a living hell.

Here is my short list:

• Bodily noises from the people who work around you that are better left to the pages of Mad magazine
• Food or drink at a work station that has been there since the disco age
• Print jobs that a) use the last of the paper or b) jam the machine and were launched by a person who just went on a three week vacation
• Anybody who works around you whose teenage children have more ethical lapses than a presidential administration
• Any client or manager who begins a request with the phrase, "It is just a ..."
• The rattle made by the air vent in the ceiling in which you have already stuffed 37 post-it notes
• Application dialogs that tell you that the system has crashed/needs to be restarted and then asks if it is "OK"
• Meetings scheduled for the end of the day because that is, "the only time everyone is available" -- because we want to go home!

Anything else?

Filed under: humor, irritating, worst, best companies to work for

Incremative
01 July 07 07:45 AM | Earl Beede | 1 comment(s)

In our 10x and Agile seminars, I talk about the role and purpose of incremental and iterative (incremative) development practices. On the surface incremative development is kind of wasteful. I mean, it is like asking me to drive to the grocery store and a I stop on each block, call home and ask my wife, "I am one block closer to the grocery store. Do you still want me to get the milk?" By the time I get there, buy the milk, call 10 more times on the way home, ("Do you still want me to come home? What do you mean you are having doubts???") the milk is spoiled and the tea is cold.

There is waste even if my wife were to say to me, "I think I need something at the grocery store, but I will not know until I see it and I am not sure what store I want to go to. Get in the car and start driving." There is wear, tear, and overhead costs in starting and stopping the car. We will take more time to buy the thing-she-may-end-up-buying-but-won't-know-it-until-we-get-there then if she knew what she wanted in the first place. Heck, I may even drive the wrong way and have to retrace my path since I need to guess a bit to choose an initial direction. Why even start a trip like this? It doesn't make sense.

I only have that "waste", however, when I truly have a deterministic outcome. If I can know the final destination, the straight line always will be faster. It is when uncertainty creeps in that I need to be incremative. With uncertainty comes the need to gather information to lower the uncertainty. The "waste" of incremative development is a known cost to buy information and avoid the potentially much larger unknown cost of guessing wrong.

Being incremative is all about lowering uncertainty by getting and acting on feedback. The incremental part of being incremative determines how often I get feedback. Since I have high uncertainty about what the other bozos on the road are going to do, my increments are often very small as I constantly scan the traffic. I don't let my eyes leave the view of the road for long (unless, of course, I need to send a text message on my mobile). The iterative part of being incremative determines what I parts I do over and can change based on the feedback. As I spot a bozo in a red truck coming into my lane, I change my acceleration, vehicle direction and the amplitude of my horn. Based on what the traffic does around me and my desired route, I will change the vehicles parameters many times.

But here is the punch line. Both certainty and uncertainty can live side by side on the same trip. I can be certain of my desired destination (I want to go to the store) but have uncertainty about the traffic, road conditions, etc. on the way there. Saying my trip is completely deterministic because I know I want to buy milk is naive. Saying it is completely uncertain because of the traffic is simplistic. It is both and I need to approach it that way.

So the trick in incremative development is to find the right balance, the point where I buy just enough information to lower the risk to an acceptable level. Too much, and I have unnecessary waste; too little, and I likely to have large undefined costs.

Like when you brought home the non-fat when your spouse really wanted the whole. It's back to the store again! (Note: bad iteration!)

Filed under: humor, increments, iteration, milk