Stone Cold Coder meets Diva Developer!

Cheech and Chong, a 1970’s comic act, portrayed themselves in one of their skits as Siamese twins that were not identical.  They were paternal twins physically connected at the hip.  Of course this was impossible, absurd and a very laughable idea.  Whenever I hear about pair programming I can’t help but think about Cheech and Chong and the absurdity of the idea.    It is like asking two teenagers to share a mobile phone.   It ain’t going to work folks.  It is absurd and laughable.

The idea is that one programmer writes code and the other programmer stands over his or her shoulder and watches for mistakes. When the first programmer gets tired they switch positions.  I think they are suppose to touch hands like professional wrestlers do in a a tag team wrestling match.  How cool would it be to called something like Stone Cold Coder or Diva Developer.  You could go to work dressed in costume.  Instead of programming sessions you could have smack down coding sessions.

You don’t have to implement Agile to try out  the idea of pair programming.  I would suggest  trying pair writing.  Have one person start to type and have another person stand over them and correct them as they go.    This is an awesome idea! I am curious to see how long this process would last.  How about pair cooking?  You have one person cook and another person correct them as they go – nice.  How about pair driving?  You could have one person sit in the backseat and correct the driver.  I think that is called back seat driving.  Sorry pair programming is a joke of an idea and absurd.

——————————————————————————-

Want to read more about “pair programming”

http://blogs.atlassian.com/developer/2009/06/pair_programming_is_kryptonite.html

Reboot! Rethinking and Restarting Software Development.

Agile Methods and Other Fair Tales

If you are having a hard time coming up with a pseudo name for your pair programming team check out the auto Professional Name generator at  wrestles – http://www.wrestlingname.com/

Professional Wrestling –http://www.wwe.com/

Want to read more about “pair programming”

http://blogs.atlassian.com/developer/2009/06/pair_programming_is_kryptonite.html

Advertisements

The great exalted software guru measures time in bytes

The great exalted software guru measures time by the size of the USB drive I give to him. I brought with me a 16 GB USB drive able to fit on a key chain to give to the guru. I laid the new 16GB drive at his feet and the guru picked it up and examined it closely.

He said, “It has been a long time since you last visited.”

I asked, “How long has it been?”

The guru replied, “It has been 15 gigabytes ago.”

Yes, the guru was right it had been a long time. The guru said, “You first visited me 16 gigabytes ago.”

I said, “How can it be that I gave you a 16 gigabyte USB drive today and I have visited you many times before.”

The guru smiled and said, “Time begins now not yesterday.”

I thought I am going to need a bit more explanation than that and I started to speak and say, “Exalted software guru…”.

The guru held up his hand and I stopped. The guru continued and said, “In software the first day of learning starts today not yesterday.” I started to speak again and the guru held up his hand to stop me. The guru said, “skills that were useful yesterday are not useful today. Those skills you develop today will not be useful tomorrow. This is why software professionals need to learn something new every day.”

He reached under his rob and scratched himself. I felt a bit uncomfortable not knowing how to respond and then he pulled out a 5 ¼ floppy disk.

I thought, “640KB.”

He said, “no 720KB.”

I said, “16GB minus 720KB is really just about 16GB, so the 720KB is insignificant.”

 The guru smiled and said, “YES!, what you learned in the past may not be useful today or tomorrow.”

I asked, “if skills that I learn today are not useful tomorrow then why learn them today?”

The great exalted one held up his hand and said, “Why do you keep trying to interrupt me?” I apologized and he continued and said, “you need skills today and you need to learn tomorrow’s skills today too.” I nodded because I started to understand.

Just like he always does the guru picked up his new 16GB USB drive and walked back into his cave. He waved and said, “I will see you in a few terabytes.” It was his way of saying I will see you soon.

 I walked down the hill and thought what I had learned today. I need to learn something new every day about tomorrow. I can’t live off of the technical skills I learned in the past. Then I thought, “I wonder where I can buy a 1 terabyte USB drive.”

More from the guru…

https://davidlongstreet.wordpress.com/2009/04/27/the-software-guru-speaks-again/

Pay no attention to the little man behind the curtain!

The little dog Toto pulls back the curtain and exposes the Wizard.    In this most embarrassing moment the Wizard thunders out, “pay no attention to the little man behind the curtain.”  Well, there are many IT organizations and IT “professionals” saying the same thing these days.  Too many IT professionals are Wizards pretending to be something they are not.  They manipulate knobs and dials creating a lot of smoke and noise.  They give the appearance what they are doing is really complex and sometimes even frightening.   When challenged they will speak in techno talk in hopes they will not be challenged.

 Over the years, I have pulled back a lot of IT curtains and heard over and over again “pay not attention to the little man behind the curtain.”

Watch out for fling monkeys too!

Read more at Reboot! Rethink and Restarting Software Development

Technical Support Cheat Sheet – Cartoon

A friend of mine sent me this cartoon that outlines the steps necessary to solve most technical problem. The great thing about this cartoon is that helps people learn the steps necessary to solve problems instead of providing an answer.

Technical Support Cheat Sheet

Technical Support Cheat Sheet

Read  more at Reboot! Rethinking and Restarting Software Development

Published in: on August 24, 2009 at 11:20  Comments (2)  
Tags: , ,

Is software an art form?

If software was truly an art form, then the same adjectives used to describe art would be used to describe software.   I often software developers ask, “What three words best describe your software applications.”    Seldom do I hear words like, beautiful, elegant, sophisticated or graceful.   On the other hand,  I have had many  say, “Alt, Control, Delete.”

Published in: on August 5, 2009 at 06:56  Comments (1)  
Tags: ,

IT the toilet that never stops flushing

I was consulting for a large international firm and one of the executives on the business side made the comment that, “IT is the Toilet that never stops Flushing.” To often this is an accurate phrase to describe how money is spent in IT. Most of us have had a running toilet in our bathrooms and it can be very annoying. In the end a running toilet is just money down the drain and too often spending money on IT is money down the toilet too.

Over the past 20 years a lot of IT spending was done without careful cost benefit analysis.  Too many projects were undertaken because there was a desire to move to the latest and greatest technology.  The current recession is causing IT to really justify its spending.   The business is forcing IT to wiggle the handle to see if they can’t stop the water from running.

Even though the current fade de jour is build as you go or ad hoc software development it is an expensive proposition.  Those IT organizations that embrace, study, and learn  the core business are the same organizations with the highest productivity rates, best quality and lowest costs per unit.

Read more at Reboot! Rethinking and Restarting Software Development

What gets rewarded gets repeated!

A behavior followed by a reinforcing stimulus results in an increased probability of that behavior occurring in the future. – B.F. Skinner, Psychologist

The idea of “what gets measured gets done” is only partially correct.  It would be more correct to say, “what gets rewarded gets repeated.”  One of the most thoroughly accepted notions in psychology is the principle that behavior eventually extinguishes if it is not followed by reward.

I was on an airplane and in front of me was a father and his young daughter (she was about 3 years old).  When it came time to take off the father worked and forced his daughter to sit down in her seat with her safety belt fastened.  The child screamed and yelled.  The child wanted out of her seat. As an outside observer, I understood if he let his child out of her seat, the child would learn that the way to get out of her seat is by yelling and screaming.  The father gave in and let the child out of her seat and stand up.  The flight attendant had other ideas and told the father his child had to be seated.

Let’s look at the behavior and the reward.  The father’s behavior of allowing his child to stand in her seat was immediately squelched, and he was forced to follow the rules.   Can you imagine what happened the second time the father tried to fasten his child in the seat?  The child was more resistant and screamed even louder.  The father made the situation worse by giving into the behavior the first time.  In other words, the father rewarded the behavior of screaming and yelling.

Non-negotiable estimates
I was working with a manager, and I watched him interact with his client (an internal client). The manager estimated it would take 600 hours to complete a project.  His client pushed and challenged him, so the manager reduced the project by 100 hours.  This is a 20% reduction in time.  Then his client pushed a bit more and got the estimate reduced another 50 hours down to 450 hours.  This is a 25% reduction!  Whoa!  What behavior did the manager exhibit and reward?

Estimates need to be non-negotiable.   An estimate should be created using a quantified method.  That means there is some method to creating estimates.  Put some data into a formula and derive the result.  The only thing you should be willing to budge on is the inputs.   There are several inputs with an estimate including size of the project, deadlines, staff, so on and so forth.  Hence, if the estimate is too high, then one of the inputs needs to be changed.
Unfortunately, what traditionally happens is that an estimate is nothing more than a guess.  The estimate has no substance at all; in other words, it is not based upon historical performance or statistical modeling.  Often when working on a contract I ask the question, “How did you come up with your estimate?” More often than not the person actually admits it was a guess.   Another common answer begins, “based upon my vast experience as a software professional.”  In other words, questioning the estimate is the same as questioning their integrity.    It is important for an estimator to be able to quantitatively explain how they derived their estimate.
Unfortunately software development is full of bad behaviors that get rewarded and get repeated.
Read more at Reboot! Rethinking and Restarting Software Development

Measure what is not measurable

It does not matter what is trying to be done, if it can’t be measured, it  can’t be understood , controlled, or predicted.  If it can’t measured it  can’t moved forward.  If the software development process can’t be measured it can’t be understand it.  Measurement has been the basis of all science since the time of Galileo.   The idea of measurement is nothing new; it is only new to the field of software.  If the software development process is not measured it cannot be studied, it cannot be understood, and it is difficult for the organization to move forward. Measurement is one of the most ordinary actions.  We speak its language whenever we exchange goods or information.

Better A Surgeon’s Notes on Performance is a recent book written by Atul Gawande.   The book is an investigation into how medical professionals can progress from good to great.    Many of the lessons outlined in the book apply to everyone including software developers.  Gawande recommends, “Count something. Regardless of what one ultimately does in medicine or outside of medicine – one should be a scientist in this world.”    This applies to software developers too.  To be considered a scientist, something needs to be counted and measured.   It is common for software developers to refer to themselves as a computer scientists or software engineers.  Both of these titles imply utilization of the scientific method, systematic study, and measurement.

Knowing something
The most common and accepted way to know something is through systematic study and utilizing the scientific method.  Another way to know something is through personal experiences.  Through all experiences, each individual constructs a “reality” of the world.  The danger arises when this method is the only method since biases develop or information can be distorted. Often, the events experienced represent a biased sample that in turn can lead to inaccurate conclusions.   Most biased individuals do not see themselves as biased, and often they defend their opinions with a lot of passion. Basically, the scientific method is a set of assumptions and rules about collecting and evaluating data.  The idea is to reduce bias as much as possible, and the proof of the science is the data. “Stripped of fall its glamour, scientific inquiry is nothing more than a way of limiting false conclusions.”

The real conflict in software  is between systematic study and personal opinion.  There are a number of software professionals who rely on personal experience and hold the misconception that systematic study and measurement of the software development process is not possible or not necessary.  Some believe that measuring the software development process is just too complex.

One reason why software professionals do not measure is because they do not have the necessary basic quantitative and qualitative skills.  They do not know how to study a software environment.  Many of them studied computer science where there was an emphasis on learning programming languages instead of learning about the software development process. The emphasis has been on writing code and not on the idea of developing software to solve customer problems.   Since the emphasis has been on programming, it is hard for a programmer to explain how he or she knows what they know.  There is also limited knowledge and experience of what goes on before  code is written and what happens after it has been written.  The reason for this is because there is little interaction with the actual customer or the person who uses the products.  Many developers do not have the desire to know the customers either.

Read more at Reboot! Rethinking and Restarting Software Development

“I will tell you… I don’t know…its Tradition!”

Some friends or mine David and Jo Cowdery operate a vineyard and winery in the south of France called Chateau La Bouscade. They have received several awards for their wines, so I was excited when  I received a couple of bottles wine from them.    What I found interesting is the bottles were sealed with screw caps not corks.   Since I do not know a lot about wine, I asked my friend Jo, “What’s up with the screw caps?”  She laughed and told me that screw caps were far superior than corks.  She told me that all the wines at Chateau La Bouscade have screw caps.   “Say it ain’t so, Jo!”

The scientific evidence is overwhelming that screw caps are better than corks in a bottle of wine.   It turns out a bottle of wine with a cork has at least a 1 in 10 chance of having cork taint.  Cork taint ain’t a good thing either.  It makes wine smell like shoes or a wet dog.

So what does this have to do with software? A lot. I have spent years gathering scientific evidence on the best methods to develop software and the scientific evidence is overwhelming.  I am not alone because organization like SEI and QAI share my findings.  Just like it is hard for get consumers of wine and wine makers to change it is hard to get software developers to abandon traditions.

So why do wine makers still use corks and how did this tradition get started?  Tevye a character in the Fiddler on the Roof sums it up nicely, “I will tell you… I don’t know…its Tradition!” The same can be said about software development.   I don’t know why so many software organizations refuse to adopt best practices.

There is an old proverb saying, “Seldom does Saul become Paul.” It means that seldom do people actually change.  What happens is a new generation has to grow up with the idea from the beginning.   There are pioneers like David Cowderoy who lead the way for a whole new generation of wine makers.    The new generation starts with the idea from the beginning.  A new generation of human factors engineers are going to be the future of software development.   These human factors engineers understand the importance of studying actual users and customers.  One best practice is to study the business and not to be passive in the requirements process.

I was speaking at a conference and I was asked the question,  “if things like metrics are such a good idea, then why don’t more software organization adopt metrics?”  I don’t know why?  I don’t know why people are overweight or why they smoke or why some wine makers still use corks.  I guess it is like Tevye says, “Tradition!”  Because It can’t be explained with logic.

Cheers!

Read more at Reboot! Rethinking and Restarting Software Development.

———————————————————————————-

For my  non American friends
“Say it ain’t so Joe” is a reference to Shoeless Joe Jackson who was accused of fixing the outcome of  the 1919 World Series.  Legend has it that as Jackson was leaving the courthouse during the trial, a young boy begged of him, “Say it ain’t so,  Joe!” and that Joe did not respond.

To learn more about the argument of screw tops v. cork  see http://www.hoguecellars.com/feature/homework.html

Hello, Good Bye, Howdy, John Wayne!

Some years ago I was traveling in China.  My client had written out directions for me in English, so I could find my way to the worksite.  My plan was to take the train from Beijing to a small town where my client was located.  At first, all was going well, but the signs started to change from Chinese/English to just Chinese.   I asked some other travelers on the train for assistance but, since my instructions were in English and I did not speak Chinese, they could not help me.   I decided the best strategy was to get off the train at the next stop, which I did.  I found myself standing in a small village in China with chickens running around on a dirt road.   I was standing there in a suit and tie holding my computer bag.   I had one of those profound, obvious thoughts – I am lost.

At the end of the road, I noticed one sign that was in English.  The letters read, B A R.  So I ventured to the BAR in hopes of finding someone who spoke English.  As I entered an elderly Chinese man looked at me with some excitement and said, “Hello! Good Bye! Howdy! John Wayne!”  That was the extent of his English, but that did not deter me from trying to communicate with him.  I tried to explain, in English that I was lost.  He  smiled and nodded, then he poured me a large glass of beer and handed me a sandwich.   Keep in mind it was about 10 am., I was in China, I was lost, and I was drinking beer.

Suddenly, the elderly Chinese man left the bar.  I drank the beer and finished the sandwich, and I was not sure what to do next.  Since I had no idea as to where I was,  I just sat there. After about twenty minutes, he returned with a young boy who turned out to be his grandson.  His grandson told me, in English, “My grandfather came to my school and told everyone there was an American in his bar. No one believed him, but he insisted; so, I came along to translate.”

The young boy read over my instructions and, luckily for me, he understood my predicament.  He translated all the train stops from English to Chinese.  He told me he would escort me to the train station and helped me purchase a ticket to where I needed to go.  I started to feel a sense of relief.   As I departed the bar, I asked how much I owed for the beer and sandwich.   The young boy translated for me and then said, “My grandfather says you are his American friend, and there is no need to pay.”  I thanked the elderly man. He bowed toward me and, instinctively, I bowed back.

Software development is also lost. It is as if we cannot communicate with anyone other than ourselves; and too often, we can’t even communicate with each other.  When customers and clients ask us the simplest questions, we tend to answer with jargon.  Over the past decades development fads have come and gone.  In the late 1990’s the development fad was RAD (rapid application development); we moved onto iterative and today, the fad “de jour” is Agile.    Some of the fads are actually good ideas and have positively impacted software development while other fads have caused great damage.  What all the past and current fads have in common is that they were developed because software development is lost.

Just as there was a lack of understanding between the elderly Chinese man and myself, there is a real lack of understanding of those interfacing with software development.  It seems software development lacks the necessary vocabulary to communicate and understand their customers.  There is a lack of understanding between industries and disciplines that have gone before us, yet there is a lot to be learned from them.

Read more at Reboot! Rethinking and Restarting Software Development
Published in: on June 23, 2009 at 07:22  Comments (1)  
Tags: