A friend of mine sent me the following. I have seen it before and I thought I would share it.
Computers are like Men…
…In order to get their attention, you have to turn them on.
…They’re supposed to help you solve problems, but half the time they are the problem.
… They have a lot of data, but are still clueless
… As soon as ou commit to one, you realize that if you had waited a little longer you could have a better model.
…They hear what you say, but not what you mean.
My son is getting married this weekend and I suggested the entire wedding should be Agile. That means there is limited planning up front because the bride does not really know what she wants and she keeps changing her mind. The wedding and reception does not have to be delivered all at once because it could be delivered in iterations. If it works for software development then it should work for other things, too.
On the other hand they could take some simple advice from wedding planners.
1. Before going completely into debt for your wedding, create a budget.
2. Allow plenty of time to plan; the more rushed you are the more money you’ll spend.
Perhaps it is a better idea that software developers take some advice from wedding planners instead.
Software development organizations, like people, have patterns. In other words organizational behavior is not random. Organizational behavior, like the behavior of a person, has a pattern and therefore can be predicted. If you study your software development organization I guarantee you will start to see repeating patterns be able to predict patterns and make systematic improvements. The only way to learn about a software development organization is by systematic study. When studying a software development organization it is important to gather data from samples, make conclusions and then forecast the future.
The entire premise of software metrics is the best way to can improve a software development organization is by systematic study. Peter Senge points out in his book, The Fifth Discipline organizations must learn if they are going to survive in a global economy. Software development is a global industry that changes and moves rapidly.
The movie Groundhog Day exemplifies many software development organizations. The basic premise of the movie is the main character, Bill Murray, never learns. Too many software development organizations never learn. They just keep making the same mistakes over and over again.
The best learning comes from systematic study of past projects. Some organizations, like people, need to learn from their mistakes and their successes. Unfortunately many software development organizations, again like people, never learn from their mistakes. These organizations keep making the same mistakes over and over again.
Ethnography
The fancy or academic word for what you are about to do is, “Ethnography.” In ethnography a researcher examines the group’s observable and learned patterns of behavior, customs, rituals, and ways of life.
The lengthy study of Gorilla’s by Dian Fossey is an example of an ethnographical study. If Fossey can successfully study and learn about gorilla’s in the wild, then I am pretty sure anyone can study and learn about their software development organization in an office environment.
Read more at Reboot! Rethinking and Restarting Software Development.
There are few things as predictable as software developers can’t estimate. Nonetheless it software projects follow the same patterns. Most small projects are underestimated by about 10%, medium size projects by 40% and very large projects by more than 200%. As project size increases the error rate of the estimate increases with near mathematical precision.
Estimating problems are not to software development. Gustav Theordor Fechner wrote a book Elemente de Pscyhophysik in 1860. He coined the term “psychophysics.” Over the years all the senses have been studied: vision, hearing, touch, taste and smell and the sense of time. There are three main topics in psychophysical classification scheme: absolute thresholds, discrimination thresholds and scaling. I am writing about scaling. It is clear that the untrained are not good at scaling. On the other hand, those individuals that are good at scaling have been trained and they have adopted some sort of strategy to help them measure and then scale. The point here is that estimating is a skill that can be learned.
The same pattern with estimating is seen over and over again. A person is pretty good at estimating the height of a 20-foot tree and horrible at estimating the height of a 200-foot building. The same would be true when they try to estimate the weight of a rock. They are good at estimating the weight of a ten pound rook and very poor at estimating a 800 pound rock. So it does not matter if we are estimating the weight of a rock, volume of a liquid, loudness, the height of tree or the size of a software project the error rate increases with size. As size gets larger the error rate increases.
Musicians learn the specific vocabulary of dynamics. Trained musicians can hear if one piece of music is being played louder than another piece of music. As the music gets relatively louder they are able to distinguish loudness because they have been trained to do so. Musicians are trained in scaling and they have a specific vocabulary for loudness. They know that piano p means soft while pianissimo pp means very soft. On the other hand they know that forte f means loud and ff means very loud. If they are playing their instrument at p and their sheet music or conductor directs to play at ffff they know that means to turn up the volume about six times. Musicians also know if they are to gradually get louder (crescendo) or gradually get software (decresendo).
You may be thinking that it is lack of experience that prevents people from estimating the height of a tree or loudness. Wansink studied bartenders with an average experience of over ten years. He removed all their devices to estimate the volume of liquor they pour into a glass. When their strategies and measuring devices were removed they were unable to pour the correct amount of liquor into a glass.
The same would be true with musicians. If suddenly all the symbols and strategies used by conductors to communicate with musicians were removed, then the musicians would have a difficult time playing at the right volume and right tempo. The musician would be constantly asking, “How much louder or softer?”
One of the values of measurement in software is it provides a vocabulary to communicate. It allows developers to communicate with the core business and explain how much larger. Software developers are not aware of the importance of scaling. They do not understand scaling is critical to sizing software projects. The absence of a measurement of scale or an ability to size a software projects prohibits one software project to be compared to other software projects.
WeightWatchers trains dieters how to estimate their food consumption. It is not just the amount of calories to consider because the grams of fat and fiber are a important too. Calories, fat and fiber are combined to determine points. The point system is a method of scaling food consumption. The “points” allow one food item to be compared with other food items.
The reason software development can’t estimate is because they don’t measure. Those few that are successful at estimating software projects have adopted a strategy to size and scale projects. The best estimators are those that base their size on functionality.
Read more at Reboot! Rethinking and Restarting Software Development.
Many software organizations are left with the mistaken belief they are doing fine when in actuality they are not. Individuals in these organizations actually believe they are doing a “quality” job . These individuals have this false belief because they do o not have the fundamental skills necessary to realize they are actually doing a poor job.
One of my favorite psychology papers is called Unskilled and Unaware. The premise of the paper is when people are incompetent they suffer a dual burden. First, they reach erroneous conclusions and make bad choices. Second, their incompetence robs them of their ability to realize they are making bad choices and they are left with the mistaken belief they are doing fine. Since they think they are doing fine, they will never learn from their mistakes. They will never make an effort to improve until disaster strikes.
Those skills making one competent in a particular domain are often the very same skills necessary to evaluate competence in the domain. Because of this, incompetent individuals lack what cognitive psychologists call “metacognition” or self-monitoring skills. In other words they are just too ignorant to realize they have a problem.
Read more at Reboot! Rethinking and Restarting Software Development.
Over the next few weeks I am going to write about how to improve software requirements. Most software organization cannot get requirements right. It is not uncommon for software requirements to grow two to three times throughout the software life-cycle. I argue that software requirements is the largest unresolved issue facing the software industry.
There have been many software methodologies that have attempted to resolve the requirements problem, but none are long lasting. Agile methodology recognizes the problem of poor requirements but fails to provide the right solution. As one Agilista wrote me, “Extreme helping the customer figure out what they want is not part of Agile.”
The role of the software developer needs to be helping customers define what they want in a software application. Most software organizations skip this step. Customer often cannot define what they want because they lack the basic vocabulary to do so. The software developer needs to develop the skills of asking the right questions.
Imagine a customer who wants to buy a computer being asked the question, “What processor speed do you want?” Now compare and contrast that with the question, “What do you do with your computer?” A better question is, “What would you like to do with your computer?” The processor speed depends on what the customer wants to do with his or her computer. The customer does not know the answer to, “What processor speed do you want?”
The root cause of requirements growth is a lack of understanding of the business problem that needs to be addressed. The problem is those tasked with creating software rely on customers to articulate what is needed. To often customers cannot articulate their needs because they do not have the basic vocabulary to do so. Customers may lack the vocabulary to explain what’s wrong and especially what is missing.
Sometimes what people say they do is not what they really do, and what they say they need to do their jobs is not what they really use (artifacts). It is important for the software developer to determine what is really needed and not rely on customers to tell them what is needed.
A friend of mine sent me the following cartoon. It reinforced what a software manager told me, “I don’t manage programmers, I manage freakin prima donnas!!” He was discussing his trials and tribulations of managing a technical team. A prima donna is the first lady of the opera. Prima donna’s are egotistical, unreasonable, and they have a high opinion of themselves. The term is used to describe a vain, obnoxious and temperamental person who, although irritating, cannot be done without. Sound familiar?
It is summertime and I need a new lawnmower. Lucky for me a friend of mine named Bob is selling lawnmowers. Bob use to be a software developer who specialized in gathering requirements and became an advocate for Agile Software Development. I felt bad for Bob because he was recently laid off from Megatelecommunications Company With Way Way Too Many Employees, INC.
I went to the the lawnmower shop where my friend was working and met up “Bob.” After the obligatory greeting of “hey, how’s it going,” “how is so and so,” and “who is working here and there,” we got right down to business. Bob said, “How much horsepower do you want?” I thought, “What is horsepower and how does that relate to cutting grass.?” so I responded, “What are my choices?” Bob said, “2, 5, 6, and 7.” I stood and kind of stared at Bob and he said, “David, if you can’t tell me how much horsepower you need, then I can’t really help you.” I figured that more was better so I responded, “7.” Bob said, “Good choice!” I started feeling better.
“The next thing you need to tell me is how big you want the cut diameter.” I said, “cut diameter?” Bob rolled his eyes and said in a condescending manner, ” Yeah. the cut diameter.” Bob said, “Your choices are 20, 21, or 22 inches.” This time I choose a number in the middle and said, “21 inches.” He chuckled and said, “You can’t get a 7 horsepower with a 21 inch cut diameter.”
Bob asked, “How many speeds three, six or variable speed?” I asked, “What do you recommend, Bob.” Bob quipped back, “You have not done your homework have you?” He continued on and started lecturing me and said, “David this not hard. You need to go home and start doing your research. There are plenty of online resources. When you have figured out what you need come back and talk to me.” I felt a bit stupid and left the lawnmower shop.
I was driving home and noticed another lawnmower shop and thought I would pull in and do a bit of research. As I walked in a nice man greeted me with a big friendly, “Howdy! I’m John what brings you in today.” I said, “I am looking for a lawnmower and I need to do some research.”
John said, “Can I ask you some questions?”
“Sure.”
He asked, “How big is your yard?” and I responded, “Oh about 3/4 of an acre.”
“Do you like to cut your grass?”
“I hate it.”
“Are you trying to get some exercise when you cut your grass?”
I looked at John in a sort of curious manner and he said, “The reason I am asking these questions is to figure out your needs. If you want to get some exercise while you cut your grass then you may need a push mower. If on the other hand you just want to get it over with as fast as possible you may need a riding mower.”
I nodded and said, “Oh, okay.”
John kept asking questions like, “Will your wife and kids use the mower or will it be just you.” After sometime and a bunch of questions John smiled and said, “Let me make some recommendations for you based upon your specific needs.” He walked me over to a mower and explained to me how it would benefit me. I thought this guy knows his stuff.
I was really excited and purchased the mower from John. Then I thought about Bob. I thought, “I never really liked that guy.”
There is an ole adage that says, “No good code was written before midnight.” Of course it is okay to work late, but you should probably avoid drinking and coding. It is probably a good idea to avoid any decision making and drinking.
Read more at www.RebootRethink.Com
I don’t know why I waste my time teaching statistics and quantitative methods when I could be teaching people how to use the force instead. Do you remember how Obi-Wan Kenobi (Ben), teaches young Skywalker how to use the force? Luke is training against some type of floating ball. Of course Luke can’t hit the small beams coming at him from inside the floating ball. Obi-Wan blindfolds young Luke with a helmet and says, “act on instincts.” Obi-Wan encourages Luke to ignore his eyes. Once Luke is blindfolded and uses the force he is able to hit all the small beams coming at him. In software development we call act on instincts expert opinion. It seems like software developers use the force.
Too often when someone is asked, “How did you come up with your estimate?” they reply, “expert opinion.” They are acting on instincts instead of using quantitative analysis. Don’t get me wrong often instincts can give you insight into estimates and understanding projects status, but it should not be a substitute for quantitative methods.
The best part of the movie Star Wars Episode IV is when Luke is making his final approach to destroy the Death Star. He is flying at a couple times the speed of sound and he has to hit a small target which is about one foot by one foot. Time is running out and all the other attempts have failed to destroy the Death Star. Luke hears the voice from the other side (Obi-Wan), the voice says, “Use the Force Luke.” Luke looks around and thinks about it and the voice tells him, “Luke trust me,” so Luke turns off all the quantitative instruments. Of course, Luke launches his rockets guided only by instinct and they are right on the mark and the Death Star is destroyed. My advice is when creating an estimate, or when asked about project status it is best to let the force guide you. When asked how you came up with your estimate simply respond, “The force was with me” and refer them to the Star War movies or this blog.
Just imagine how your next performance review could be worded. In the Stars Wars movie Darth Vador says about Luke, “The force is strong with this one.” Now wouldn’t it be great if your boss would write that about you. That is something you could put on your resume.
Read more at Reboot! Restarting and Rethinking Software Development.
Quips On Software Development 
You must be logged in to post a comment.