Proof Of The Pudding Is In The Eating

There is an interesting conversation on between Phil Haack and Frans Bouma, about testing and proving code correctness.

Is it good to test your software? Of course! Does it prove your code works right? Not necessarily. Then why do we test? Because it helps us move beyond a point while writing software. We write the tests for ourselves, to make sure we have reached a point where we can move ahead and start with other parts. There is one more very important thing that testing does. It catches those missing constraints that had slipped through till now.

Can we anything to prove correctness of code? Perhaps, but by the time we end up doing that the environment around the software would have changed enough to make that correctness invalid. But it will be wrong to say that we do not try to derive correctness of the code from testing, even if partially. And that correctness, like the testing, is for ourselves, not for others. It is clinical and we can go only to the point of technical specifications, which the end user will give a damn about.

I am more inline with what Reginald Braithwaite wrote.

I am not saying that provability or strong typing, or TDD or BDD or anything else is necessarily better or worse in this respect. I am just pointing out that the surface, buzzwords for these things—fewer bugs, provability, test coverage, serparation of concerns—are not the goal, they are ways and means of achieving the goal, which is the discovery of the true requirements and the delivery of working software which meets the true requirements over the project’s complete span.

If we ever want to prove anything about the software, it is its value to the user. Proof of the pudding is in the eating. And yes, that is terribly difficult to prove or even measure, because along with the software it depends on the user, its usage and the context. But that is the only thing that will matter and will be the best indication if your code is correct and if the tests are successful. All our efforts of finding requirements, transforming into specifications, design, testing, writing code and those thousands of meetings lead to that one thing – the value.

Does this mean that the best practices in software engineering are irrelevant? No, but they prove, whatever they do, only to us, not others. We, the software writers, use all these techniques to satisfy ourselves that we are still in the right direction. The tests and correctness of code help us to plan the development, execute it and produce those numbers that the finance division needs. And I can imagine that just like many other things they will be specific to the work at hand. But we need to slap ourselves and remind ourselves hundred times a day, that it is for ourselves and not for the end user.

Discussion [Participate or Link]

  1. Changes Are Expensive, Damn Expensive | iface thoughts said:

    [...] check that there are no unexpected effects of the changes is through tests. Tests will not tell us whether our code is right or not, but they will help us gain sufficient confidence and experience that a user might have after the [...]

Say your thought!

If you want to use HTML you can use these tags: <a>, <em>, <strong>, <abbr>, <code>, <blockquote>. Closing the tags will be appreciated as this site uses valid XHTML.



Abhijit Nadgouda
iface Consulting
+91 9819820312
My bookmarks


This is the weblog of Abhijit Nadgouda where he writes down his thoughts on software development and related topics. You are invited to subscribe to the feed to stay updated or check out more subscription options. Or you can choose to browse by one of the topics.