If you want to learn Craftsmanship, you would be hard pressed to find a better mentor than Rino Baglio, the Executive Master Chef at Pazzaluna, in St. Paul, Minnesota. I had a chance to catch up with Rino this past weekend when I was in Minneapolis to teach a tutorial on Aspect-Oriented Design at ICSE 2007.

There was an accident earlier this week. Apparently a number of blog comments were deleted in a frenzy of spam-combatting deletions. Your clever and useful feedback was a casualty in the spam wars.

Rather than turn off all comments, we are going to work on ways to better combat the blasts of blog spam we’re getting these days.

I just though you might want to know it wasn’t censorship, and it wasn’t personal.

There is an odd idea that learning is compressible, that any training course of any length can be squeezed into a very small time box and delivered to any large number of people without significant loss.

I’ve been reading up on some of the newer aspects of SOA, and came across BPEL. It’s another language you are supposed to write in XML. Get ready for a rant.

Should you strive for 100% code coverage from your unit tests? It’s probably not mandatory and if your goal is 100% coverage, you’ll focus on that goal and not focus on writing the best tests for the behavior of your code.

That said, here are some thoughts on why I still like to get close to 100%.

Good process is like Tabasco; A little goes a long way, and when it’s right, you hardly know it’s there.

Legacy systems suffer as much from Requirements Debt as design debt. People tend to not want to lose anything so “new” code meant to replace old code has the same stuff that nobody understands. Why? Because pack rats don’t want to lose anything.

In TDD a unit test has to be very small to isolate failures. This does funny things to code coverage as a metric. Each test should have a very small area of effect, and so each unit test should have a negligible effect on the overall code coverage statistic. Bear with me here, see where I’m missing out.

I’m playing with ways to make CPPUNIT and VIM a bit more agile for my C++ teams.

I’ve been hearing about great lengths people go to, flipping back and forth between .h and cpp for the tests or writing perl scripts to coalesce them together. I’m too simple-minded for that. I figure nobody wants to #include my tests, so I don’t need a .h. I do it all in the .cpp file, all inline. It works fine. This way, everything is in one place. I don’t have to jump up to the header file to add a protoype and then down to the implementation to add the CPPUNIT_TEST line, and then back down to my code to enter it. I have no .h, so no prototype. Inline makes it a bit more like pyunit or junit.

I have a fresh idea. When someone is supposed to change their workstyle to do TDD, and they say “we can’t do that”, how about we assume they’re telling the truth.

The first word is “we”. It may well be that the speaker and the people he represents might not be able to do the work. They’re not saying that it can’t be done. They’re only saying that they can’t do it.

The next word is “can’t” and that’s an interesting word, too. It might mean that they lack the ability or knowledge. That’s ideal, because such things can be taught and can be led. The other sense is that they are not allowed. If it’s like that, then there is going to be some political work going on. But at least you know what you’re getting into.

The other tell is the word “that”. Maybe they should describe what it is that they can’t do, and you can tell if the thing they can’t do is the same thing that you are wanting them to do. Sometimes it is not.