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!

Iterative Deployment or Big-Bang?

Let’s say your CEO asks for input: “Should an up-coming software development project use an iterative development process?” (Let’s take the question as assuming an alternative of deploying the software product all at once.)

Iterative development means that the software development team team delivers the product functions in a series of small efforts adding up to the whole rather than as a single effort. It can mean (but doesn’t have to) that the end customer sees several deployments.

The Agile answer is clear; the pre-Agile answer may surprise some Agilists. Let’s do pre-Agile first.

Capers Jones released a highly respected book on software cost estimating in 1998; he released a second edition as Estimating Software Costs: Bringing Realism to Estimating (ISBN 978-0-07-148300-1) in 2007. His book (p 479) says that systems and commercial software requirement tend to change at an average rate of “about 2 percent per month from the end of initial requirements until start of testing.” It further says to expect “12 percent for Agile projects”. My experience cannot support contradicting this book.

Maybe that rate of change results from those specifying requirements learning more about the environment in which they’ll use the tool. Maybe that’s a change rate in business. Maybe it measures the amount humans tend to change their minds. Whatever it is, it seems to happen in lots of projects (maybe some of yours!)

Two percent a month doesn’t sound like much, right? Even using processes that ask the user to commit to no further requirements change after establishing a requirements baseline, the development organization ought to be able to be that flexible, right?

How long is your pre-Agile project? Let’s say it is a year, with three months at the start for requirements and two months at the end for testing and deployment. Dr. Jones’ book is telling us that on average, 14 percent of requirements will change in the seven months between the end of requirements and start of testing. And that for an 18-month project, 26 percent of requirements will change. By any chance, do you feel like shortening the project yet? Maybe it makes sense to do a small project with only part of the product function; maybe a six month project or even shorter?

That argument has been around for quite a while. Companies that scheduled projects for long durations didn’t hear it or didn’t find it persuasive.

If the CEO asks me that question, I’d suggest starting with a short project. And since nothing in that logic depended on the current process in use (Agile or otherwise), I’d almost always suggest that. (And it would be easy to say I’d “always” suggest that; it’s just that “always is a very strong word”!) That’s my pre-Agile answer.

The Agile answer: Oh! It’s like they saw this coming!

The Agile answer is to start with a “project” the length of one iteration (commonly, two to four weeks). Agile teams ask their users to make no change to user stories in the iteration once the iteration starts. (Geez! That sounds a lot like the pre-Agile request to let the programmers work on unchanging requirements. And … it makes sense in both places, though it sounds easier to implement in Agile!) Holding user stories unchanged for two to four weeks (and then not all user stories; only those in the iteration) seems lots easier to ask of our customers. At the end of the iteration, Agile teams look forward to showing products to their users and to getting feedback “early and often”.

So … what’s the difference in responding to that CEO question now that Agile is growing into so many of our work processes? Maybe in the pre-Agile days, we wouldn’t have felt comfortable proposing so short a project, though we would have suggested something shorter than “all at once”. Maybe Agile is, in this respect, the direction we were heading anyway!

(By the way, Chapter 7 of Dr. Jones’ book covers “Manual Estimating Methods Derived from Agile Projects and New Environments”. He presents data on many processes, including Scrum and Extreme Programming. It’s good reading.)