This post originated from an RSS feed registered with Scala Buzz
by Daniel Sobral.
Original Post: Bugs, TDD and Functional Programming
Feed Title: Algorithmically challenged
Feed URL: http://dcsobral.blogspot.com/feeds/posts/default
Feed Description: Random thoughts of an IT worker in the stone age of computer science.
I'm watching a BBC series produced long ago called "The Machine That Changed The World". At some point, Mitch Kapor (founder of Lotus) says, as the narrator compares building software to building airplanes, buildings and bridges:
So if you've got something that's not holding its weight well, you look to see if the the joint is tight, or if the screws are right. You don't have to go and analyze the whole building. Well, software doesn't work like that. If you see a problem when you attempt to execute a certain command, there is no simple and direct way of knowing which part of the code could have the problem. In some sense it could be almost anywhere. And so the detective problem of hunting down the source of the problem is enormously harder than in physical media because the digital media don't obey the same simplifying law of proximity of cause and effect.
I see both TDD and functional programming as ways to change that.
For TDD, it's quite obvious, and, in fact, one of the benefits lauded by proponents of the practice. If some bug shows up (in the test), then it must be related to the change you just made. Since changes are supposed to be small if you do it right, then the code path you must follow to find the bug should be quite restricted.
The same holds for functional programming, with the advantage of applying to bugs that did not show up on the tests. A program in functional programming is supposed to be a composition of functions, and each function should be referentially transparent -- side-effect free, so that it's output relies solely on the input, and pure, so that it always return the same output for a given input. So, once you can reproduce the problem -- one you have an input that causes the bug -- you can go down the functions that handle it and see if they are returning the correct output for the input they are receiving.
Add both together, and software starts looking a lot more like building an airplane or a bridge. In this respect, anyway.
When I left work for the weekend on Friday, I had just started feeding input from another module of the systems we are building, as my own module finally got to the point one could start doing integration tests. There is a bug: some data I expected to be produced isn't showing up.
As it happens, however, the code that looks at that data is functional and was developed using TDD. If it got the input I expected, it would have returned the output I wanted. That means when I arrive at work tomorrow, I'll look at the input being provided, and I know it will not be the same as the input the system was tested with. I'll see what's different, and, knowing that, I'll be able to tell exactly which piece of code should have handled it, and find out why it isn't doing what's supposed to do.
Previous Topic
