
Notes on “A Philosophy of Software Design” - r4um
https://lethain.com//notes-philosophy-software-design/
======
DonaldFisk
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](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.

~~~
falcolas
> 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.

------
antirez
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.

~~~
flr03
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.

------
lixtra
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.

~~~
dvfjsdhgfv
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.

~~~
chosenbreed
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...

~~~
TeMPOraL
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.

------
planetmcd
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.

------
_pmf_
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.

~~~
jspash
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.)

------
SCdF
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](https://twitter.com/JohnOusterhout/status/989581205799452672)

~~~
criddell
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.

~~~
TeMPOraL
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.

------
yumaikas
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.

------
thra018
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...](https://www.reddit.com/r/Entrepreneur/comments/9ay8fq/design_helps_software_companies_grow/)

~~~
ofrzeta
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 :)

~~~
meheleventyone
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.

~~~
mannykannot
'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.

------
hodgesrm
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.

------
huntie
The author gave a talk on this book at Google recently:
[https://www.youtube.com/watch?v=bmSAYlu0NcY](https://www.youtube.com/watch?v=bmSAYlu0NcY)

