Are we doomed?

Is History Repeating Itself?

About one hundred years ago blacksmiths were considered a highly skilled occupation and like software development, it was labor intensive.  While the blacksmith had been around for centuries, it was the Industrial Revolution that created a rapid growth in employment from 1880 and  1915[1].   The blacksmith was critical to the Industrial Revolution, and the software developer is a critical component of the information and knowledge revolutions.

If, in 1915, someone would have suggested to the million plus blacksmiths employed in the industrialized economies they would be obsolete in less than 50 years, they would have thought that person crazy.  The idea of working with metals, fabricating metals, did not evaporate; it was the role of blacksmith that became obsolete.    The role of blacksmithing turned into ironworkers, and those blacksmiths that did not learn the new skills of ironworkers were not able to find employment.

Instead of creating everything from scratch metal workers (weldings) began to assemble parts and pieces together.  We are seeing this same basic trend in software development today.

As software development rolls down the road of progress, the programmer will become obsolete; and the idea of software developer will continue into the future.  I imagine there are those reading proclaiming, “You will always need someone writing code,” and I am sure there were those blacksmiths who could not imagine a world without them, either.  It will be a combination of automation and outsourcing that will make the Western programmer obsolete.

The story of the blacksmith does not end with the decline of employment.  Today blacksmiths are artists and a novelty profession.  The British Artist Blacksmith Association (BABA) continues blacksmithing as an artist profession as well as offering courses on blacksmithing, and they have regular events..   It has nearly 700 members worldwide and their members create brilliant works of art.

---

[1] United States Statistical Abstract 1915.  Page 233 Table 158

Scaling Music and Software

I am working on a lecture for my economics class about production theory.  Production theory works nicely for software development, music and    information workers too.

Output is the result of labor and capital.  The amount of music produced is the result of musicians (labor) and instruments (capital).    As more and more musicians are added to the process of making music the process of making music becomes more formal and there are overhead costs.

If we start with one musician playing a piano, then there is not much overhead required.  Add  three musicians and you get a quartet and there is some communication that needs to take place.  Add about 96 more musicians and you get an orchestra.

The cost per output (the average product) begins to rise because you have overhead costs.  If you have about 100 or so musicians you need a conductor.   Sheet music is required too (formal documentation not necessarily required for a small group).  We see the marginal cost, the cost to produce additional music, begins to rise.  The reason are additional labor is required that does not produce music directly.

This same model works for software development too.  Output for software is the amount of functionality produced.  As the project scales upward formal processes are just required.   There project resources (labor) required such as a project manager.  Formal methods and documentation is required to help in communication.

So there you have it…. Production theory works for information workers.

Quality 911

I was channel surfing and came across the show Nanny 911.  The premise of the show is that there are families who cannot control their children, so they call Nanny 911.  The nanny focuses on the behaviors of the parents rather than the behavior of the children.  A nanny trying to control the behavior of children is analogous to putting your hand in a bucket of water in hopes of displacing water.  Your hand displaces the water, but as soon as your hand is removed, the water goes back to its original position.  The same analogy holds true for the quality department.  It is impossible to enforce quality standards within an organization without holding management accountable.

The nanny teaches parents that children need to have boundaries, and children need to understand there are consequences to their behaviors. Generally, the consequence for the children is timeout.  Since there is no adult time out, a manager can’t put an employee in time out; so, other types of consequences must be adopted.

Too often, quality consultants are focused to helping employees implement a process or fine tune existing processes.    They need to be working and consulting with senior management so management understands they have a role in implementing quality programs.

The bottom line, folks can work, talk, train, cajole, sell, and communicate process until blue in the face; but if management does not enforce the desired process, then the process is not going to happen.  By enforce, I mean there have to be consequences to following the process and for not following the process.  A consequence does include loss of job.  Many successful managers I have worked with do fire people for not following the process, and they also reward those who do follow the process.

Why do most diets not work? What does this have to do with software development?

Why do most diets not work and what does this have to do with software development? It turns out that diets don’t fail, but people fail to stick with the diet. The secret to losing weight is a pretty simple concept and hard to do. The secret, of course, is to eat less food, drink less booze, and exercise. The bottom line is if you burn more calories than you take in you will lose weight.

Most software process improvements don’t actually fail. People fail to stick with the process improvement just like most people fail to stick with a diet. When you think about it a diet is a process improvement plan too.

To stick with any process improvement takes a tremendous amount of discipline. It takes discipline to lose weight and it takes discipline to develop good software too. This little snack here or there adds up to a few extra pounds just like this little short cut here and there adds up crappie software.

Cooking and Communication

This past weekend I tried a new recipe that turned out brilliant. I can’t take too much credit because I followed a recipe provided by America’s Test Kitchen. There are a lot of analogies between cooking and developing software. Not all recipes are created equal and some are better written than others. The same is true of documentation. The point of cookbooks and cooking shows is to communicate a process to another person. This is also the reason behind documentation. In other words, documentation is an attempt to communicate a process to another person.

I like America’s Test Kitchen because it provides videos with detail explanations of the science of cooking and written recipes. Not only do they provide a detail explanation of how to prepare the dish in both written and video formats, they also explain the science of cooking. On the other extreme is learning to cook by trial and error. Learning to develop software by trial and error seems to be the norm rather than the exception in software development.

Many of us learned to cook from our grandmothers by verbal instruction. My grandma left off steps or failed to emphasis a specific point (she would tell you that I was not paying attention). If grandma was in a hurry she was terse in her explanations. This is the same problem when verbally explaining how a software process should work. Experts often leave off important steps or fail to emphasis a specific point. They often blame the user for failing to understand too.  Another excuse is not having time to communicate and this can be overcome too.

Complex system requires better communication

The whold idea of communication is a process.  The more complex a dish becomes the more complex the explanations need to be. The same is true with software because the more complex the product the more detail and clear the communication needs to be.

Application communication can take on many forms including written documentation (recipes), verbal communication, and even video explanations. Cooking is a repeatable process It turns out that cooking is just a repeatable process and there are a lot of ingredients that go into making a great dish or dessert. The better the communication of the process the easy it is to follow, understand and repeat. The better the understanding a person has of the cooking process (and especially of the cooking science) the easier it is to create a something new. The same is true with software development. The better the communication the easier it is for others to understand. The more one understands about the science of software the easier it is to create something new and different.

America’s Test Kitchen http://www.americastestkitchen.com/corp/about-americastestkitchen.asp

13 Ways to Improve Communication with your clients
http://designm.ag/freelance/communication-with-clients/

14 Quick and Effective Communication Tips for the Time-Challenged

http://www.sitepoint.com/blogs/2009/10/12/quick-communication-tips/

Drinking from the Fire Hose of Information!

Drinking from the Fire Hose of Information or five things to do to improve status reporting.

When providing status of a problem it is important to provide the right level of detail, so the situation can be easily digested. A lot of technical team members provide status and it is like trying to get a drink of water from a fire hose. They tend to provide so much technical information the person on the receiving end is totally drenched in information, but thirsty for status.

 The objective is not that everyone understands the technical nuts and bolts of the problem; rather, the objective is to gain confidence the problem is being handled appropriately. Status should include items like:

1. Who are the customers impacted?
2. Have the customers been notified?
3. Have the customers been shown evidence the problem has been resolved?
4. What caused the problem?
5. What steps have been taken to make sure the problem does not reoccur?

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

Brunelleschi’s Dome

In the late 1200’s it was decided that Florence needed a cathedral that would rival the cathedrals of London and Milan.  The original planners had envisioned a cathedral with a dome that would be the largest dome ever constructed.  They decided to move forward with the construction even though the designers were not certain how the actual dome would be constructed.

Brunelleschi's Dome

For nearly a century it was obvious that no one in Florence or anywhere for that matter had any clear idea how to construct the dome.   All attempts to build the dome had failed and the cathedral was domeless.  While the intent of the dome was going to represent civic pride it instead was a constant reminder of failure and embarrassment.   The story does not end here.

The original planners had been overly ambitious.  All contemporary building knowledge had been exhausted.  The man that would eventually design and oversee the construction of the dome was named Filippo Brunelleschi.    Brunelleschi believed the secret of the dome was not in contemporary knowledge but held in the past.  He would resurrect forgotten concepts by studying the ancient architecture of Rome especially the Pantheon.  He spent over a year studying the Pantheon and it eventually gave up its architectural secrets and he had his solution.   He designed and constructed the largest unsupported dome in Christendom. The dome is an architectural achievement that architects still marvel at today.

Sponsors of software projects can be overly ambitious too.  One of the problems with iterative development such as Agile is it is based upon design as you go. One of the problems with designing as you go is the probability of creating undesirable constraints. Brunelleschi knew he could not tear down what had already been built.   He could not start from scratch.   The outer walls of the cathedral had already been constructed and this dictated the size and shape of the dome.  The same thing happens in software development where previously written code and design constrain all future solutions.

The requirements of the project need to be outlined and the technical solution needs to be understood.  The degree of understanding needs to be in proportion to the importance of the problem.  It was not a good idea to start construction of the cathedral without a clear understanding of how the dome would be constructed.   Lucky for inhabitants of Florence and everyone who has visited the city that Brunelleschi appeared on the scene.

Brunelleschi documented his project in secret code he only understood to maintain control over the project. He even refused to explain the details of his plan to the project sponsors. They had no choice but to tolerate Brunelleschi’s difficult and uncompromising behavior.   He documented the project without any intention of communicating, so clearly the reason he documented the project was because it was too complicated for him to do all the analysis in his head.

Brunelleschi’s Dome: How a Renaissance Genius Reinvented Architecture (Paperback)