- Tags:: 🗣️Talks, Coding best practices, TDD
- Author:: David Heinemeier Hansson
- Link:: RailsConf 2014 - Keynote: Writing Software by David Heinemeier Hansson - YouTube
- Source date:: 2014-05-04
- Finished date:: 2021-01-16
Success is clarity, as in writing
The key idea of the talk is that software engineering or computer science are not metaphors that he liked in creating information systems There are no absolute truths that you can apply systematically (such as the law of Demeter). There are no miracle diets such as TDD (00:23) that would make your software more successful. Success in software does not come from coverage, test ratio or speed of tests.
Instead, for him, creating information systems is akin to writing. Coding is writing (47:06). We are software writers: success comes from clarity.
I see this very related to the various articles saying that the most important productivity factor for a software engineer is familiarity with a codebase:
- The most important factor for developer productivity is codebase knowlege. And the way to get that knowledge is… to code (10x engineers: the Purple Developer – Jessitron)
- Questionable Advice. The Trap of The Premature Senior - Charity.wtf
What you wrote first was a draft! (58:11)
‘People say: “Oh, ActiveRecord is to big”. Who gives a shit? Is it more readable?‘
TDD does not bring clarity
TDD does not make your code look better. Easier to test != easier to understand. So, driving your design from unit tests is not a good idea (33:17).
Splitting up functions destroys your system architecture and code comprehension along with it. Here it makes sense to remember how Mental chunking works. We cannot hold many small chunks on our heads.
Understanding is hard also because of all the indirections (38:47). Ideally, you still test, but at a higher level, and not driving the design with that.
Why then people insist so much on TDD and the likes? The problem is people want badly for it to be science, to be engineering (41:00). People also have made a career out of making people feel shitty about their code (44:52).
This is not a fault of Kent Beck: “I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence” (44:12). Also, Extreme Programming Explained insists a lot in that code should be easy to change.
Because clarity is not science, is not easy to measure. You develop an eye for it by reading and writing a lot of software. And not necessarily good software: Sturgeon´s revelation “Ninety percent of everything is crap”.