What is "Software Seasoning"?

Software Seasoning

September 29, 2010

I have been reading an interview with the late Hiromu Naruse entitled "What is 'Automotive Seasoning'?". Naruse was known as a "meister of automobile manufacturing". Naruse compares the inception, creation, and completion of an automobile to that of preparing a culinary dish. For me the analogy is clear and meaningful. I love automobiles and I drive as many different types as possible. It doesn't matter if the automobile is a Honda Civic or a BMW 3 series, I enjoy "tasting" each vehicle and judging if the automobile was satisfying in its role. 

Is there flavor to software products? I believe so. I will follow the flow of Naruse's interview and compare it to software. 

The performance of the software, the minimum system requirements, the list of features, and other "specs" of the software are simply the ingredients. Having all of the "right" features does not determine the quality of the software or whether it will impress the users. The goal of "software seasoning" is to provide the customer with the optimal product. Just as there are many different types of cars made for many different purposes and many different dishes there are many different types of software, from text editors, to games, from shell's to windowing environments. 

The flavor of the software should be adjusted to its specific characteristics. What are software characteristics? 

Two important ones are "flow" and "use". 

The software will have a purpose for which it is used and the work will progress with a certain flow. Complex software will have "inner" activities that will have their own flow. In that sense software can be similar to an entire meal instead of just a single dish. Each "inner" activity would be like a course of the meal. Refactoring software is not "seasoning" software. The seasoning of software is centered around how the user feels about the product. The fine tuning or seasoning of software results in true user satisfaction. 

A software user's experience can be changed greatly by moving an item in the "flow" or positioning a control in a different location. Naruse describes the quality of the ride of an automobile is related to the "logitudinal G-force". The quality of the software user's experience can be enhanced by such well known things as uses multiple threads to complete the initialization of the software thus giving the user the ability to interact with portions of the software sooner while other portions are still loading. I relate this to how the courses of a meal are delivered. While you are eating the soup the salad is being prepared. If you ordered your meal and then had to wait until all the courses were prepared before any course was delivered the overall experience would be tainted by the initial long wait. Everyone knows about using multiple threads for initialization, but since we all know about that practice it makes it an excellent example. When the technique first came into practice those that used it had a more seasoned product than those that did not. Now that practice is common to all and therefore not interesting anymore. It is up to you to find new ways to season your software. 

Naruse makes an interesting observation, "most people cannot really tell the difference between high-end brand clothes and relatively inexpensive clothes simply by looking at them, but when worn, the differences become apparent." 

Looking at feature lists and screenshots is not sufficient to determine the flavor of a software product. Usage allows the difference to become apparent. 

Naruse also points out that we get tired of food that tastes too good. That is interesting. Do people get tired of software that is too good? I can think of examples where this is the case. I will leave that as an exercise for you to see if you agree. 

True flavor comes out after years of use. This is an interesting point. Software changes quickly and often very drastically. Naruse says, "It has been commonly said that people get tired of a beauty after three days. With a car, as in the case of my dear wife, the true flavor comes out after years of being together, through thick and thin. As with one’s spouse, it is the odd imperfection that gives a car its unique character and appeal." 

If you have ever participated in a major change of a well established software product there is often a quick and vocal expression of dissatisfaction with the new flavor of the software. Removing all imperfections does not create quality. I like McDonald's fries because of their particular "over" saltiness. I can not sit down and eat McDonald's fries all day long because they are too salty for that. But they are "just right too salty" for certain occasions! I also like the fries from "Five Guys" and from "In N Out" but if you combined all three of these fries to make the perfect french fry do you think you will succeed? In other words, there are times when I like the salty quality of McDonald's fries. 

Naruse, again, makes another very interesting observation: "When adding seasoning, it is necessary to determine one’s own flavor. Even if you were to conduct a survey and ask customers what kinds of flavor they want, you wouldn’t find the answer there. Rather, there are two possible questions that you could ask customers. Does it taste good or bad? Or, do you want to eat it again or not? This is because customers are not professionals, and if you increase or decrease the salt according to customer requests, the flavor will gradually become peculiar. There is no sense in seeking a middle of the road taste that practically no-one would dislike." This is interesting because many software processes feel that continuous customer input is the only way to arrive at a quality product. This is very interesting. I have studied the development of the iPod and found that the product was kept secret and did not use continuous customer involvement. Are there lessons here? Can a software process be developed that will produce software that has qualities that appeal to users, such quality that the user will spend their money to own the product? It is arguable that all software processes try to lay some claim in that area. 

Naruse states in the interview, "At one point, there was an attempt to quantify my know-how and create a manual. In the end, however, it didn’t turn out well. This is because know-how is not the same as knowledge. Results such as 'in this type of situation, I used this kind of countermeasure' are no more than solutions for specific problems. What is important is asking how the solution was reached, or why something was done the way it was. This is what we call technique or craftsmanship. Craftsmanship is not handed down through education. Things that are learnt from others passively will never be useful. What is necessary is 'nurturing.' In other words, you will not learn unless you feel that you must do something and want to do something and have the desire to learn and to take from others. Craftsmanship is handed down in implicit knowledge." 

This too is very interesting when considering software processes, the teaching of a particular software process, and the expectation of a particular quality result from the process. Is your method of instructing developers on how to write quality software more like a manual of knowledge or more like a nurturing system of sharing know-how? 

Naruse states that the racetrack creates the flavor of cars. "Races are the best forum for handing down craftsmanship and nurturing human resources. Unexpected things happen all the time and things that must be done out of necessity occur constantly. It is necessary to skillfully and accurately solve problems with limited time and tools. These types of things do not happen within a computer, but happen right before our eyes. It is under these extreme conditions that we focus entirely on winning the race and work as hard as we possibly can. The word “can’t” does not exist at the racetrack. This type of experience builds our character, and builds cars. Both the drivers and engineers focus their five senses to engage in a dialogue with the car under the extreme conditions of the race. It is through this dialogue that the perfect flavor becomes visible" - Naruse. 

Do you develop software at the racetrack or in the shop? Did you notice that dialog is the key? Dialog between professionals, between craftsmen, that bring skill to the situation. The approach is based on "go and see". See it in use. Push it in use. Break it in use. Go and see, don't imagine it, don't talk about it, don't have meetings to talk about it, but go and see. 

Finally there has to be someone that is responsible for the "flavor" of the software. Until that one person gives the okay the software cannot be sold. This statement might not be readily accepted or understood by most. Some might quickly argue that Naruse is Japanese and "they" are different. Maybe Japanese are different from Americans, and Americans are different from Europeans, and maybe they are not. I feel that we are more alike than different. At least those of us that have come to recognize the difference between a worker and a craftsman, a stone cutter versus a cathedral builder. There can be democracy in a software development team. The freedom to fine-tune your work area, your work process, and the things for which you have responsibility. But ultimately the flavor being expressed will be that of one chef. If you are a cook but want to act like a chef you might become frustrated. If you want to be a chef then be one. Do not complain if you are a cook and treated as one. 

The software that many work on will have no particular taste, and will require no particular seasoning. But for those lucky developers that work on software that is valued and sought after, that brings some modicum of satisfaction to the user, those developers should be aware of the need for "flavor" and work together like the racing team through dialog to hand down craftsmanship and through "going" and "seeing" that the correct flavor will be made manifest.