Agile Otter Blog

The Background I (re)tell a story frequently about a place I worked in the 90s. There was a piece of code with an absurd cyclomatic complexity score, running literally hundreds of lines in length, and being called from myriad places in the code base. The code was written to check to see if two ranges were overlapping. Being written in a poor 4GL, it took four parameters representing the starting and stopping dates of two time ranges. Such a simple task for the code to be so horrible and lengthy. In C it would look rather like this: bool ranges_are_overlapping(int a, int b, int c, int d){ } It quickly became clear to the most casual reader that the ranges were a..b and c..d. Well, sort of. The code was defensive and was written with the understanding that the range-defining arguments could be somewhat unordered: if ( (a<b) && (c<d) ) { // blah blah } else if ( (a==b) && (c<d) ){ // blah blah } else if ( (a>b) && (c<d) ){ ...

(kudos to Cory Haines who, I think, owns the image).

I was reading Uncle Bob's latest blog this morning about messy code and technical debt . I wanted to make a comment about the problems programming shops face, but decided to do it here instead. The problem with clean code is twofold: 1) people who can't see it don't believe in it 2) some people who should be able to see it don't believe in it People who can't see it don't believe in it. One of the heartbreaking lessons from the Big Ball Of Mud talk on Wednesday at Agile2009 is that people working two levels of management above your head do not know that the code is messy. Joe and Brian popped up a slide of Mike Rowe , and quipped that you can't bring him out to wade in the muck in a way that non-programmers can understand. Oh, the code is stinky and messy and bad, but only you can see it. If you can't see the difference between clean and ugly code, it all sounds like a "programmer myth". It seems daft to take time for refactoring. After all,...

This is an article about writing articles. I get to relearn lessons from time to time. An example is the discussion that went on behind the scenes while producing the Stop The Bad Test Death Spiral card at Agile In A Flash . I saw Ben and Phil speak at Agile2009, partly because I know Ben and expect him to someday have a large impact on the world of software development, based on his intellect and personality. Ben and I were coworkers briefly at Object Mentor, and I got to work with him a very little. I don't know Phil, but enjoyed meeting him. They are at Improving Works now, the commercial entity behind Infinitest (a Continual Testing tool). I asked if I could borrow the death spiral steps for an InAFlash card, and they graciously agreed. I produced the card and my spin on the points and turned it over to my partner Jeff Langr for review. Jeff pointed out that it was interesting enough, and true enough, but as an extract from the context of the talk it is not particularly he...

It’s worth noting that some observers incorrectly believe that faulty software causes most IT failures. That perspective is wrong and misinformed See the rest of the content at Six Dirty Tricks at ZDNet. The context is in dirty tricks pulled by vendors that cause software engagements to fail (perhaps in a profitable way). I recommend that one reads these tricks defensively, not as a tutorial on making money on other people's dissatisfaction.

If your test has a trainwreck in it, DO NOT start building the object chain in your setup so that the trainwreck will execute in your test. That will take forever, and the payoff is next to zilch. Instead, extract the trainwreck expression to a private virtual method you can override: public void Blah() { doSomething(ClassName.GetInstanceName().GetInstanceVariable().GetAttribute()); } becomes: public void Blah() { doSomething(GetAttribute()); } protected virtual string GetAttribute() { return ClassName.GetInstanceName().GetInstanceVariable().GetAttribute(); } It allows you to override "GetAttribute" in your tests, with something as simple as : protected override string GetAttribute{ return "okay"; } Astute readers will realize that this is the Law of Demeter at work. Advanced students may note that the public method is in the wrong class now. It doesn't use any local methods or variables, indicating very low cohesion. Time to p...

A friend of mine told me that his company is doing an agile project for integrating some systems. They've already had a few deployments, and their bug count is below 1/10th the expected level. Ahhh. That's how it's done.

An expert knows three things of great value: 1) What all the mistakes look like. 2) That they are mistakes. 3) That you don't have to make them.