Feedback

In many areas of my past study, feedback is considered good; I consider it important to software engineering life-cycles. I’ll give a definition useful for us here. I’ll mention several examples of feedback in modern life and I’ll apply those thoughts to software engineering life-cycles.

Feedback Defined

Let’s use this definition: feedback in a process flow occurs when a process influences a preceding process.

a process flow with two processes and one arrow; the arrow points from "Build Product" to "Sell Product",
Figure 1. A process flow: “Build Product” is a predecessor to and affects “Sell Product”.

That begs for an example and a picture. At high aggregation, we might say a company that produces product has two processes: Build Product and Sell Product. As shown in Figure 1, the Build Product process is a predecessor of and influences the Sell Product process. (That makes sense: In many cases, producing product makes it easier to sell.) Figure 1 does not include feedback; Sell Product does not influence Build Product.

a diagram similar to Figure 1, but adding a second arrow, this one from "Sell Product" to "Build Product" in addition to the one from "Build Product" to "Sell Product"
Figure 2. A process diagram like Figure 1, except that it adds feedback. Each process is a predecessor to and affects the other process.

Figure 2 adds feedback; Sell Product and Build Product each is a predecessor to the other; each both influences and is influenced by the other.

The feedback might support fiscal constraints; the company might stop production when warehouse inventory gets above a threshold.

The feedback might support customer satisfaction; it might report the results of complaints received, reports of satisfaction, or suggestions for future development.

The concept of a feedback loop is closely related. Figure 1 demonstrates a linear process; it has no loops (or cycles). Figure 2 is an example of a feedback loop.

Corporate Governance

I have heard it said that in parts of the 1900’s, American manufacturing had a relatively easy time designing product that would sell well. A manufacturing organization in that position generates the greatest profit by producing as much product as possible at the lowest possible cost. If variation results in extra cost and doesn’t result in extra profit, they cut variation. Wikipedia describes a 1918 environment in which over half of all U.S. cars were Ford Model T’s. Their black paint dried fastest, which reduced cost on the assembly line. Henry Ford wrote in his autobiography about that time, “Any customer can have a car painted any color that he wants so long as it is black”.

Feedback works. Wikipedia goes on to indicate, “By 1926, flagging sales of the Model T finally convinced Henry to make a new model.” The flagging sales were feedback; by 1927 the company produced the Ford Model A.

Steering Response

A three-year-old recently reminded me in several ways about feedback. She was driving a light and slow electric car; I was jogging beside her interested in assuring her safety. (I’ve later wondered whether I was thinking at all when I put her behind that wheel! There are so many warnings I could have heeded at that time! But I did not …) I didn’t want to be “that” adult in her life, constantly controlling her vehicle; my preferred behavior was to let her do all the steering. (Note to self: you silly man!) I soon realized that she didn’t yet understand the concept of steering this car. She understands steering; she drives her tricycle. On the car, though she held the steering wheel correctly, she didn’t exert enough force on it to change the car’s direction. (In her defense, even truckers might not consider this steering system to be responsive!) Her lack of steering inputs was feedback leading me to take the car to a deserted section of parking lot. We did; she had a great time going either in straight lines or in repeating circles depending how I had most recently set the steering wheel. All was well.

I mentioned this was a three-year-old. After perhaps three minutes of this, she wanted to go to the playground then sometimes within her field of view. Her wish to go to the playground was feedback reminding me about three-year-olds’ tendency toward short attention span.

I set the steering wheel to a position I hoped would get her vehicle to the playground. The vehicle turned well past the direction I wanted. The excessive turn was feedback reminding me that driving a vehicle is an active control process. We cannot set the controls once and be done with it; we must repeatedly check results and adjust the controls again. We get close to one side of the lane, turn away from that side, get close to the lane center, and turn the opposite direction to stay close to the center; we repeat that process all the way to our destination. That process depends on receiving feedback that our vehicle is “close” to an edge or center of the lane. That three-year-old either wasn’t receiving the feedback or wasn’t acting on it.

(By the way, controlling an airplane involves double the inputs. We must start the roll, thus changing the angle of the wings make with the horizon; that’s bank angle. Then we must stop the roll and hold the desired bank angle to turn. Just before we get to our desired direction, we must start rolling toward level. When the wings are level, we must stop the roll. Yup. That’s four control inputs compared to a car’s two.)

Feedback in a Software Development Process

The August 1970 original paper on waterfall software development by Winston Royce mentions the importance of feedback. His Figure 3 shows the classic waterfall diagram also with all feedback flows pointing for each phase “uphill” to the prior phase; the caption is, “Hopefully, the iterative interaction between the various phases is confined to successive steps”. His Figure 4 and the accompanying text recognize the likelihood of detecting problems in testing that invalidate program design and, in turn, invalidate software requirements; the caption is, “Unfortunately, for the process illustrated, the design iterations are never confined to the successive steps”. This paper is convincing evidence that we’ve known since the inception of waterfall processes that feedback is useful. And that feedback can be expensive.

The most interesting part of this discussion is deciding how this observation drives today’s software development.

The Agile models answer unanimously: Do a very small part of the project, show it to the customer, get feedback “early and often”, and repeat. Feedback is an important component of the Agile models.

For those of us not using Agile, a useful answer is to divide the project into a series of shorter efforts, each of which completes one development cycle. Perhaps doing more development cycles will make some methodology processes or products excessive; we might find we can streamline those excesses to everyone’s advantage. There is perhaps a reasonable minimum cycle time advised by Agile: one to four weeks; if your organization gets to that point, it has done lots of the change needed to do all of Agile.

This post reviews feedback; feedback is good. We use it in many activities of our lives; in some parts of our lives, we use it without noticing. It is a valuable part of all software development. May we all have and use lots of feedback in our software development!

If We Have a Problem, We’ll Find It. Early is Better. Still.

Let’s consider here a project with a significant problem we haven’t found. If the project’s product is to be a chair, maybe we have cut a leg too short. If the project’s product is software, maybe a function we designed with two parameters actually needs three (or reports answers in units different than a consuming function assumes it reports, maybe miles per hour instead of meters per second). This discussion is not about a misspelled word in a quick and informal email message, for example.

Do we get to choose between finding that problem or not? Well … (he he) … since our discussion is about significant problems, we’ll find it. And as one of the many corollaries to Murphy’s Law says, “If you have a problem, you’ll find that problem at the worst possible time.” (There’s something irresistibly pessimistic about that Law and all its Corollaries!)

You’ll find that problem just after you’ve spent lots of effort with the short chair leg in a lathe, getting sanded, and getting just the right finish (all of which was a waste of effort, of course, but you didn’t know that yet). It’ll happen just after you or your tester tell your executive that your code is 99 percent through testing, that the results look good, that you expect to complete ahead of schedule, and that the profits for this product are likely to start early. Or your customer will find the problem. (That would be embarrassing!) You’ll find that problem. It’ll hurt.

Let’s do something about it. And let’s focus now on creating software. Barry Boehm published once or twice (tongue-in-cheek) in a long and continuing software engineering career. In 1981, he wrote Software Engineering Economics, which contains the famous Constructive Cost Model (COCOMO) used for estimating the size and duration of software development efforts. It also contains (page 40) a graph showing the increasing cost to fix a problem introduced in requirements. The chart makes the point that if the problem costs roughly $15 to fix during requirements, it costs something like $50 in design, $100 during construction, $200 during development test, $500 during acceptance test, and $1,800 during operation. Many other sources of similar age make similar arguments and cite other cost studies. Their numbers vary, but let’s agree: cost to fix grows rapidly with time.

One message from those studies is: projects need a strong sense of urgency about finding problems we must fix because of the rapid increases in cost.

Another message is that a key question in managing a project is, “How much is the optimal spending now (in dollars, hours, process, whatever) to detect more problems earlier and get the greatest benefit from the current lower price of fixes?”

Sound good? Well … it certainly sounded good enough to form an orthodoxy in our professions. (Perhaps, anyway. It felt like that!)

From the current perspective, is there a problem?

Well … from today’s perspective, many of us would feel the data collection seems to presume use of the waterfall development model. Fewer projects use a waterfall model today.

And … many in our industry now have experience working projects without spending lots of time in review of past work. Many of us feel that the right answer to the question above is spending no time specifically looking for past problems.

And we achieve great results.

And our stakeholders love the new relationships with us as service providers.

(Well … not every time. New project models aren’t “the silver bullet”. And there are lots of other reasons projects don’t do as well as we want; many still need work.)

I refer, of course, to the development models advising us to strive for market agility (Scrum, Lean, Kanban, and Extreme Programming are commonly-cited examples). I intend to write more about these in future posts. For now, I’ll say: Much of the market has already moved one (or more) of these directions.

And what about the advice derived from the statistics Dr. Boehm cited? I’ll say projects need the same sense of urgency about finding errors; we’ll find problems differently than we most commonly thought about then. Projects using today’s agile models probably expect to discover those errors during their frequent interaction with customers (“early feedback”). And we expect to fix problems during the first iteration in which the customer wants us to fix them. And that advice sounds great … Why would anyone oppose?

And what about Dr. Boehm’s career after writing the book I mentioned? Well, in 1988, he published an often-cited description (info) of his “Spiral Model” of iterative software development. Both his works cited here influenced thought leaders who contributed to other models later collectively called “agile”. He is now an AIAA Fellow, an ACM Fellow, an IEEE Fellow, an INCOSE Fellow, and a member of the National Academy of Engineering.

He is one thought giant on whose shoulders we stand today. May we all learn …

//Later edit: Fixed a broken link.