This isn’t the process you’re looking for

There was a fairly awesome pissing match between “Uncle” Bob Martin and, well, everyone, on Twitter today. Twitter isn’t a great venue for this kind of thing, because it’s hard to read and hard to make a solid point, but basically Bob suggested that you should do everything possible to make sure you have 100% test coverage. He was making the argument that this was the cheaper way to go for the long-term quality and maintainability of code (or at least, that’s what I interpreted it as, in 140 characters or less).

Absolutes annoy me. That’s why I posted this:

What you describe (re: 100%) is akin to being a modern congressman, ignoring the continuum of possibility for one extreme.

The insanity of absolutes is certainly not limited to politics. I see it all of the time with regard to process in software development. It’s a bit of an absolute paradox that there are some absolutes, like death (though Walt Disney and Elvis would tell you differently if you could find them), but they’re very rare.

I like test-driven development. I like test-“influenced” development even better. I tend to find that the more I refactor stuff, the fewer things a class does, the less likely I’ll feel that I need a test. I mean, how often do you end up having a method that ends up looking like this?

public void Foo(int id) {
   _someRepository.Foo(id);
}

I’m not going to write a test for that! OK, truthfully, I have written tests for that, but I don’t even like to own up to it. Every other method in the class may act on some piece of data, and you’ll end up with a method that just calls on one of its dependencies. But there are a lot of cases where it just doesn’t seem like writing a test adds value. There’s a point where there is little to no return on investment, and I think a good developer understands where that point is, so they can devote time and energy to a place where there is some ROI.

I like to think about the process of software development, to the extent that I’m always asking how there can be less of it. I instinctively want to fight any time someone says you “must” do it a certain way. I can remember the first time I sat in with consultants from a firm specializing in agile development, while working at a major auto insurer with a spokesperson named “Flo.” I believed in most of what they had to say conceptually, but didn’t care for their insistence that some of our adaptations were wrong. I really thought we were making the process better, and even leaner, without sacrificing our results.

When I was interviewing for my new job, one of the interviewers, a dev lead, asked what the best way was to communicate “specs” to him and his team. It could have been a make-or-break question, because you never know if you’ll work with someone from the old school who insists on pages of documents that no one ever reads. But I still told him what I think: There’s a broad continuum of what the “right” level of detail looks like. Sticky notes and kanban boards are often more than enough to build software. Sometimes, you need very specific information that has to be broadly agreed upon, understood and well documented (think legal text, like copyright notices or a terms of service page). The only rule I make is that there should be as little documentation as possible.

It all seems like common sense, but business has evolved (devolved?) beyond it in some ways. Engaging in the right process for the situation, instead of being dogmatic about what you “must” do is counterproductive. One of the things I learned early on in coaching volleyball to teenage girls was that I couldn’t just push my system on them the same way every time. Different girls and social hierarchies respond to it differently, so I have to adapt it for every team. The same can be said for development methodologies.

Adapt your processes. Use only what you need. Avoid declaring absolutes.