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:
- How can anyone work toward patents on software without it keeping them up at night riddled with guilt?
- How can anyone disagree that software running on vote-counting machines for government elections should be released into the public domain?
- 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.
Sententia cdsmithus 
Arguably, “What should my code do?” means “What contract should my code satisfy? What pre- and post-conditions, what invariants?”. That seems generally distinct from implementation to me.
From another point of view, I’ve had project managers hand me PRDs that specified particular algorithms (how) to provide the required functionality (what), and I’ve had to explain that a) that’s not appropriate in a PRD, and b) their algorithm sucks.
Of course there is a difference between ‘what’ and ‘how’. The difference is huge.
Take a simple example of ‘what’: Write a function sqrt such that ‘sqrt(x)*sqrt(x) == x’.
(Ignore numerical problems for the moment.)
It says all about what and nothing about how.
There is a language for expression ‘what’ (at least for functional requirements), namely predicate logic. The fact that it is hardly used is another matter.