I want the JetBrains and Eclipse people to automate The Saff Squeeze

Imagine that you have a Feathers Characterization test that fails. You click on the test and then select Tools->Saff Squeeze. The IDE then goes through an iteration of inlining the functions in the test and Jester-ing out any code that doesn’t change the result of the assertion.

I think that by using internal code coverage monitoring to see the paths being taken, and by intelligent monte-carlo modification, you could automatically reduce the code down to the minimum needed to maintain the defect.

How cool would that be?

A month ago I was deep in the throes of shipping the current release of FitNesse. I just wanted to get it done. I was close to delivery when I spotted a subtle flaw. To fix this flaw I decided to insert identical if statements into each of 9 implementations of an abstract function.

My green wrist band was glowing a nasty shade of puke. I knew I was duplicating code. I knew that I should use the Template Method pattern. But that just seemed too hard. I was convinced that it would be faster to spew the duplicated code out into the derivatives, get the release done, and then clean it up later.

So this morning I was doing something else, and I spotted this duplicated code. I sighed, as I looked down at my green wrist band, and thought to myself that I’d better eat my own dog food and clean this mess up before it gets any worse. I was dreading it.

I made sure that every occurrence of the statement was identical. Then I went to the base class with the intention of refactoring a Template Method. When, what to my wondering eyes should appear, but a Template Method that was already there.

I sheepishly copied and pasted the if statement from one of the derivatives into the Template Method, and then deleted the other eight instances.

I ran the tests.

They all passed.

Damn.

My green wrist band is shouting: “I TOLD YOU SO!”

For my penance I did 20 recitations of Marick’s law. “When it comes to code it never pays to rush.”

I really like the concept of BDD (Behavior Driven Development). I think Dan North is brilliant, and had done us all a great service by presenting the concept.

OK, you can “feel” the “but” coming, can’t you?

Confreaks has started posting the videos from RubyConf. Here’s mine on Better Ruby through Functional Programming.

Please ignore the occasional Ruby (and Scala) bugs…

The week after next, I’ll be visiting Russia to do some training and some University lectures.

The lectures will be at Ural State University, Ekaterinburg. Each starts at 18:30:

Monday, Dec 8th Recovering a Code Base

Wednesday, Dec 10th Error Handling as a First Class Consideration in Design

Thursday, Dec 11th Design Sense – Reaching Consensus on Excellence

I’ll also be speaking to the Agile Russia group in Moscow Friday, Dec 12th.

The internet tells me it might be colder than Miami. I will probably bring a jacket.

This video describes how to use the comparison operators in SLIM.

This is a video overview of the new SLIM test system in the latest release of FitNesse

So we’ve finally found the answer. We know who’s to blame. It’s SCRUM! SCRUM is the reason that the agile movement is failing. SCRUM is the reason that agile teams are making a mess. SCRUM is the root cause behind all the problems and disasters. SCRUM is the cause of the “Decline and Fall of Agile.”

When you’re working in a batch of legacy C code, it’s often hard to build and test just a part of it. You may want to build some set of functions, but then you discover that they call other functions, and those functions call yet other functions. When link dependencies are very bad, you may discover that you’re linking in the entire system.

Fortunately, there is a way out of this. Pick a set of files that appear to be a “component” and attempt to build them into an executable along with a simple main function.

You will get link errors.

Create a file called <componentname>_stubs.c and then go through each of the link errors. Look up the full declaration of the variable or function the error describes. Create a stub for each of them in the stub file.

Here’s an example of a function stub:

int irc_send_ppr(struct ppr *pprn, int nSize)
{
}

The only problem with this is that you have to place something in the stub function. For functions which return values you need to, at the very least, provide a return value. But what should it be?

int irc_send_ppr(struct ppr *pprn, int nSize)
{
  /* is negative -1 okay?   If it isn’t, how will we know? */
  return -1;
}

There is alternative ++:

int irc_send_ppr(struct ppr *pprn, int nSize)
{
  assert(!”irc_send_ppr boom!!”);
}

This is an exploding link stub. When you have it in place, you will know when a function you’re testing calls a stub. When you see the boom you go to the code and replace the assert with a better stub implementation.

When you use link stubs, you have to be able to build your component two different ways. Production builds link to the rest of the code. Test builds link to the stubs and a testing main. There’s no need to stub out all of the external functions that a component uses. Many low level functions can remain direct calls, but stubbing out calls to other high level components can give you a decent amount of leverage as you try to get an area under test.

Fortunately, for any given component you only have to go through the massive grunt work once. Once you do, you can reap the reward of easier testing in that component forever.

++ Note: If you are using C99, you can genericize this code by using the __func__ predefined macro. In any function, __func__ expands to the name of the enclosing function.

I’m speaking this Friday at RubyConf on Better Ruby Through Functional Programming. I’ll introduce long-overlooked ideas from FP, why they are important for Ruby programmers, and how to use them in Ruby.

In two weeks, I’m speaking on Wednesday, 11/19 at QCon San Francisco on Radical Simplification Through Polyglot and Poly-paradigm Programming. The idea of this talk is that combining the right languages and modularity paradigms (i.e., objects, functions, aspects) can simplify your code base and reduce the amount of code you have to write and manage, providing numerous benefits.

Back in Chicago, I’m speaking at the Polyglot Programmer’s meeting on The Seductions of Scala, 11/13. It’s an intro to the Scala language, which could become the language of choice for the JVM. I’m repeating this talk at the Chicago Java User’s Group on 12/16. I’m co-writing a book on Scala with Alex Payne. O’Reilly will be the publisher.

Incidently, Bob Martin is also speaking in Chicago on 11/13 at the APLN Chicago meeting on Software Professionalism.