Java Case Study 14: Flub-a-dub

As we pursue the architectural refactoring of the application, I make a silly mistake in the diagram on the board. And for two and a half tomatoes we don't spot it. Yikes! This doesn't invalidate the work we do. And much of it is good. But it does create a kind of "friction" that we both feel and can't quite explain. This is a reality show. This kind of thing happens in real life. It's frustrating. It's embarrassing. But it's real. And it's educational. And, of course, there's lot of other things to learn in spite of the flub. We talk about mocking tools. We talk about dynamic vs static languages. We talk about refactoring strategies. We talk about big design vs TDD. And, in the end, we have a lot of fun. Because, after all, programming is the second most fun thing in the world!