Thoughts from a Thirsty Bear

Customer feedback. We all know we need it to make sure we are delivering the right thing. But sometimes we all have trouble engaging. The customer might be busy, or disinterested, or both. So here's a little tip that might just help. Like all the best stories, this happened a long time ago in a galaxy far, far away....  We were working on a web front end and associated backend system for a client. But we were suffering from the "disengaged  customer" anti pattern. The customer would not commit to a web front end design, and help us design the look and feel needed for the application. We provided a few options over a couple of iterations to try and start the design conversation, but none connected despite our efforts. So we threw in a " smelly sock ". Something so stinky it guaranteed to get folks going " Ewwww! Get that out of here!". I seem to remember we disabled all CSS formatting.... Sure enough, we got a reaction during the regular show-and-tell s

Following a fairly public spat and veiled threats over trademarks by Oracle, the Hudson CI server has been renamed to Jenkins . OK, technically Jenkins is a branch of the Hudson code, so it's more like Hudkins or Jenson . Oracle (sorry, " the Java community ") will continue to develop the Hudson trunk, however the branch appears to have the blessing of the core Hudson Jenkins development team and the community (the vote to fork appears to have been virtually unanimous ). If it looks like a duck & quacks like a duck....then the parent might just start resembling a dodo . I'd like to wish the Jenkins team good luck. I've used Hudson to great effect many times, and look forward to the future improvements with the new project butler.

Something is happening in the Test First world. There appears to be growing use of " Behavioural Driven Design " (BDD). That is, the test names in test classes are becoming sentences describing what the class should do, eg testFailsForDuplicateCustomers() . In my opinion this trend is damaging the effectiveness of Test First Design in the field. Don't get me wrong - I think the fundamental idea behind BDD is sound. But I am finding that this kind of naming approach for unit tests is seriously detracting from the "code is the documentation" ideal. If you have a class with method " X ", you should expect a test method " testX " that defines the method's contract. If the method's contract is more complex, you might expect to see a set of methods like " testX_NullInput " etc. This approach documents the class pretty damned well in my experience. Now image the same class being tested by something like " testFailsIfC

In my role as a software developer I have come across many strange attitudes to coding, but none so strange as the fear of changing code. A good example - I was working with a team trying to use XP techniques. I was hired as a XP developer to strengthen the team and get them over a busy patch - not as coach, but simply as someone who had developed Java code in an extreme agile environment. No problem there. The product we were working on required new functionality added to it. Since the current software structure did not easily accommodate the new stuff I mentioned in the stand-up that I would be restructuring the internals to make it fit more elegantly. This kind of refactoring is normal practice in any agile team, and is necessary to evolve the design with emerging requirements, keeping it coherent and stopping it from descending into a meaningless Ball Of Mud antipattern. I thought nothing of it. But one of the senior engineers threw his hands up in horror at the thought. "Yo