Notes on “A Philosophy of Software Design” | Hacker News Reader

Notes on “A Philosophy of Software Design”

lethain.com

124 pointsr4um32 comments

John Ousterhout: "It's more important for a module to have a simple interface than a simple implementation."

Richard P. Gabriel in http://dreamsongs.com/WIB.html : "Simplicity -- the design must be simple, both in implementation and interface. It is more important for the interface to be simple than the implementation."

Ousterhout here is advocating The Right Thing, as opposed to Worse is Better. Unfortunately Worse is Better has become the dominant approach and it will be difficult to change that.

> Unfortunately Worse is Better has become the dominant approach and it will be difficult to change that.

That's because "Worse is Better" provides revenue out of the gate. Design and performance doesn't sell, it just raises costs and causes churn. And so long as your features are bringing in more customers and revenue than you churn, nobody cares.

Yes, it will cause blowback later, when you have a feature-rich product that is unacceptably slow, or new features cost too much to be released on time, but that future may be years away, a timeframe you can't (or aren't allowed to) think about when investors are pushing hard for user and/or revenue growth.

Of course, those years later, it will probably be faster to pivot to a new bit of software written with a "Worse is Better" mindset and start the cycle again.

No, he's advocating simplicity. The problem is that "really does what's needed" beats "simple" every time. And the other problem is that the person designing the module often has an incomplete idea of what's actually needed, which makes it really easy to design something that is simple but incomplete, and therefore more beautiful than useful. I think that much of the war between "worse is better" and "the right thing" is exactly this - worse is better if it actually does what's needed, and "the right thing" that doesn't actually meet the user's needs isn't actually the right thing.

So, absolutely, work for simple interfaces. Absolutely, try to do the right thing rather than just creating a ball of mud. But the real world is a messy place, and your code needs to handle some of that mess in order to actually be useful rather than merely an entry in the museum of beautiful design.

I want to politely disagree with the comments here telling that this book should be categorized as a "undergrads book". This is a way to neutralize the content of the book for a broader audience, that is, we are doing everything wrong in most software development environments.

Moreover the author commits a big mistake in saying that Google is a good example of clean software design. Talk with people inside the company to get a real picture, it's full of monsters that you have to maintain just with "tactical programming". This book is very well applicable inside Google as well.

I totally agree with your point. Categorizing the book as undergrads book is really trying to minimize the importance of the message. Those recommendations does apply to everyone, thinking that it could be only useful for junior or undergrads is almost admitting that you don't really have to care, hence you are probably not trying to follow this philosophy. As a senior, I've been trying to apply and you have to be humble and question your choices all the time. One of the problem is the culture of complexity among developers, seniors not being an exception.

I saw some reviews that claim the books just presents common knowledge. Keep in mind it is aimed at undergrads.

I personally think the author is to harsh on "tactical programming" (solving problems locally without the big picture in mind). I agree with someones note on HN that tactical programming is fine till you get a product market fit. Technical debt has not to be paid back if the product fails.

I try to design strategically for overall architecture and don't care for most of the rest (in worst case you can refactor later).

If 9 out of 10 startups fail you can have huge savings. If you have enough success that it matters then you have the resources to improve.

I think your comment reflects well the mindset difference between programmers working for startups and the rest of the world. When you're working on a system that's supposed to last for decades, you think in a completely different way.

>When you're working on a system that's supposed to last for decades, you think in a completely different way.

Some of the worst systems I've seen were those designed to "last for decades".

https://en.wikipedia.org/wiki/Second-system_effect

I was thinking about the other end of the spectrum like Voyager probes.

That takes a whole other approach yes.

But that's also not the same as "to last decades". A lot of the old space code was used and dismissed after a few years / missions.

The key difference is not "future-proofing" but "proofing" in general: the code had to be absolutely robust.

https://www.fastcompany.com/28121/they-write-right-stuff

Code written on/for a space probe is certain the 0.01% in terms of safety and robustness required.

Do general purpose line of business programs last for decades though? I suspect that the ones that have lasted have gone through enough iterations to the point of being unrecognizable to original authors...

Even if it lasts for 5 years, that is still a long time to maintain and so the advice in the book is solid. As a business, you may want or need it to last longer.

Not just LoB, also EDA software, specialized industrial and automotive testing / HiL software and general equipment control software where you can never start from clean slate because there's existing hardware in old production lines with a 10 year support contract.

I.e. basically everything non-web/non-mobile has a higher lifetime.

Someone on HN said recently that business software is like another employee. You wouldn't fire a senior with lots of domain experience, on whom critical processes are dependent, just because it's time to freshen things up.

I've not seen this 'common' knowledge in the field enough to call it common.

While there can be a strategic value to just getting something working, the tough part is that many times that is used as a crutch to do no more thinking or design, quite possibly because they've never been called to. And refactors happen less than they ought to. The point is to be strategic about when to turn the quality/speed dial towards speed and know you are consciously taking on tech debt.

This was a fantastic book. It is definitely not for undergrads, or just undergrads. I think it even more important for people actually working on production systems. Even better, it provides some language for people to share when doing code review about how to design their APIs better.

I've found this book to be a nice antidote to the damage done by excessive Uncle Bobbing. I.e. if you give your undergrads "Clean code", also give them this book to prevent them from becoming mechanical DRYers who think good code equals avoiding duplication.

If the only thing you got from "Clean code" is Don't Repeat Yourself then I highly suggest reading it again.

(IIRC the DRY principle comes from "The Pragmatic Programmer" and not "Clean code", but it is referenced and is one of dozens of "clean" concepts.)

Side note: I find it really weird that a book about software design released in this day and age has no plans for an ebook edition[1].

I've had this book on my radar since it came out, but no library near me is going to stock it, and I just don't have the space in my tiny apartment for books unless they are very important to me.

[1] https://twitter.com/JohnOusterhout/status/989581205799452672

Interlibrary loan is fairly cheap, and since this book is so small, the short lending term shouldn't be a problem.

I don't know why Ousterhout doesn't want to release an ebook version, but I do know that some authors refuse because of typography limitations in the mobi and epub formats and popular ebook readers.

On one hand it's annoying to not be able to buy something in the format you want, but on the other, it's nice to see people refuse to compromise on aspects they consider important.

I'd settle for a PDF then. No limitations whatsoever, and trivial to generate from whatever the author's toolchain is.

I suspect the reasons have nothing to do with typography or technology limitations, and are more related to a contract with the publisher.

In Australia I had to pay 50% over RRP because the only vendor is Amazon and .com.au is a mere shell of its American parentage - filled with profiteers reselling at huge margins. :(

I've yet to finish this book yet, but it's definitely not just for undergrads. There is a lot of things in it that seem obvious when stated, but are either good reminders, or genuinely well stated language for a domain.

One example that stands out to me is deep vs shallow classes.

This [1]post on Reddit says something similar and really is true. Most of us engineers tend to neglect design. The fusion of good code and good design can set you up for success (after product market dit obviously)

https://www.reddit.com/r/Entrepreneur/comments/9ay8fq/design...

To a certain extent design is the antithesis to agile. How can you create a good design when you make up new features on the go?

Following the above summary of the book Ousterhout argues for increments implementing abstractions instead of features.

Ordered the book now :)

I don’t think design is the antithesis to agile just that design needs to be an iterative process not just in terms of product features but software architecture.

Jamming new features into an existing architecture whether it fits of not is amazingly common though. In that vein I’d maybe even think about separating product and software increments just to highlight technical debt.

'Agile' has become such an overloaded and qualified term that it is almost meaningless, or even a source of confusion between people for whom it has different implications. If you are asking whether something is or is not agile, you are probably asking the wrong question.

You are right about the frequency of jamming new features into an existing architecture whether it fits of not, but, if the feature makes sense (which is not a given), then a bad fit shows that there is something inadequate about the current architecture. This does not necessarily mean that it is wrong for its current purpose, but regardless of how you got into the situation, you now have a choice: you can redesign the architecture and re-implement the affected parts (aka refactor), or you can create technical debt, and the former has a much greater chance of success if you separate it from anything that changes features.

Thats talking about UI Design, not software design.

I use 'A Philosophy of Software Design' as my goto-list for reviewing pull requests. It has a great set of points that apply across a wide variety of applications.

The author gave a talk on this book at Google recently: https://www.youtube.com/watch?v=bmSAYlu0NcY

Reply on news.ycombinator.com