A Philosophy of Software Design | John Ousterhout | Talks at Google

John Ousterhout, Professor of Computer Science at Stanford University, discusses complex techniques on how to become a more confident coder. John is excited to announce that he just published the first edition of a new book on software design, based on material from a software design class he has been teaching at Stanford for the last several years.

Prior to joining Stanford, John spent 14 years in industry where he founded two companies, preceded by another 14 years as a professor at Berkeley. Over the course of his career, Professor Ousterhout has built a number of influential systems (Sprite OS, Tcl.Tk, log structured file systems, Raft, RAMcloud, etc) and has taught several courses on software design. In this talk, he synthesizes these experiences into an insightful and provocative discussion on how to (and how not to) design software.

[ruixue]

3:46 most important thing in computer science: *problem decomposition - How do you take a complicated problem or system and chop it up into pieces that you can build relatively independently*
10:10 what are the secrets
12:36 classes should be deep
15:25 typical shallow method
17:50 one of the biggest mistakes people make:
18:46
*20:16*
20:32 example of a deep interface
21:55 defines errors out of existence
23:00 try to minimize the number of places we have to handle exceptions
26:49 3rd example: substring
34:13 tactical VS strategic programming
34:24 tactical
37:29 strategic programming approach

[zkreso]

Wow, imagine the teacher actually providing feedback on your code. No wonder Stanford has a good reputation.

[nikolatasev]

Great lecture, with great points.
But apart from the topic, what really impressed me was how honest he was. He was not afraid to say "I will have to think on that" or "I have no idea" multiple times.

[bertnijhof]

Good explanation. It reminds me of my life at the second part of the seventies, when I used the ideas of Parnas (information hiding) and Dijkstra (semaphores and layering) to design an OS for 16-bits Philips mini-computers for our Air Traffic Control systems. We used the OS from 1976 to 1990, when that mini-computer range was discontinued. One system would consist of 1 to 100 of these mini computers (2 or 3 per radar; 1 per radar display and 2 to 10 centrally).

[erwanounn]

The book is well worth it. Thanks Prof Ousterhout.

Edit: and I would add that it shines most at providing the rationales behind certain "good practices" which are more used as dogma than as heuristics to produce strong systems. Some of these rationales are not trivial (at least not for me!) and understanding them will shape your intuition for future work. Nicely done.

[Chiramisudo]

"Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat." --Sun Tzu, "The Art of War"

[alexanderkurz]

Problem decomposition ... this is what Descartes talked about in his Dicourse On The Method ... I have some notes on this, if I find them I paste a link here later ... btw, I wouldnt agree that we dont teach problem decomposition ... for example the applied category theory community talks about nothing but "compositionality" which is all about problem decomposition and solution synthesis.

[ruslanuchan]

I wish there might be an open access to his software design studio class for public.

I'm really curious about how they teach the student about tackling design problems.

[theoneed]

I'm a beginner developer, and this talk was incredibly relatable even to me as a novice. Some of the things he's objecting to/suggesting I thought of as well, and just make sense (though I'm still stuck on the substring point). I agree with the commenter that I wish there was access to his course.

[joaovitordeoliveiracarlos]

this is the most abstract talk i've ever seen

[ishaanj]

At the beginning, "Talent is overrated - the only thing that really differentiates the top performers from the average performers is how much they've practiced."
but at the end, "
I think you want to hire the person who's the fastest learner, who has the fastest slope.
I look for people who are really smart, fast learners"

[AndriiMuliar]

One of best lectures I have seen. Thank you, John Ousterhout. Thank you, Google.

[Luiz__Silva]

About teaching people to be better developers (the 10x thingy), the issue goes way deeper than just sheer practice. It does involve talent in a limited sense and many other aspects but, much more importantly, it involves your work ethics and ultimately your moral values.
To begin with, people do have different inherent abilities. I'm not saying he's arguing the contrary but some people do have the idea that we're all a blank slate and equal in all aspects. This is self-evidently wrong. Some people develop muscles better than others, some are naturally good with numbers, some thrive in dealing with people while others shy away from such a thing. If you ever lived in or close to a large family, you'll be able to easily correlate how wildly different each child can be in terms of interests and capacity to do things.
However, I agree those inherent abilities and capacities are not necessarily the determining factors of productivity. They can become a hindrance if the person is forcing himself or herself to do something diametrically contrary to their skills but even then self determination can get one at least above the average.
The ethics and moral values, however, are what drives people to put their minds and hearts into whatever they are doing. I have taught countless developers how to perform tasks from the simplest to the most complex in the work environment and outside it, and in different cultures as well. What I have observed is that very few of those developers were actually invested in their work - either trying to solve a problem or deliver a feature in the best way they could - as opposed to just doing their job and satisfying their manager or whatever external factor was pressuring them.
The good developer feels bad when they deliver code they know it's less than ideal. This sentiment drives them to do better and sometimes make contributions that are not asked by anyone else. They set a higher bar to themselves to the best of their abilities. They care about such things because they have an internal value and a conscience that bothers them otherwise.
The average developer feels good if they deliver what they were asked to deliver. They only care if they are doing a good job for external reasons, such as fear from what other people will say about their code, fear of not getting a promotion, etc. Those external factors can, to some extent, drive them to be more productive temporarily, with bursts of focus and effort. But it fails miserably in making them more productive over time and really grow as developers because the external pressure soon will burn them out and they will retreat.
If possible, good developers will spend countless hours doing and re-doing stuff until it satisfies them, thus they practice without even realizing it. With each effort, their minds are engaged and are looking for opportunities to improve and satisfy their own high standards.
The average developer can repeat the same task over and over again but their mind is not as engaged and focused because they are not looking for an improvement but just to finish the job at hand. Repetition can make them a little faster as they get used to perform the same tasks. But that's not the same as improving how they perform the tasks, not by a long shot.
The conclusion is that making developers more productive is not about providing them with more training or more time to practice, it's about changing their hearts, giving them passion for what they are doing, making them care about the code and the features. I don't have an answer for how to make such fundamental changes in people's mind and so far I don't think anybody can do that effectively and at scale. So I guess we will have just to continue pretending it's all about opportunity and knowledge.

[iosbfree]

Great talk. Great presenter. Great developer. Great ideas!
Thank you so much for sharing this!
❤🧡💛💙

[kribrigdefoo]

this guy speaks from experience, very practical advice

[andrew]

One thing though about a shallow class is, even if the signature is technically a bit more, it helps you abstract business logic so that if tgat piece ever needs to change it's only a single spot. Also it helps guard against mis-writing that small logical bit in multiple places in the code. A compiler can verify correct usage (mostly) of the function but not of the logic.

[nadellakailash]

[23/01, 11:18] Bhuvanesh Nadella: In the video, John Ousterhout discusses his views on software design and how it can be improved. He talks about his new book on the subject, and how he hopes it will start a discussion on how to improve software design. He also talks about how he thinks testing considerations like unit testing can influence interfaces and abstractions.

00:00:00 In this talk, John Ousterhout argues that software design is still a black art, and that there is no agreed-upon definition of what a good piece of software looks like. He goes on to discuss his new course on software design, and how he hopes it will start a conversation about how to improve the design of software.
00:05:00 In this talk, John Ousterhout discusses his philosophy of software design, which is based on the idea that anyone can learn to be a great software developer with the right amount of practice. He describes his course at Stanford, which uses an iterative approach to teaching students how to design software.
[23/01, 11:18] Bhuvanesh Nadella: 00:20:00 In the video, John Ousterhout argues that striving for shorter methods is not as important as striving for deeper abstractions, and that exceptions are a huge source of complexity. He gives three examples of how redefining the semantics of a function can eliminate the need for exceptions altogether.
00:25:00 John Ousterhout argues that exceptions should be avoided whenever possible, as they are often the result of programmer error. He gives the example of the Java substring method, which he believes should be more forgiving in terms of indexing. Ousterhout believes that making it easier for programmers to do the right thing will ultimately lead to fewer mistakes being made.
00:30:00 The speaker argues that exceptions are best used when they are thrown farthest up the stack, as this allows for better error handling by the caller. He also argues that crashing is sometimes the best option, as it can avoid complexity and data corruption.
00:35:00 John Ousterhout talks about the importance of good design in software development, and how it can help developers work faster in the future. He argues that working code is not enough, and that developers need to sweat the small stuff in order to create a great design.
[23/01, 11:18] Bhuvanesh Nadella: 00:05:00 In this talk, John Ousterhout discusses his philosophy of software design, which is based on the idea that anyone can learn to be a great software developer with the right amount of practice. He describes his course at Stanford, which uses an iterative approach to teaching students how to design software.
00:10:00 John Ousterhout discusses the importance of deep classes in software design. He argues that classes should have a simple interface with a large amount of functionality underneath. He also discusses the importance of mindset in software design, and how red flags can help beginners identify problems in their designs.
00:15:00 In the YouTube video "A Philosophy of Software Design | John Ousterhout | Talks at Google", John Ousterhout discusses the importance of design in software development and gives examples of shallow and deep design. He argues that shallow design is often more complex than it needs to be and that classes should be designed with future expansion in mind.
[23/01, 11:18] Bhuvanesh Nadella: 00:40:00 John Ousterhout argues that a good software design culture is important for attracting top talent, and that a company should invest 10-20% of their resources into design. He also advocates for taking small steps, designing interfaces and documentation, and always looking for ways to improve the codebase.
00:45:00 In this video, John Ousterhout talks about his philosophy of software design. He emphasizes the importance of constantly asking oneself whether one is doing the best they possibly can, and of investing time and resources into making designs better. He also talks about how teaching the course has helped him to become a better designer himself.
00:50:00 In the "A Philosophy of Software Design | John Ousterhout | Talks at Google" video, John Ousterhout discusses his views on software design and how he thinks it can be improved. He talks about his new book on the subject, and how he hopes it will start a discussion on how to improve software design. He also talks about how he thinks testing considerations like unit testing can influence interfaces and abstractions.
[23/01, 11:18] Bhuvanesh Nadella: 00:55:00 In the YouTube video "A Philosophy of Software Design | John Ousterhout | Talks at Google", John Ousterhout discusses his views on software design, specifically in relation to the use of threads and the Tk programming language. He states that threads are a necessary evil in some cases, but that they can be difficult to program. He also shares his opinion that the Tk language is not as well suited for web applications as it could be.
01:00:00 - 01:00:00
John Ousterhout argues that the best way to hire software designers is to find people that you enjoy talking to during the interview process. He admits that this may not lead to the most diverse team, but says that it has worked well for him in the past.

01:00:00 In this talk, John Ousterhout discusses his philosophy on software design. He argues that the best way to hire software designers is to find people that you enjoy talking to during the interview process. He admits that this may not lead to the most diverse team, but says that it has worked well for him in the past.

[huangjun]

the exception handling part is really helps, thank you, john

[thyssenbot]

2 cents:
1. A deep class is a borderline monolith. A module should be deep with classes that have high cohesion and purpose.
2. The substring debate was meaningless. It does not have to be either-or.
First function:
string Substring(int, int) throws IndexOutOfBoundsException
Second function:
string GetSubstringOrNull(int, int) // return null if the index is out of bounds/ mismatch etc
Third function:
string GetSubstringOrEmpty(int, int) // return an empty string if the index is out of bounds/ mismatch etc

Second and third save this code from being written repeated by hundreds of developers and further give them a choice of whether they care about the bounds (check for null on return if they do) or don't (empty).

[jeanapolo]

The MAJOR exception to what the speaker talks about in 33:00 is when you're dealing with a Real-Time System for a Critical device for either medicine, aerospace and defense industries where when you allow the software to put up its hands and say "I give up" and crash very BAD things happen. in these industries, you not only have to make sure your system is resilient to crashing but WHEN it does crash, how do we recover from the crash? You usually need your system to do this in VERY quick succession.

For soft systems like consumer and server systems applications an occasional crash is fine and won't necessarily have a BIG impact on the overall functionality of the system as a whole. Thankfully in systems OUTSIDE of medical, aerospace and defense, systems engineers have a bit more "breathing room" in that regard.