Monday, December 5, 2011

Reducing Extract Method on a Reduce Loop

Let's say you have code like this, wherein totalYs is being used for multiple purposes, including accumulate the Y values within the collection of Xs.


int totalYs = ...;
Collection<X> xs = ...;
... something that uses totalYs ...

for (X x : xs ) {
    totalYs += x.getY();

}
...
process(totalYs);


You can start isolating the Y accumulation (to extract to a method) by introducing a temporary variable.



int totalYs = ...; 

Collection<X> xs = ...;
...

int tmpTotalYs = 0;
for (X x : xs ) {
    totalYs += x.getY();

}
totalYs += tmpTotalYs;
...
process(totalYs);



Then, replace all instances of totalYs within the loop:




int totalYs = ...;
Collection<X> xs = ...;
...

int tmpTotalYs = 0;
for (X x : xs ) {
    tmpTotalYs += x.getY();
}

totalYs += tmpTotalYs;
...
process(totalYs);


Finally, you can extract your method easily, and inline the temporary variable:


int totalYs = ...; 

Collection<X> xs = ...;
...

totalYs += collectYs(xs);
...
process(totalYs);


Now, totalYs is much easier to manipulate. The lure of this transformation is that tests will pass at every step.

BTW, this will work for any associative operation with an identity value in place of addition.

Chris

Wednesday, August 10, 2011

Feedback Loops

Remember when you were in school, and your teacher was handing back your homework? You probably got a number or letter near the top of the paper indicating whether were going to have trouble passing the semester. That was feedback.

And as it happens, one of the worst sort of feedback.

Homework grades suffer from several serious problems: they are fed back to you far too late in the learning process, and they are discouraging when they should be informational.

However, homework grades are a perfect example of one good trait of feedback: they are highly visible.

Feedback is an integral part of a feedback loop, which is any iterative process wherein feedback from one part of the process to alter another part of the process. We use feedback loops to learn in school, such as with homework or test grades. We use feedback loops to learn to play games and music. We use feedback loops to improve at everything we do.

Well, almost everything. When was the last time you evaluated your job performance? That happens once or twice per year, right? And did your job performance improve as a result? Probably not measurably. Oddly, the place we spend most of our waking time is the place we use the fewest feedback loops.

I'm guessing that you or your boss or someone fairly high in your organization's hierarchy wants to increase the ratio of your output value to your output costs. And probably not just once. Improving performance consistently is only possible by learning from the past. And feedback loops are integral to learning.

Agile and lean methodologies evangelize short iterations of production interspersed with customer demos and team retrospection. Notice that this is a simple feedback loop. What's more, this process exhibits some of the best properties of feedback loops: there are natural consequences and the customer responses are simple (if not always pleasant) to consume.

Let's characterize feedback according to whether it is a (non-trivial) metric. A non-metric feedback might be a customer's comments after a demo, or the blinking lights telling everyone that you just broke the build. A metric-based feedback might be a graph of the count of broken builds each day in the last month or a diagram of your bottlenecks in your value stream. Some generalizations may be made about these two classes. A non-metric feedback is generally more useful the closer it is to the behavior it is meant to adjust. A metric-based feedback is often used to detect trends, and thus is more useful for longer-term behavior adjustments.

Other generalizations may be made about feedback in general. It should be relatively simple. It should be highly visible. Feedback is most potent when it takes the form of natural consequences. However, feedback which triggers negative emotions will almost always have several undesired effects. You can create (intentionally or accidentally) a virtuous cycle or a vicious cycle depending on the representation of your feedback. A broken build light will motivate a fix. A broken build stick will motivate not checking in, which is worse than a broken build.

Feedback loops are much easier to maintain whenthe feedback is collected or generated automatically. For metric-based feedback, this usually means having an automated process which regularly processes the relevant data. For non-metric feedback, this means that the process must explicitly capture the data. In the case of gathering customer comments, this may require setting the expectation early in the relationship that every iteration the customer must look at the product and tell you what they think.

The reason we use feedback loops is to measure performance of our systems over time. Metrics-based feedback are used primarily for this purpose. But, why do we care to measure the performance of our systems? To combat overconfidence. Unwarranted confidence damages the ability for people to make decisions, which in turn destroys their ability to deliver. And delivery is what Agile and Lean are all about.