Software Development And The False Dilemma

So I started my morning, as I often do, by looking at Twitter. It’s better than a demitasse of espresso in terms of raising my blood pressure.

One thing I see over and over again on Twitter is the rather common false dilemma logical fallacy. And this fallacy seems to be in play a lot in software development.

We Can’t Test All Of It!

This is one of those old saws I’ve heard from multiple developers over multiple years. It goes something like “Well we don’t have time to test thoroughly . . . ” the unstated implication being that if we can’t test “thoroughly” (for whatever definition of thorough that person has in mind) then there’s not much point in testing at all.

This is, of course, a false dilemma. There’s quite a bit of value in testing even 10% of a system because that’s 10% more chance you have of finding bugs before your code gets in to the hands of your customers.

Now testing costs money. It takes time. But that has to be weighed against the loss of time for customers and the loss of trust. I think the loss of trust is an even larger (if much more difficult) cost than the loss of time. Once a customer stops trusting that your software is mostly right, it’s very hard to regain their trust after the fact. The hasty generalization occurs–one crash makes the entire application suspect from there on out.

I Tested And Bugs Still Got By!

This is yet another form of the false dilemma. Developers will, sometimes very grudgingly, write unit tests against their code. Then after several iterations they may find a bug. “Well I guess all those unit tests were useless! They didn’t catch this one bug!” And there’s a great excuse not to do the work of writing unit tests any longer, right?

Of course this is a false dilemma. Unit tests certainly won’t eliminate the possibility of any bugs. For one thing, the code doesn’t stay static after we write our unit tests. For another, it’s human nature to miss details that need to be checked. Neither of these factors mitigate the value of having a good suite of unit tests. If you find bugs after the fact well add another unit test to catch that bug in the future and congratulate yourself on being a tiny bit wiser about potential bugs in your code!

The Comments Lie To You!

Another common false dilemma is the notion that once comments get out of date there’s no point in updating them. “Well,” the reasoning goes, “this one comment is obviously incorrect so I won’t bother to read any of them. And there’s no point in correcting the comment either!”

I guess as I put more miles under my tires, I get more and more to appreciate the developer who rather than leaving garbage does his or her part to spruce up the code. Maybe you can’t fix the entire code base but that doesn’t mean there’s no value to be gained from fixing the part of the code base you’re currently working on.

We Can’t Verify All Of It!

One area I’ve been focusing on lately is the idea of formal verification of software. I’ve been playing with Coq and I have found an excellent tutorial on how to use it to formally proven assertions about code. But this seems to be one of those false dilemmas that developers feed themselves.

“Hey Onorio, you can’t formally verify the correctness of all of your code so why bother with any of it?” And that’s true. For all but the most trivial applications a full formal verification is pretty expensive and time consuming. But that doesn’t mean that there is no case where some formal verification cannot help build stronger software.

Pretend you’re dropped in the middle of landscape you’ve never seen before. You’re offered a map but the map, intentionally, has a lot of details omitted. Would you rather have the incomplete map or nothing? I don’t know about you but I’d consider an incomplete map is still better than absolutely no clue about the landscape.

Of course we can’t formally verify entire large software applications–especially applications that interact with human beings. But that doesn’t mean that we cannot verify parts of the application and have some assurance that some parts of our code are formally, provably correct.

I guess if I wanted you to take anything from this little thought ramble it’s that “I can’t fix everything” is almost never a justification for not trying to fix anything. The single cleanup here and there will eventually add up to a code base that if not perfect is at least a lot more liveable.