Hacker News Reader

Comment by _wp_ | Hacker News Reader

I bought this book off the back of the referenced discussion trashing Clean Code. Whilst Clean Code has its problems, well articulated in that previous discussion, I am loathe to recommend this book. A large part of it is dedicated to commenting practices and seems a bit out of touch with the way software is developed today. There were some rather dubious claims on TDD as well, suggesting that it aims to 'get features working, rather than finding the best design' which seems to completely ignore the refactoring phase practised in a TDD cycle. A choice quote about comments that I strongly disagreed with: "without comments, you cannot hide complexity". The book also strongly advocates for large classes and considers small ones an anti-pattern called 'classitis'.

I'd say half the book contained good advice, the other half was mediocre or dubious at best.

I'm curious to hear what others think who've read both books.

View on HN

I’ve read both books. I consider Ousterhout’s to be one of the better recent books on software development, though as mentioned in my other comment, this is more because of the earlier content than the later chapters. I have been critical of Clean Code since before it was cool and I actively recommend against junior developers reading it.

I would have liked to see Ousterhout make a more thorough argument if he was going to criticise TDD. His central criticism — that TDD results in what he calls tactical programming, prioritising the implementation of specific features over good design — is certainly defensible. However, I think he was too superficial in what he actually wrote on the TDD section, and consequently I don’t think he made a particularly convincing connection with the ideas developed earlier in the book.

I think you’re slightly unfairly misrepresenting his position on large or small classes. He makes a solid case that what he calls deep modules are better for managing complexity than shallow ones. He also identifies a correlation with size because small modules tend to be shallow. That’s not the same as arguing for large classes or against small classes just because of their size, though.

I think you're referring to the part in the book where Ousterhout says he doesn't like to start with a test harness when writing a new abstraction or feature like some advocates of TDD would. I think that was some of the best advice in the book in my opinion.

Instead, Ousterhout recommends designing the interface for the abstraction you're building before you start writing a test harness for it, and I can't agree enough with that statement.

If you write a good interface, testing it will be easy. If testing the interface isn't easy, then you have a bad interface. (This is relative to the complexity of the code invovled, obviously)

I am just in the middle of the book but so far I also have mixed feelings:

+ thoughts on complexity and how constant addition of new features adds to complexity + deep vs. shallow modules but at the same time...

- "..classitis": author criticizes the use of many small classes and functions/methods while I think form my experience SOLID principles are there for a reason- every method/class should have one purpose only.

- which leads me straight to my second point of critique so far: nomenclature. for several ideas exist established names already that are not used in the book.

>-"..classitis": author criticizes the use of many small classes and functions/methods while I think form my experience SOLID principles are there for a reason- every method/class should have one purpose only.

I don't understand how you can be so confident that SOLID means you should have many small classes and functions/methods. The question of when we should carve off a piece of reality (natural or artificial) and call it one thing, or say that it does one thing, is an ancient philosophical question with no single right or easy answer.

The book's design approach suites TDD perfectly. Narrow deep modules allow to freely refactor internals and keep tests green.

I didn't say that the book's approach contradicted TDD, I'm merely quoting from the book and refuting one its claims (that TDD doesn't lead to good design). I agree that narrow and deep modules support refactoring internals if their unit tests are written to treat them as black boxes.

TDD in classical form (understood by most devs) aka "one test per function/method" leads to poor design indeed. There is a little training about why this approach couples code with tests and what to do instead.

Yes, that would make for both terrible design and terrible tests.

I think sometimes people refuse to go past the words naming a practice or past the tldr; and it causes problems.

Reply on news.ycombinator.com