The Lack of Difference Between "What" and "How"

I’m just jotting down my thoughts in response to a conversation at work yesterday.  I’ve realized now that there is a whole category of programmers out there that see a very stark black-and-white distinction between two things:

• What my code does
• How my code works

I don’t see that distinction at all.  It’s fascinating to me to suddenly realize that many people filter their entire view of programming through lenses that separate those two nearly identical concepts into opposite sides of an impermeable divide.  It leads me to suddenly understand some of the nagging issues that live in the back of my head, such as:

1. How can anyone work toward patents on software without it keeping them up at night riddled with guilt?
2. How can anyone disagree that software running on vote-counting machines for government elections should be released into the public domain?
3. Why are so many people so worried about whether their code passes tests, but not with whether their tests are testing the right things?

Reading articles from Reddit today, I came across James Golick’s statement:

When you explore in your implementation code, you’re trying to answer two questions at once: “What should my code do?” and “What’s the best way to implement my code’s functionality?”

And there’s the same thing again.

I’m not saying one way or the other of thinking about programming is “right”.  I’ll be the first to admit that there exists infinitely many ways of writing programs to compute the same function.  I just doubt whether it’s ever really possible to have a right answer to “what should my code do?” independent of the related question “how should it do that?”  Except for small finite sets of possible input, I just don’t think we generally have the language for it.

Revisiting "X Improves My Design"

I seem to have upset a few people.  Let me clarify a few points about the last article I wrote:

• I don’t think unit testing or test-driven development is a bad idea.  I’ve done it for some time.  I’ve argued for it.  I’ve invited Mark Clark to speak at user groups to promote TDD.  If this post is read as a hit piece on the idea of test-driven development, that’s not how it was intended.  I’m not the right person to write such a hit piece, because I think TDD is a good idea.
• Nothing in the article was intended to attack or insult Tim Ottinger.  It was meant to point out something we all do, and that I think we need to be made aware of.  I do it with functional programming and static typing.  Others do it with OO design, or certain kinds of version control, or whatever.  Tim wrote a good article, and I used it as a springboard to make a slightly related point.  I do apologize to Tim if my comments were upsetting at all.
• I don’t actually believe that doing test-driven development requires completely giving up private variables.  I don’t think it necessarily means adding Java EE style abstract factories for all classes in the program.  I was pointing out, more than anything else, that we should just remain aware that these techniques have disadvantages.

The main thing to bring away is there there are very few techniques in programming that don’t make some things hard or awkward.  Denying that fact is dishonest, and does nothing to help the advocacy of a technique.  Acknowledging it brings us back to real people balancing real and often conflicting concerns in the context of their various projects.  This is the essence of software development, and it’s directly opposed to the human tendency to pick a side and defend it against all comers.

I remain convinced that test-driven development will lead to some design compromises in other areas.  I’ve seen it in my projects, and I think Tim’s experience basically says the same thing.  I still think it’s best that we describe these compromises as what they are.  It’s important to resist silver-bullet-ism in a field that’s already gone too far down that path.