Latest / The Pragmatic Engineer / The Philosophy of Software Design – with John Ousterhout

Transcript

The Philosophy of Software Design – with John Ousterhout · The Pragmatic Engineer

0:00
SPEAKER_00: Right now, there is a huge explosion of AI and LLM tools.
0:03
SPEAKER_00: How might this change software engineering?
0:06
There's things that seem relatively clear and things that seem
0:08
less clear.
0:09
I think on the relatively clear side is that the AI tools will
0:12
make it easier to
0:13
SPEAKER_01: churn out low-level code.
0:14
SPEAKER_01: You should call it autocomplete.
0:15
SPEAKER_01: Autocomplete will get better and better.
0:17
SPEAKER_01: It could actually be reasonably high-quality code that gets churned out.
0:20
SPEAKER_01: So it seems like that will probably happen.
0:22
SPEAKER_01: And the big question is,
0:23
to what degree can the AI tools actually replace the
0:26
higher-level design tasks?
0:28
SPEAKER_01: I don't know the answer to that.
0:30
So far,
0:30
I don't see anything in the current tools that makes me think
0:34
they're going to do that.
0:36
SPEAKER_01: But what's interesting about this,
0:37
SPEAKER_01: I think,
0:37
SPEAKER_01: is that by handling more and more of the low-level programming tasks,
0:42
SPEAKER_01: what software designers do is going to be more and more design.
0:45
SPEAKER_01: I think software design is going to become more and more important.
0:48
That'll be a larger and larger fraction of where developers
0:51
spend their time,
0:52
which makes it even more sad that we don't really teach
0:54
software design at our
0:55
SPEAKER_01: universities at all.
0:56
John Osterhauld is the author of a philosophy of software
0:58
design and currently a
1:00
SPEAKER_00: professor of computer science at Stanford.
1:02
SPEAKER_00: John Kohl founded two tech companies,
1:04
SPEAKER_00: worked at some microsystems,
1:05
SPEAKER_00: created a TCL scripting language,
1:07
and invented the RAF consensus algorithm that is used across
1:10
databases and systems
1:11
SPEAKER_00: like MongoDB,
1:12
SPEAKER_00: CockroachDB,
1:13
SPEAKER_00: Kafka,
1:13
SPEAKER_00: and others.
1:14
SPEAKER_00: In our conversation,
1:15
we cover the impact of AI on software engineering and why
1:19
software design could
1:19
SPEAKER_00: become more important than before.
1:22
SPEAKER_00: the concept of deep and shallow modules,
1:24
and why deep modules are so important to deal with complexity
1:26
in software,
1:28
SPEAKER_00: John's advice on error handling,
1:29
SPEAKER_00: commenting,
1:30
SPEAKER_00: and why he suggests avoiding test-driven development,
1:33
SPEAKER_00: and many more topics.
1:35
SPEAKER_00: If you're interested in practical software design tactics and strategies,
1:38
SPEAKER_00: and want to take a step back from tactical coding,
1:41
SPEAKER_00: this episode is for you.
1:42
If you enjoy the show,
1:43
please subscribe to the podcast on any podcast platform and on YouTube.
1:47
SPEAKER_00: Welcome to the podcast.
1:48
SPEAKER_00: Thank you.
1:49
SPEAKER_00: I'm excited to be here.
1:50
SPEAKER_00: You have been working in academia at Stanford for quite a while,
1:53
SPEAKER_00: but you were in the industry beforehand.
1:55
SPEAKER_00: What made you change from working at tech companies,
1:58
SPEAKER_00: from founding your own companies to academia?
2:00
SPEAKER_00: And why did you do it?
2:03
SPEAKER_01: I've always wanted to do both academia and industry.
2:07
SPEAKER_01: When I got my PhD,
2:08
I debated what to do because I love the creative freedom of
2:13
academia and I love
2:14
SPEAKER_01: teaching also.
2:15
SPEAKER_01: But I also love building real software.
2:19
SPEAKER_01: Coding is one of the passions that I live for in my life.
2:22
SPEAKER_01: And so I always kind of figured I'd probably do both over my career.
2:25
SPEAKER_01: But when I got my PhD,
2:26
SPEAKER_01: the advice I was given was,
2:27
SPEAKER_01: if you're going to do both,
2:29
it's always better to do academia first because it's easier to
2:31
switch from academia
2:33
SPEAKER_01: to industry than the other way around.
2:35
SPEAKER_01: So I went to Berkeley, had a fabulous 14 years there.
2:37
But over time,
2:39
this nagging feel for wanting to build commercial software had
2:42
built up.
2:43
SPEAKER_01: And so I finally decided to take the plunge.
2:44
SPEAKER_01: I gave up my position at Berkeley,
2:46
SPEAKER_01: moved to Silicon Valley,
2:47
SPEAKER_01: worked at Sun for a few years,
2:48
SPEAKER_01: started a couple of only moderately successful companies,
2:52
SPEAKER_01: and had a great time doing that.
2:54
SPEAKER_01: Just learned a ton of stuff doing startups.
2:58
But over time,
2:59
the nagging of the call of industry kind of built up in me.
3:03
SPEAKER_01: And I gradually realized,
3:05
SPEAKER_01: although I liked doing startups,
3:07
SPEAKER_01: that I think being a professor,
3:09
SPEAKER_01: that's my real true passion in life.
3:12
So after doing startups for 14 years,
3:14
I was fortunate enough to get a position at Stanford.
3:16
And I've had another 14 or 15 years back at Stanford where I've
3:19
been really happy.
3:20
SPEAKER_01: So it's been really fun, really fun getting to see both sides.
3:24
SPEAKER_01: And honestly, I think...
3:25
SPEAKER_01: You know, doing both has actually made me better at both.
3:29
SPEAKER_00: What you see,
3:30
SPEAKER_00: I talk with a lot of people,
3:32
SPEAKER_00: obviously,
3:33
who are only in the industry and maybe they're thinking of one
3:36
day doing academia.
3:38
SPEAKER_00: I at some point thought of this myself.
3:40
SPEAKER_00: My dad is a university teacher, was a university teacher.
3:44
SPEAKER_00: And obviously there's people in academia.
3:45
SPEAKER_00: Having them both,
3:47
SPEAKER_00: what are big differences between,
3:49
SPEAKER_00: you know,
3:49
SPEAKER_00: as we call the tech world,
3:50
SPEAKER_00: which is industry and academia?
3:52
SPEAKER_00: Yeah.
3:53
Well,
3:53
first,
3:53
it wasn't as different as I thought it was going to be when I
3:56
went to industry.
3:57
SPEAKER_01: Really?
3:59
SPEAKER_01: Because in both cases, you're working with a relatively small team.
4:04
You're trying to do something relatively new,
4:08
trying to build software that really works.
4:09
SPEAKER_01: Even when I was in academia,
4:10
SPEAKER_01: we tried to build stuff that really works,
4:12
SPEAKER_01: not just throwaway research prototypes.
4:15
SPEAKER_01: So in many ways, it wasn't that different.
4:17
SPEAKER_01: But in other ways,
4:18
SPEAKER_01: it was in that you deal with a much broader spectrum of people,
4:21
SPEAKER_01: you know,
4:22
SPEAKER_01: salespeople and marketing people and financers and venture capitalists.
4:26
That was one of the fun things about it is seeing a much
4:28
greater diversity of people.
4:30
SPEAKER_01: I would say the difference that contributed to my going back to academia,
4:35
SPEAKER_01: I would say one of the downsides of industry,
4:39
is that there's tremendous pressure in startups particularly to
4:43
make yourself look
4:44
SPEAKER_01: bigger and better than you are.
4:45
SPEAKER_01: You know, you're trying to survive and get funding.
4:48
SPEAKER_01: And so there's a lot of pressure to...
4:52
SPEAKER_01: spin your company and exaggerate and market yourself.
4:57
SPEAKER_01: I mean, everybody does it to some degree.
4:59
SPEAKER_01: Some people do it in ways so stream it's illegal.
5:01
SPEAKER_01: They get in trouble.
5:03
SPEAKER_01: But that kind of bothered me.
5:06
And within my companies,
5:08
of course,
5:08
we had to market ourselves externally.
5:10
SPEAKER_01: But internally, we tried to be very honest.
5:12
I don't want to hear lies and spinning internally because that
5:14
puts our company at
5:15
SPEAKER_01: risk if you do that.
5:17
SPEAKER_01: But nonetheless,
5:18
SPEAKER_01: the thing I like about academia is you do a project,
5:21
SPEAKER_01: some of them work,
5:22
SPEAKER_01: some of them don't.
5:23
If a project doesn't work,
5:24
you just say,
5:25
oops,
5:26
okay,
5:26
that wasn't a good idea.
5:27
SPEAKER_01: Here's why.
5:28
SPEAKER_01: And you go on to the next thing.
5:29
In a company,
5:30
if it's not working,
5:31
you can't really say,
5:33
oops,
5:33
that didn't work.
5:34
SPEAKER_01: Sorry, everybody, we're shutting down tomorrow.
5:35
SPEAKER_01: You try and somehow figure some way around it.
5:37
So I think that was the thing,
5:39
the one thing about industry that I liked least.
5:42
SPEAKER_00: This episode was brought to you by CodeRabbit,
5:44
the AI code review platform transforming how engineering teams
5:47
shift faster without
5:48
SPEAKER_00: sacrificing code quality.
5:50
SPEAKER_00: Code reviews are critical, but time consuming.
5:53
CodeRabbit acts as your AI co-pilot providing instant code
5:56
review comments and
5:57
SPEAKER_00: potential impacts of every pull request.
6:00
SPEAKER_00: Beyond just flagging issues,
6:02
CodeRabbit provides one-click fix solutions and lets you define
6:05
custom code quality
6:06
SPEAKER_00: rules using AST graph patterns,
6:08
SPEAKER_00: catching subtle issues that traditional static analysis tools might miss.
6:13
SPEAKER_00: CodeRabbit has so far reviewed more than 5 million pull requests,
6:16
SPEAKER_00: is installed on 1 million repositories,
6:19
SPEAKER_00: and is used by 50,000 open source projects.
6:22
Try CodeRabbit free for one month at coderabbit.ai using the
6:26
code pragmatic.
6:27
SPEAKER_00: That is coderabbit.ai and use the code pragmatic.
6:33
This episode is brought to you by modal,
6:34
the cloud platform that makes AI development simple.
6:37
SPEAKER_00: Need GPUs without the headache.
6:39
SPEAKER_00: With modal,
6:40
SPEAKER_00: just add one line of code to any Python function and boom,
6:43
SPEAKER_00: it's running in the cloud on your choice of CPU or GPU.
6:46
SPEAKER_00: And the best part, you only pay for what you use.
6:50
SPEAKER_00: With sub-second container start and instant scaling to thousands of GPUs,
6:54
SPEAKER_00: it's no wonder companies like Suno,
6:55
SPEAKER_00: Ramp,
6:56
SPEAKER_00: and Substack already trust modal for their AI applications.
6:59
SPEAKER_00: Getting an H100 is just a pip install away.
7:02
SPEAKER_00: Go to modal.com slash pragmatic to get $30 in free credits every month.
7:07
SPEAKER_00: That is modal.com slash pragmatic.
7:11
SPEAKER_00: Now,
7:11
SPEAKER_00: thanks to you having worked in academia as well,
7:14
SPEAKER_00: and you taught a course,
7:16
SPEAKER_00: which we'll later talk about,
7:17
SPEAKER_00: but you wrote this book,
7:19
SPEAKER_00: The Philosophy of Software Design.
7:20
And a lot of people in the tech world who I talk with point to
7:23
this book as one of
7:25
SPEAKER_00: the best books that gives them specific,
7:29
SPEAKER_00: actionable things,
7:30
SPEAKER_00: ways to think about software design.
7:32
SPEAKER_00: I just want to go into some of the things into the book.
7:35
SPEAKER_00: People who've read it will find this refreshing,
7:37
SPEAKER_00: and people who haven't might find it as new ideas.
7:40
SPEAKER_00: In the very beginning of the book,
7:42
SPEAKER_00: in chapter,
7:43
SPEAKER_00: I think two or three,
7:45
SPEAKER_00: in the first 10 or 15 pages,
7:46
SPEAKER_00: you write about something called tactical tornadoes.
7:49
SPEAKER_00: And let me just quote a little bit from this.
7:53
SPEAKER_00: You wrote,
7:53
a tactical tornado is a prolific programmer who pumps out code
7:56
faster than others works,
7:58
SPEAKER_00: but does it in totally tactical fashion.
8:00
SPEAKER_00: When it comes to implementing a quick feature,
8:03
SPEAKER_00: nobody gets it done faster than a tactical tornado.
8:05
SPEAKER_00: In some organizations, management treats tactical tornadoes as heroes.
8:09
SPEAKER_00: However,
8:09
SPEAKER_00: tactical tornadoes leave a wave of destruction behind,
8:13
and typically other engineers must clean up the messes left by
8:15
this tactical tornado.
8:16
So I wanted to ask you,
8:18
first of all,
8:18
how did you come across your first tactical tornado?
8:22
SPEAKER_00: And...
8:23
Why do you think these types of folks are still around in most companies?
8:28
Because I had an aha moment when I was like,
8:30
oh yeah,
8:31
I know the tactical tornadoes as well.
8:33
I can't point to a specific incident or person,
8:36
and I wouldn't want to identify them anyway.
8:38
SPEAKER_01: But I've encountered them over my career.
8:40
I bet everybody who has significant software development
8:43
experience has encountered
8:44
SPEAKER_01: these people over your career.
8:46
SPEAKER_01: And just kind of observing them and the frustration with that,
8:51
SPEAKER_01: I think it's just a particular personality type.
8:54
SPEAKER_01: There are people who are very detail-focused and closers,
8:59
SPEAKER_01: want to get absolutely everything right,
9:00
SPEAKER_01: and they finish everything.
9:02
And there's people who love getting started on projects and
9:06
doing the first 80% or 90%,
9:08
SPEAKER_01: but that last 10% or 20% doesn't matter to them so much,
9:11
SPEAKER_01: and they're not.
9:13
You know,
9:13
there's just like there's neater people and there's sloppier
9:16
people in the world.
9:16
SPEAKER_01: So, the technical owners are just sort of sloppy.
9:18
SPEAKER_01: They don't care about, you know, leaving cruft behind.
9:21
SPEAKER_01: It doesn't really bother them at all.
9:23
SPEAKER_01: It's just a personality type.
9:25
SPEAKER_01: So,
9:25
SPEAKER_01: I suspect they'll always be there,
9:27
SPEAKER_01: particularly because some organizations value speed above all else.
9:33
SPEAKER_00: Especially startups, right?
9:34
SPEAKER_01: Yeah, a lot of startups.
9:37
There are startups that are probably completely staffed by
9:39
tactical tornadoes.
9:40
SPEAKER_00: You call them tactical tornadoes,
9:41
but some of the synonyms that came into my mind as I was
9:46
thinking of what people use,
9:47
SPEAKER_00: sometimes they use a 10x engineer.
9:49
SPEAKER_00: Especially when management sees, oh, they just get things faster.
9:52
SPEAKER_00: Sometimes,
9:53
SPEAKER_00: you know,
9:53
like it's a hacky way of doing things or someone who just hacks
9:56
quickly or at some point,
9:58
SPEAKER_00: maybe a decade ago,
9:59
SPEAKER_00: people call it a hacker,
10:01
SPEAKER_00: but in a way of working fast.
10:02
SPEAKER_00: But I don't think we have that anymore.
10:04
SPEAKER_00: But there are a lot of cases.
10:06
SPEAKER_00: It is a positive thing.
10:08
SPEAKER_00: Indeed.
10:09
SPEAKER_00: Well, I was seen as a positive initially.
10:12
SPEAKER_01: When I think of 10X engineers and the way Google defined it,
10:15
SPEAKER_01: I don't think of these as tactical tornadoes.
10:17
I think of these are people who come up with the really clean
10:20
designs that can be
10:22
SPEAKER_01: implemented in very small amounts of code.
10:25
SPEAKER_01: And so they might actually write less code per day than other people,
10:30
SPEAKER_01: but the functionality that they implement is way higher,
10:34
SPEAKER_01: and it comes with higher stability and evolvability and so on.
10:37
SPEAKER_01: So to me, at least, that's the 10X engineer.
10:41
SPEAKER_00: I agree with you.
10:42
I'll just add the note that I think the 10x engineer is so
10:45
ambiguous that it means
10:46
SPEAKER_00: different for every person.
10:48
And especially so when I've seen it was mostly less technical
10:53
CEOs refer to my 10x
10:55
SPEAKER_00: engineer who was a tactical tornado because what they saw is,
10:58
SPEAKER_00: oh,
10:58
SPEAKER_00: I'm getting output.
10:59
SPEAKER_00: They're not saying no, they're building it.
11:01
SPEAKER_00: But of course,
11:02
SPEAKER_00: they had trouble understanding the tech depth that is going into there,
11:05
SPEAKER_00: how it's slowing others down.
11:06
And some of the people that you talked about in this
11:08
environment might have not
11:09
been perceived as a 10x engineer by this person who is not that
11:14
close to the code.
11:15
SPEAKER_00: And I totally agree with you, by the way.
11:17
SPEAKER_00: But this is probably a good reminder of everything is relative, right?
11:22
SPEAKER_00: Everything is based on your vantage point.
11:23
If you are close to the code,
11:25
you're technical,
11:26
you will value other things.
11:27
SPEAKER_00: You should value other things.
11:28
SPEAKER_00: Yeah.
11:30
SPEAKER_01: You know, I think a lot of this comes down to strategic versus tactical.
11:34
SPEAKER_01: Again,
11:34
there are people who value all the short-term stuff and there
11:36
are people who value,
11:38
SPEAKER_01: place more emphasis on the long-term stuff.
11:40
SPEAKER_01: And my view of design is all about the long-term stuff.
11:43
But as you've said,
11:43
there are many people who think of it all in terms of
11:46
short-term stuff.
11:47
And so I can see how they would have a different idea of what a
11:49
10X engineer is.
11:51
SPEAKER_00: And speaking of long-term versus short-term,
11:53
SPEAKER_00: one thing that came to my mind,
11:55
SPEAKER_00: rereading this tactical tornado part,
11:58
SPEAKER_00: is right now there's a huge explosion of AI and LLM tools,
12:02
SPEAKER_00: which are,
12:03
SPEAKER_00: as you're probably seeing it,
12:05
SPEAKER_00: they are really good at generating code rapidly.
12:07
SPEAKER_00: A little bit like the tactical tornado, to be honest.
12:09
SPEAKER_00: You can prompt them,
12:10
SPEAKER_00: they can do short,
12:11
SPEAKER_00: they can do long,
12:11
SPEAKER_00: they can do autocomplete,
12:13
SPEAKER_00: they can do all skeletons.
12:14
SPEAKER_00: I was wondering,
12:16
SPEAKER_00: so far what you've observed,
12:17
SPEAKER_00: what do you think the long-term impact of these tools,
12:21
SPEAKER_00: if we assume that this is how they're going to stay,
12:22
SPEAKER_00: let's just assume that,
12:24
SPEAKER_00: you know,
12:25
every engineer will have tactical tornadoes at their fingertips
12:28
and who do not say
12:29
SPEAKER_00: no and they will,
12:30
SPEAKER_00: you know,
12:30
SPEAKER_00: churn out code.
12:32
SPEAKER_00: How might this change software engineering personally?
12:37
SPEAKER_01: That's a really interesting question, and I wish I knew the answer.
12:41
SPEAKER_01: I don't.
12:41
SPEAKER_01: I can only guess.
12:43
SPEAKER_01: I think we're going to see big changes over the next five to ten years,
12:47
SPEAKER_01: and it's really hard to predict what direction they're going to go.
12:51
There's things that seem relatively clear and things that seem
12:53
less clear.
12:54
I think on the relatively clear side is that the AI tools will
12:58
make it easier to
12:59
SPEAKER_01: churn out low-level code.
13:01
SPEAKER_01: As you call it, autocomplete.
13:02
SPEAKER_01: Autocomplete will get better and better.
13:04
SPEAKER_01: And I think it won't necessarily be sort of tactical tornado stuff.
13:08
SPEAKER_01: It could actually be reasonably high-quality code that gets churned out.
13:11
SPEAKER_01: So it seems like that will probably happen.
13:14
SPEAKER_01: And the big question is,
13:17
to what degree can the AI tools actually replace the
13:20
higher-level design tasks?
13:23
SPEAKER_01: And I don't know the answer to that.
13:26
So far,
13:26
I don't see anything in the current tools that makes me think
13:31
they're going to do that.
13:32
SPEAKER_01: But never underestimate what could happen.
13:37
SPEAKER_01: But what's interesting about this,
13:38
SPEAKER_01: I think,
13:39
SPEAKER_01: is that by handling more and more of the low-level programming tasks that
13:45
SPEAKER_01: What software designers do is going to be more and more design.
13:49
SPEAKER_01: So I think software design is going to become more and more important.
13:54
That'll be a larger and larger fraction of where developers
13:56
spend their time,
13:58
which makes it even more sort of sad that we don't really teach
14:02
software design in
14:02
SPEAKER_01: our universities at all.
14:04
So the skills we're teaching students may actually be the
14:07
skills that are going to
14:08
SPEAKER_01: be replaced by the AI tools.
14:12
SPEAKER_00: Can we just double click on software design?
14:16
SPEAKER_00: How do you see software design?
14:18
SPEAKER_00: What is it and why is it important?
14:21
SPEAKER_00: And the reason I'm asking the question,
14:23
SPEAKER_00: it might seem like a naive question,
14:25
but these days you really can get started building an
14:28
application by taking a template,
14:32
SPEAKER_00: using it.
14:33
You will soon be able to prompt an AI tool that will generate
14:38
things for you.
14:39
SPEAKER_00: How do you think about it?
14:40
SPEAKER_00: software design?
14:43
SPEAKER_00: It's abstract, right?
14:44
SPEAKER_00: By nature.
14:44
SPEAKER_01: So, well, I think of it as it's a decomposition problem.
14:50
SPEAKER_01: It's how do you take a large,
14:52
complicated system and divide it up into smaller units that you
14:56
could implement
14:57
SPEAKER_01: relatively independently?
14:59
SPEAKER_01: And by the way,
15:00
SPEAKER_01: to me,
15:02
SPEAKER_01: when I give talks,
15:02
SPEAKER_01: I often ask people,
15:03
SPEAKER_01: what do you think is the most important idea at all of computer science?
15:06
SPEAKER_01: And ask the audience.
15:07
SPEAKER_01: To me, I think decomposition.
15:09
That's the key thing that threads through everything we do in
15:11
computer science.
15:12
SPEAKER_01: How do you take large, complicated problems and break them up?
15:14
SPEAKER_01: And that's design.
15:15
SPEAKER_01: And then implementation is when you go about the individual pieces.
15:19
But again,
15:19
you may do more design of those to break them up into still
15:22
smaller pieces.
15:23
SPEAKER_01: But that's the way I think about software design.
15:26
SPEAKER_00: Now,
15:26
an interesting thing that I've noticed over the past few
15:29
decades is about 20 years
15:32
SPEAKER_00: or so,
15:33
SPEAKER_00: maybe a little bit more,
15:34
there was a lot of focus on architectural practices that felt
15:38
closer to software design.
15:39
Things like TDD,
15:40
test-driven development,
15:42
architecture approaches like architecture patterns.
15:45
SPEAKER_00: I think they were called design patterns,
15:46
SPEAKER_00: a gang of four,
15:47
SPEAKER_00: different like factory,
15:48
SPEAKER_00: et cetera,
15:49
SPEAKER_00: patterns.
15:49
SPEAKER_00: However...
15:51
SPEAKER_00: The focus seems to be moving away, at least in the industry.
15:56
SPEAKER_00: There's fewer people referencing these models, these ideas.
16:00
From your observation,
16:01
both in academia and industry,
16:03
why do you think this might have been?
16:04
Why did we have such a big focus on architecture design topics
16:09
10 or 20 years ago?
16:11
And maybe just we're talking about it less or maybe even
16:14
thinking about it less.
16:15
SPEAKER_00: Yeah.
16:15
SPEAKER_01: Well,
16:15
SPEAKER_01: you know,
16:16
SPEAKER_01: of course,
16:16
there's always fads that everybody gets excited about and they
16:18
gradually fade away.
16:20
SPEAKER_01: So maybe that's part of it.
16:22
SPEAKER_01: Now, to me, the things you mentioned, TDD and patterns...
16:27
SPEAKER_01: I don't think of those as design, certainly not TDD.
16:32
In fact,
16:33
I would argue if you want to get into a TDD discussion,
16:35
we could have that.
16:35
SPEAKER_01: But I would argue it actually works against design.
16:38
SPEAKER_01: Design patterns, that's an alternative to design.
16:41
That is,
16:42
rather than designing something,
16:43
you pull something off the shelf.
16:46
SPEAKER_01: Where it works, it works.
16:47
Certainly,
16:47
there's areas where,
16:48
of course,
16:49
if a pattern works,
16:50
you should just use it.
16:51
But to me,
16:51
that only addresses a tiny,
16:53
tiny fraction of what I think of as software design.
16:56
There's so much more to design than just picking one of a half
16:59
a dozen patterns.
17:00
SPEAKER_00: When you're building new software and you're saying,
17:05
SPEAKER_00: okay,
17:05
SPEAKER_00: I'm going to start to design,
17:07
SPEAKER_00: how do you start designing?
17:09
SPEAKER_00: Is it sitting down pen and paper?
17:11
SPEAKER_00: And if we can talk about something specific,
17:14
SPEAKER_00: I think that could be even useful if there was a project that you did.
17:18
SPEAKER_00: Because I'm just really curious about your thinking.
17:21
SPEAKER_01: I can't give a recipe for design.
17:23
SPEAKER_01: I wish I could.
17:24
SPEAKER_01: Follow these steps in this order and you'll get a great design.
17:28
SPEAKER_01: I wish I could.
17:29
But,
17:29
you know,
17:30
there's two general approaches,
17:32
each of which has its pitfalls.
17:33
SPEAKER_01: This is the top-down approach and the bottom-up approach.
17:36
SPEAKER_01: I think what people tend to use,
17:38
particularly less experienced engineers or people who are in a
17:43
domain that they're
17:44
SPEAKER_01: not familiar with,
17:45
SPEAKER_01: is you do bottom-up.
17:46
SPEAKER_01: You just say, okay...
17:48
SPEAKER_01: I'm going to need this functionality in this system.
17:50
I have no idea what the overall system is going to look like,
17:52
but I need this piece.
17:53
SPEAKER_01: I'll just build this piece.
17:55
SPEAKER_01: Then you pick another piece and you build it.
17:57
Then you start trying to put the pieces together and you
17:59
gradually layer in your design.
18:02
SPEAKER_01: That's the bottom-up approach.
18:04
The top-down approach is you start at the top and you try and
18:07
break the system up
18:08
into what you think are relatively independent components and
18:10
then decompose those
18:11
SPEAKER_01: until you eventually get something that you can design.
18:16
SPEAKER_01: And by the way,
18:17
SPEAKER_01: in the 1970s,
18:18
SPEAKER_01: back when I was in graduate school,
18:19
there was a big discussion about should you do design top-down
18:22
or bottom-up,
18:22
SPEAKER_01: and people argued about it.
18:24
SPEAKER_01: My personal opinion is that it's hard to do either one pure,
18:27
that the actual process of design is some combination where you
18:31
think about big pieces,
18:32
SPEAKER_01: and then you start thinking about some little pieces,
18:34
SPEAKER_01: and you build some stuff,
18:35
SPEAKER_01: and you discover it actually didn't work very well,
18:37
SPEAKER_01: so you throw it away,
18:38
SPEAKER_01: and you build some more stuff.
18:39
SPEAKER_01: And it's this iterative kind of back-and-forth process.
18:42
SPEAKER_01: Yeah.
18:45
SPEAKER_00: It's interesting that you mentioned the two ways,
18:48
SPEAKER_00: because in the book,
18:49
the book itself starts with you writing how design is all about
18:54
managing complexity,
18:56
SPEAKER_00: and then you bring these two approaches.
18:58
SPEAKER_00: What were the two approaches to complexity?
19:00
So one is that there are certain things you can do in design
19:03
that simply eliminate
19:04
SPEAKER_01: complexity completely.
19:06
SPEAKER_01: Eliminating working on special cases and things like that.
19:09
SPEAKER_01: So those are the best, most powerful approaches.
19:12
SPEAKER_01: But you can't eliminate all complexity.
19:15
SPEAKER_01: So then the second approach is where you use modular design,
19:19
SPEAKER_01: where you basically try and hide the complexity.
19:21
SPEAKER_01: That is,
19:21
you take things that are relatively complicated and put them
19:24
off to the side where
19:25
SPEAKER_01: somebody can solve this problem and deal with this complexity,
19:28
SPEAKER_01: and nobody else in the system has to be aware of that complexity.
19:32
SPEAKER_01: So those were the two overall ways of dealing with complexity.
19:37
And good software design will help us deal,
19:42
like,
19:43
wrangle complexity,
19:44
right?
19:44
SPEAKER_00: Do I sense that that's one of the... It will do with both of those.
19:47
SPEAKER_01: It will both give you ideas for how to eliminate it and also for how to,
19:51
SPEAKER_01: again,
19:52
modularize it so most people don't have to be aware of most of
19:55
the complexity.
19:57
One interesting idea that resonated with the book is you wrote
20:01
about how it's worth
20:03
SPEAKER_00: designing things twice.
20:05
SPEAKER_00: In fact, this is a whole chapter in the book, chapter 11.
20:07
SPEAKER_00: It's called Designing It Twice.
20:09
SPEAKER_00: And you wrote,
20:10
SPEAKER_00: I'll quote from you,
20:12
SPEAKER_00: Unfortunately,
20:12
I often see smart people who insist implementing the first idea
20:15
that comes to mind,
20:16
SPEAKER_00: and this causes them to underperform their true potential.
20:19
SPEAKER_00: It also makes them frustrating to work with.
20:23
SPEAKER_00: How did you come across this observation?
20:26
And one more thing that you added is it doesn't take more time
20:31
to design twice than
20:33
SPEAKER_00: what most people think.
20:36
SPEAKER_01: Yeah.
20:36
SPEAKER_01: So first,
20:38
the way I came across this is because I've been a professor at
20:40
both Stanford and Berkeley,
20:41
SPEAKER_01: which are two of the top universities in the world.
20:45
SPEAKER_01: And both places get brilliant graduate students.
20:48
And I've noticed it's common for students at both places to
20:51
have bad work habits.
20:53
And the reason is,
20:55
all their lives,
20:56
everything's always been easy for them.
20:58
SPEAKER_01: They've always been the best at everything they did.
21:00
SPEAKER_01: In high school, they were smarter than their teachers.
21:02
SPEAKER_01: In college, perhaps as smart as their professors, top of their class.
21:06
SPEAKER_01: Their first ideas,
21:07
just the first thing that came off their mind was always good
21:09
enough to get great grades.
21:12
SPEAKER_01: And so there's never been any real incentive for them to think twice.
21:17
And I think they start kind of latching on to the idea that
21:21
whatever comes to my
21:22
SPEAKER_01: mind is going to be good.
21:24
But,
21:24
you know,
21:24
as you get into harder and harder problems,
21:27
that characteristic goes away.
21:29
SPEAKER_01: And particularly when we're doing research at top universities,
21:33
SPEAKER_01: honestly,
21:33
SPEAKER_01: we're working on really hard problems.
21:35
SPEAKER_01: Nobody's first idea is going to be the best idea.
21:38
And so I often have to work with students to force them to
21:42
think about things.
21:44
SPEAKER_01: And so, for example, a common technique I will use is I will say,
21:48
suppose I told you that you may not implement this thing you
21:51
just suggested.
21:51
SPEAKER_01: And if you try and do it,
21:52
SPEAKER_01: I'm going to stop funding you and have you thrown out as a grad student.
21:56
SPEAKER_01: What would be your second approach?
21:58
Would you come up with something or would you say,
21:59
okay,
21:59
I better look for a new advisor?
22:02
SPEAKER_01: And the interesting thing is,
22:03
SPEAKER_01: and by the way,
22:03
SPEAKER_01: I say this typically when I think there's a better way of doing it.
22:06
SPEAKER_01: And when I force them,
22:08
SPEAKER_01: And they go away and come back.
22:09
SPEAKER_01: The second idea is always better.
22:11
SPEAKER_01: It's better.
22:12
SPEAKER_01: And I've seen this myself.
22:15
The best example I can think of over my whole career was when I
22:18
was designing the
22:19
SPEAKER_01: TK Toolkit,
22:20
SPEAKER_01: which is part of the TK system.
22:24
And I was trying to figure out what should be the API for
22:27
programming graphical widgets.
22:30
SPEAKER_01: And I spent, actually, I think it was mostly a long airplane ride.
22:35
SPEAKER_01: And I basically did two designs.
22:37
SPEAKER_01: I did kind of the first idea that came to mind.
22:40
SPEAKER_01: And then I said, okay, suppose I'm going to throw that out.
22:41
SPEAKER_01: What would be something that's really different that I could do?
22:44
SPEAKER_01: I did a second one.
22:46
SPEAKER_01: And after comparing them, I ended up choosing the second idea.
22:49
And honestly,
22:50
that was one of the best ideas I've had in my professional career.
22:55
SPEAKER_01: One of the things that made TK popular was the API for TK.
22:58
SPEAKER_01: It was just a very sweet, simple, powerful API.
23:02
SPEAKER_01: And it was my second choice.
23:04
SPEAKER_01: It was the second thing that came to my mind.
23:06
SPEAKER_01: So I have that example.
23:07
SPEAKER_01: That always motivates me.
23:09
And when I'm doing new things,
23:10
I usually try and force myself to think of two ways.
23:13
SPEAKER_01: Even if I think one of them is really bad,
23:15
even come up with what you think is a bad alternative and
23:18
compare it to what you did,
23:20
SPEAKER_01: you'll learn something from that.
23:22
SPEAKER_01: And you may discover the bad thing wasn't as bad as you thought it was.
23:26
SPEAKER_00: I'm actually starting to realize,
23:28
SPEAKER_00: when I worked at Uber,
23:29
SPEAKER_00: we had this concept of design docs,
23:31
SPEAKER_00: RFCs,
23:32
SPEAKER_00: where you were expected to just write down why you're doing something,
23:37
SPEAKER_00: how you're doing it,
23:37
SPEAKER_00: etc.
23:39
SPEAKER_00: And after a while, we started to add a thing called trade-offs.
23:44
SPEAKER_00: Or alternatives considered.
23:46
SPEAKER_00: And we were asking people like,
23:47
SPEAKER_00: write down at least one,
23:49
SPEAKER_00: ideally multiple alternatives considered.
23:52
SPEAKER_00: And we did it because we got better designs,
23:56
SPEAKER_00: ideas,
23:56
SPEAKER_00: plans,
23:57
SPEAKER_00: et cetera,
23:58
SPEAKER_00: and better discussions as well,
23:59
SPEAKER_00: because it was clear why you wouldn't do it.
24:02
SPEAKER_00: And now I'm just reflecting on what you said on like,
24:05
SPEAKER_00: yeah,
24:05
SPEAKER_00: well,
24:05
SPEAKER_00: we were kind of doing a little bit of what you were saying,
24:08
SPEAKER_00: forcing people to not stop,
24:10
either not get their first idea or put down others as well and
24:13
compare them.
24:14
SPEAKER_00: What you said,
24:15
SPEAKER_00: oftentimes it will be people just doing,
24:17
SPEAKER_00: you know,
24:17
SPEAKER_00: okay,
24:17
SPEAKER_00: here's some things that will surely not work.
24:20
SPEAKER_00: And usually, fair enough, it doesn't work.
24:21
SPEAKER_00: But then sometimes they're like, oh, actually, that's a simple thing.
24:24
SPEAKER_00: And we could just use that instead.
24:25
SPEAKER_01: Or maybe we combine these two things together.
24:27
SPEAKER_00: Yeah.
24:28
And,
24:29
you know,
24:29
you asked about,
24:29
does this take a lot of time and slow down the process?
24:32
SPEAKER_01: Well, it will take some extra time, of course.
24:35
SPEAKER_01: Nothing is free.
24:36
SPEAKER_01: But honestly, the design at this level is a very high level design.
24:41
SPEAKER_01: It's not like we're completely building a second alternative.
24:45
SPEAKER_01: I kind of think at the high level.
24:47
SPEAKER_01: So with Tickle and TK,
24:48
SPEAKER_01: this TK design,
24:49
I might have spent maybe a few days on the design thinking
24:54
about these two
24:54
SPEAKER_01: alternatives and comparing them.
24:56
SPEAKER_01: But then it took a year to implement TK or more than that.
25:00
So we're talking something on the order of 1% or 2% of the
25:04
total time to build a system.
25:07
SPEAKER_01: It's just not that big of a deal.
25:09
SPEAKER_01: And if it gives you a better design, you get back way more than 1% or 2%.
25:13
SPEAKER_00: Yeah, I feel this is less than that.
25:17
SPEAKER_00: People, teams, engineers learn again and again.
25:20
You know,
25:20
first,
25:21
there's always a point where you jump into coding,
25:22
I'm faster.
25:23
SPEAKER_00: And then when it's complex enough,
25:25
SPEAKER_00: you learn,
25:25
SPEAKER_00: oh,
25:26
SPEAKER_00: we probably should have planned a little bit better.
25:27
SPEAKER_00: I would have saved myself time.
25:28
SPEAKER_00: And then after a while,
25:30
the cycle goes into like too much planning or people feel it's
25:34
too much planning
25:35
SPEAKER_00: and then it starts again.
25:36
SPEAKER_00: So I feel there's a little bit of never ending cycle,
25:39
SPEAKER_00: you know,
25:39
SPEAKER_00: there people still talk about waterfall,
25:41
SPEAKER_00: which used to be a thing like 20 or 30 years ago.
25:44
SPEAKER_00: It's not really a thing, but people like
25:47
SPEAKER_00: There is some disdain,
25:48
especially for fast-moving teams in planning too much because
25:51
it's seen as too much
25:52
SPEAKER_00: talking and not enough doing.
25:55
SPEAKER_01: Well, and I get that too.
25:59
I think the fundamental thing about design is it always
26:01
involves trade-offs.
26:03
SPEAKER_01: And if you take any one idea and you push it too far,
26:06
SPEAKER_01: you're probably going to end up in a bad place.
26:08
So this idea about doing multiple designs,
26:11
again,
26:11
you could certainly take that too far also.
26:14
And I think one of the things that separates the really good
26:18
designers from the not
26:19
as good ones is they kind of know how to make those trade-offs
26:21
and how to combine
26:23
SPEAKER_01: these different ideas and different phases and balance them off.
26:26
And that's the kind of thing probably you just have to learn
26:30
from experience.
26:31
SPEAKER_01: You try both approaches and see the bad problems with them,
26:34
SPEAKER_01: and then you eventually get a gut feel for what the trade-offs are.
26:38
SPEAKER_00: Now,
26:38
SPEAKER_00: in the book,
26:39
one idea that stuck with me is this concept of deep modules and
26:42
shallow modules.
26:44
SPEAKER_00: And you introduce this concept that a deep module is something,
26:47
SPEAKER_00: a piece of code or functionality,
26:50
SPEAKER_00: or a module that has a pretty simple interface,
26:52
SPEAKER_00: but it has a lot of depth to it.
26:53
SPEAKER_00: It has a lot of functionality complexity.
26:56
And then a shallow module is something that has a wide interface,
26:59
but it doesn't do too much.
27:01
SPEAKER_00: So it kind of...
27:03
It might be even transparent in some points that it doesn't do
27:07
much hiding.
27:09
And in the book,
27:09
you emphasize how deep modules are important for good software design.
27:15
SPEAKER_00: Why is this so?
27:16
SPEAKER_00: And how did you, again, come across this realization?
27:19
SPEAKER_01: Well, it all comes back to complexity.
27:21
And everything in the book really derives from this idea about
27:25
how do we eliminate
27:28
SPEAKER_01: or manage complexity,
27:29
SPEAKER_01: right?
27:30
SPEAKER_01: And so a deep module is what gives us leverage against complexity.
27:37
SPEAKER_01: And the way it does that is it provides this very simple interface.
27:40
So people using the module have almost no cognitive load,
27:43
very easy to learn.
27:45
SPEAKER_01: But inside the module,
27:47
there's a tremendous amount of functionality and complexity
27:50
that is hidden from
27:50
SPEAKER_01: everybody else.
27:54
SPEAKER_01: In the deep notion, I was trying to capture the trade-offs
27:58
SPEAKER_01: And basically,
27:59
SPEAKER_01: it's this trade-off between two things,
28:02
the complexity of the interface and how much functionality you
28:04
have in the module.
28:06
And so what you want to do is get the most functionality you
28:10
can for the simplest
28:12
SPEAKER_01: possible interface on top.
28:15
SPEAKER_00: In the book, you have a chapter titled, Defining Errors Out of Existence.
28:18
SPEAKER_00: And in this one, you talk about error handling.
28:21
What is your take on error handling and how to design for
28:25
sensible error handling?
28:26
SPEAKER_01: Right.
28:27
SPEAKER_01: So again, this comes back to the complexity issue.
28:30
And anybody who's built a lot of software knows that error
28:32
handling is a huge
28:34
SPEAKER_01: source of complexity.
28:36
Basically,
28:37
it's all the special cases,
28:38
all these weird special cases you have to deal with.
28:41
And so it's easy for error handling to impose tremendous
28:44
complexity on software.
28:46
So then the question I'm constantly asking myself is,
28:49
how can we reduce error?
28:51
SPEAKER_01: the impact.
28:52
SPEAKER_01: I mean, we do have some situations we have to deal with.
28:54
SPEAKER_01: There's some, you know, there's many exceptions.
28:57
SPEAKER_01: You simply can't be avoided.
28:58
SPEAKER_01: They're fundamental to the systems.
28:59
SPEAKER_01: You have to deal with them.
29:01
SPEAKER_01: Other cases where they're not so important.
29:03
SPEAKER_01: So in that chapter, what I was trying to argue is that
29:07
SPEAKER_01: Exceptions, having more exceptions is not better.
29:12
SPEAKER_01: It is sometimes necessary.
29:14
But I sometimes think that designers think that the more
29:17
exceptions I throw from a class,
29:19
SPEAKER_01: the better a programmer I'm being.
29:21
SPEAKER_01: I'm being a more cautious, careful programmer.
29:23
And I would know the problem is every exception you throw is
29:27
imposing complexity on
29:28
SPEAKER_01: the users of your class.
29:31
SPEAKER_01: And so if you can, if you can reduce the number of exceptions you throw,
29:37
the number of special cases you generate,
29:39
that will reduce system complexity.
29:41
SPEAKER_01: I gave a bunch of examples in that chapter where,
29:44
SPEAKER_01: in fact,
29:45
SPEAKER_01: by just a slight change in the design of the system,
29:49
SPEAKER_01: whole classes of errors simply disappear.
29:52
SPEAKER_01: They can't happen.
29:52
SPEAKER_01: There is no error to deal with.
29:56
SPEAKER_01: But I will say,
29:56
SPEAKER_01: this is something that happens occasionally,
30:01
SPEAKER_01: but you have to be very careful about this.
30:03
SPEAKER_01: And in the class I teach on software design,
30:07
SPEAKER_01: students have virtually every class,
30:09
SPEAKER_01: there are people that misunderstand this.
30:12
SPEAKER_01: And in the first project, they have essentially zero exception handling.
30:15
SPEAKER_01: They're building a distributed server where machines can crash,
30:17
SPEAKER_01: and they don't even check for errors in the network.
30:20
SPEAKER_01: I say, you have no error checks here.
30:22
SPEAKER_01: What happens if a system crashes?
30:24
SPEAKER_01: They say, oh, we just defined those errors out of existence.
30:29
SPEAKER_01: I say, well, no, the errors are still there.
30:34
SPEAKER_01: You're just ignoring them.
30:35
SPEAKER_01: You can't do that.
30:37
SPEAKER_01: So anyhow, I think this is a chapter I have to warn people about.
30:40
SPEAKER_01: It's really easy to take this one in bad directions.
30:45
SPEAKER_01: It's kind of like a spice.
30:47
SPEAKER_01: They use tiny amounts of it in your cooking, and you get a good result.
30:49
SPEAKER_01: But if you use very much, you end up with a mess.
30:51
SPEAKER_00: Yeah, but I feel errors, exceptions, things going wrong.
30:57
They're one of the things that we don't really talk enough
31:00
about it when we think about design.
31:03
SPEAKER_00: When I look at outages,
31:05
SPEAKER_00: I remember a lot of outages that we had specifically at Uber,
31:08
SPEAKER_00: but even at other companies.
31:10
A lot of the times when we looked into what caused it,
31:12
it was like a mishandling of an error.
31:15
SPEAKER_00: It came from one system.
31:17
SPEAKER_00: We mapped it incorrectly as a success.
31:19
SPEAKER_00: And there was a lot of these edge cases which were,
31:22
SPEAKER_00: We misunderstood either errors or unexpected responses.
31:26
SPEAKER_00: You know, they're all the same thing.
31:27
SPEAKER_00: It was something with errors.
31:28
SPEAKER_00: And I think we struggled to put a finger on it.
31:30
SPEAKER_00: You know, we looked at ways of like, okay, let's map responses better.
31:35
SPEAKER_00: Let's have whitelists, let's have blacklists.
31:39
SPEAKER_00: During the planning phase, I don't really remember.
31:41
SPEAKER_00: I feel for planning,
31:43
SPEAKER_00: people tend to be optimistic of,
31:44
SPEAKER_00: here's how it works,
31:45
SPEAKER_00: here's how these things will communicate.
31:47
And I rarely recall planning sessions where we thought,
31:51
okay,
31:51
what could go bad?
31:54
SPEAKER_00: How will we catch it?
31:55
SPEAKER_00: How will we recover?
31:57
SPEAKER_01: So it's just- I think you make a good point in that I think people don't,
32:01
I don't think exception handling is top of people's mind when
32:06
they are doing the
32:06
SPEAKER_01: overall system design.
32:09
It just sort of happens tactically as people discover potential problems.
32:15
SPEAKER_00: Yes, I think you're putting what I'm trying to put as this observation.
32:21
SPEAKER_00: It's just a very interesting one.
32:23
So the one general piece of advice I have for people is that
32:27
when you're building a
32:28
module and thinking about what kinds of special cases and
32:32
exceptions you're going
32:33
SPEAKER_01: to export through your interface...
32:36
should think about how you think the callers are going to deal
32:42
with these and try
32:43
and put yourself in the mindset of the user as you're thinking
32:48
through these.
32:48
SPEAKER_01: And see,
32:50
SPEAKER_01: rather than having 10 different exceptions,
32:53
SPEAKER_01: there's only really two different ways people are going to handle this.
32:56
And so I can boil it all down into two kinds of exceptions
33:00
rather than 10 kinds of exceptions,
33:01
SPEAKER_01: for example.
33:04
So I think the key thing is to think about it from the caller's standpoint.
33:08
SPEAKER_01: By the way,
33:09
that brings me to what I think is one of the most important
33:13
attributes of a really
33:14
SPEAKER_01: good designer,
33:16
which is they can change their mindset and think about things
33:21
from very different
33:22
SPEAKER_01: point of views.
33:23
So when I'm designing a module,
33:26
I'm thinking about all of the details of that module.
33:29
SPEAKER_01: But then I can change my mindset to think about the user of this module.
33:34
SPEAKER_01: and realize I don't want to have any awareness of those details.
33:38
SPEAKER_01: And in particular,
33:38
SPEAKER_01: when I'm using a module,
33:40
I don't want to take advantage of things I might know about the
33:42
inside of that module.
33:43
SPEAKER_01: I only want to use things in the interface.
33:46
And so being able to shift your mindset and think about things
33:50
at one point,
33:50
but then completely put those out of your mind and take a
33:53
totally different view
33:55
SPEAKER_01: some other time,
33:56
SPEAKER_01: that's really powerful.
33:57
SPEAKER_01: That's how you come up with good designs, I think.
33:59
SPEAKER_01: Again,
34:00
SPEAKER_01: when you're designing something,
34:01
you can also think about it from the standpoint of somebody
34:04
that's going to be
34:05
SPEAKER_01: using it.
34:07
SPEAKER_00: Interesting.
34:08
So are you saying that having empathy and being able to put
34:14
yourself in the shoes
34:15
SPEAKER_00: of another role,
34:16
SPEAKER_00: may that be a customer,
34:18
SPEAKER_00: another developer,
34:20
SPEAKER_00: another developer who will be working on this,
34:23
SPEAKER_00: that could make us a better software engineer?
34:25
SPEAKER_00: I was about to say the word empathy.
34:28
SPEAKER_01: Yes.
34:29
What I was going to say is I think this skill set has
34:32
tremendous value in social
34:34
SPEAKER_01: context as well as in engineering context.
34:37
SPEAKER_01: The ability to think about things from some other person's viewpoint.
34:41
SPEAKER_01: By the way,
34:42
SPEAKER_01: one of the things I love about computer science,
34:45
SPEAKER_01: people think of us as these sort of geeky,
34:48
SPEAKER_01: nerdy people,
34:50
but many of the ideas that we use in computer systems actually
34:54
have interesting
34:54
SPEAKER_01: analogies in social systems as well.
34:57
SPEAKER_00: Yeah,
34:58
SPEAKER_00: it's just interesting because when I,
35:01
SPEAKER_00: you know,
35:03
SPEAKER_00: I'll start off like you on the software engineering journey,
35:06
SPEAKER_00: you know,
35:07
SPEAKER_00: start to learn to code,
35:08
SPEAKER_00: go to college,
35:09
SPEAKER_00: get my first job,
35:10
SPEAKER_00: et cetera.
35:11
SPEAKER_00: And initially I thought the hard part is the coding.
35:13
And every developer I talked to or every engineer I talked to
35:16
above a certain years,
35:19
we always have this discussion that the hardest part in
35:21
software engineering,
35:22
SPEAKER_00: computers and programming is the people.
35:24
SPEAKER_00: Yeah.
35:25
SPEAKER_00: You know,
35:25
SPEAKER_00: when we think back of after your first few years,
35:28
SPEAKER_00: once you get the syntax and you learn how to debug and those things,
35:31
SPEAKER_00: you think about what was the hardest project I was?
35:34
SPEAKER_00: What was the biggest problem?
35:35
SPEAKER_00: What caused me the most headache?
35:36
SPEAKER_00: And it's oftentimes miscommunication.
35:38
SPEAKER_00: You know, like we misunderstood each other.
35:41
SPEAKER_00: The spec was off, et cetera.
35:45
SPEAKER_00: Of course,
35:45
SPEAKER_00: there's outages as well,
35:46
SPEAKER_00: but usually the root cause is we did not expect this to happen.
35:50
SPEAKER_00: We didn't have the empathy for the user.
35:54
And the biggest one is conflicts with teammates,
35:59
with people that you work with.
36:01
SPEAKER_00: It's all human things.
36:03
SPEAKER_00: So it's interesting.
36:05
SPEAKER_00: There's this joke that the hardest thing in computer science are,
36:07
SPEAKER_00: I think,
36:08
SPEAKER_00: caching and naming things,
36:09
SPEAKER_00: but I will add people as well.
36:12
SPEAKER_01: Yeah, that sounds interesting.
36:13
SPEAKER_01: Yep.
36:15
SPEAKER_00: One thing that in your book you don't touch on,
36:18
SPEAKER_00: of course,
36:19
SPEAKER_00: the book cannot touch on anything,
36:20
but it's a practice that a lot of teams and tech companies use
36:24
is these things
36:24
SPEAKER_00: called design reviews and discussions.
36:26
SPEAKER_00: The idea is that someone before building a system will write down a plan.
36:31
SPEAKER_00: People will either have a meeting.
36:33
Amazon famously has this writing culture where people get into
36:37
a room and they read
36:39
SPEAKER_00: the plan and then they discuss.
36:40
SPEAKER_00: In other places, it's done with Google Docs.
36:43
SPEAKER_00: And even some others like Figma,
36:45
SPEAKER_00: they use their own tools to kind of like draw visuals and comment on it.
36:50
SPEAKER_00: What is your take of,
36:52
SPEAKER_00: before building a system,
36:55
SPEAKER_00: explaining a plan,
36:56
SPEAKER_00: either whiteboarding or other ways,
36:57
SPEAKER_00: and kind of criticizing each other's plans?
37:00
SPEAKER_00: Have you either done this to some of the things that you do?
37:03
SPEAKER_00: Do you encourage students in your class on design classes to do this?
37:07
SPEAKER_01: Oh, yeah.
37:08
SPEAKER_01: We do this certainly in all the projects I work on.
37:11
SPEAKER_01: And certainly when I was doing startups, we would do design reviews.
37:14
SPEAKER_01: They were relatively informal.
37:16
SPEAKER_01: We didn't have lengthy written documents.
37:19
SPEAKER_01: But we'd get together and talk about ideas.
37:22
And this is where,
37:23
again,
37:23
you get the multiple designs and you talk about the trade-offs.
37:27
SPEAKER_01: And it's just...
37:28
SPEAKER_01: If you can get multiple minds to think about a topic,
37:32
it's pretty clear you're going to come up with better ideas
37:35
than if just one person
37:36
SPEAKER_01: does it.
37:37
SPEAKER_01: Again,
37:37
this is an area where smart people sometimes have to get past
37:40
their history because
37:42
they've been for much of their life in environments where they
37:45
couldn't expect to
37:46
SPEAKER_01: get a lot of useful input from other people.
37:48
But when you're working at the very highest level with very,
37:50
very smart people,
37:52
you know...
37:54
SPEAKER_01: Two minds are better than one, clearly.
37:55
SPEAKER_01: So I'm all for it.
37:56
SPEAKER_01: Again, you don't want to get caught in analysis paralysis.
38:01
SPEAKER_01: And so trying to figure out what's the right place to do it,
38:04
SPEAKER_01: how much time to spend on it,
38:05
SPEAKER_01: there's a certain art to getting just the right level.
38:07
SPEAKER_01: But I'm all for that.
38:08
SPEAKER_01: Yeah.
38:10
And I think this might have changed in the last few years
38:12
because of remote work.
38:13
We've had an explosion of remote work,
38:14
and now it's a bit of a contraction.
38:16
SPEAKER_00: But I remember before 2020,
38:19
SPEAKER_00: some of the most innovative companies,
38:22
SPEAKER_00: when you went into their thing,
38:23
SPEAKER_00: or startups who were gaining momentum,
38:25
SPEAKER_00: what they had...
38:26
SPEAKER_00: is whiteboards and these erasable whiteboards everywhere.
38:30
SPEAKER_00: And what would happen in these places,
38:32
SPEAKER_00: actually,
38:32
I even had one of my older teams where we actually requested a whiteboard,
38:36
SPEAKER_00: is people,
38:37
SPEAKER_00: you know,
38:37
SPEAKER_00: you're just doing your thing.
38:39
SPEAKER_00: Someone says something, you're like, hold on.
38:41
And then you go to the whiteboard,
38:42
you start whiteboarding and,
38:44
you know,
38:44
you can erase it.
38:45
SPEAKER_00: Sometimes you leave it there.
38:46
SPEAKER_00: Sometimes you photograph it.
38:47
Basically,
38:48
it's just like on demand when there's a...
38:50
It could be any trigger.
38:51
SPEAKER_00: It could be just mishearing.
38:53
SPEAKER_00: It can be doing...
38:54
SPEAKER_00: You just have people come together,
38:56
SPEAKER_00: do their ideas,
38:57
SPEAKER_00: and there's something special about,
39:00
SPEAKER_00: there have been startups who try to replicate this digitally,
39:02
but there's something special about in-person just getting your
39:07
ideas out there,
39:08
especially when we're talking about something like software
39:10
where boxes and arrows
39:12
SPEAKER_00: do help.
39:13
SPEAKER_01: I totally agree.
39:14
SPEAKER_01: I love whiteboards and I like having meetings that are in person.
39:18
SPEAKER_01: I've also,
39:19
SPEAKER_01: over my career,
39:19
SPEAKER_01: developed a technique for using whiteboards to resolve complex issues,
39:25
SPEAKER_01: which may or may not even be technical,
39:27
SPEAKER_01: other kinds of management issues in a company.
39:30
And what I found is that oftentimes people get in meetings and
39:32
they just kind of
39:33
SPEAKER_01: talk past each other,
39:34
SPEAKER_01: repeat the same arguments and counter arguments.
39:37
And it just goes round and round and round and never reaches a conclusion.
39:41
So what I do in these situations is I stand at the whiteboard
39:46
and basically I list,
39:48
SPEAKER_01: typically we're arguing for or against something,
39:51
SPEAKER_01: just list all the arguments for and all the arguments against.
39:54
And the rule of the discussion is you can make any argument you
39:58
think is reasonable.
40:00
SPEAKER_01: No one is allowed to tell you your argument has to be removed.
40:03
SPEAKER_01: It's a bad argument.
40:03
SPEAKER_01: Every argument goes on the board.
40:06
But you are not allowed to repeat an argument that is already
40:09
on the board.
40:11
SPEAKER_01: And this is really important.
40:12
SPEAKER_01: So having the arguments up so everybody can see.
40:15
SPEAKER_01: Everybody's argument is valid.
40:17
SPEAKER_01: Everyone's allowed to contribute.
40:18
SPEAKER_01: No one can stop you from putting your argument on the board.
40:21
SPEAKER_01: So everybody's arguments goes up.
40:23
And then the discussion just naturally reaches a point where
40:25
nobody has anything more to say.
40:27
SPEAKER_01: And so this shortens the discussion.
40:30
SPEAKER_01: And then what I do after that is I take a straw poll.
40:33
SPEAKER_01: And what's amazing to me,
40:36
SPEAKER_01: you should try this sometime because it's really,
40:38
SPEAKER_01: it's quite shocking,
40:40
is that people will be arguing violently on both sides and
40:43
you'll think there's
40:44
SPEAKER_01: total disagreement.
40:46
SPEAKER_01: And then at the end,
40:47
SPEAKER_01: then we do a straw poll,
40:48
SPEAKER_01: you tell everybody,
40:48
you get to weight these arguments in any way that you think is appropriate.
40:52
SPEAKER_01: You decide which ones you value, which ones you don't value.
40:55
SPEAKER_01: Should we do A or B?
40:57
SPEAKER_01: we almost always end up with a really, really strong consensus.
41:00
SPEAKER_01: It's shocking.
41:01
Like I said,
41:02
I'll be in these meetings where I think we have total
41:04
disagreement here.
41:05
SPEAKER_01: And then we do the vote and poop, it's unanimous.
41:09
SPEAKER_00: Well, it sounds, I have not done it.
41:10
So it's,
41:11
you know,
41:11
it sounds one of those things where I don't believe,
41:13
I wouldn't believe you.
41:14
SPEAKER_00: I'm sorry.
41:14
SPEAKER_00: I do believe you.
41:16
But yeah,
41:16
as you said,
41:17
I think,
41:17
you know,
41:17
I'm going to try to try this out.
41:19
SPEAKER_00: It's the whiteboard.
41:19
SPEAKER_01: It's all about that whiteboard, I think.
41:22
Yeah,
41:22
and I think anyone listening or watching,
41:24
this is why I love these discussions.
41:27
SPEAKER_00: It's just like getting a tactic that you can try out.
41:29
And now that more and more companies are doing at least a few
41:34
days in the office,
41:34
SPEAKER_00: you get a whiteboard,
41:35
SPEAKER_00: try it out.
41:36
SPEAKER_01: By the way,
41:36
this works best in environments where people are first
41:41
generally pretty smart and
41:42
SPEAKER_01: reasonable and goal aligned.
41:43
SPEAKER_01: Like,
41:44
SPEAKER_01: you know,
41:44
SPEAKER_01: in a startup,
41:44
SPEAKER_01: for example,
41:45
SPEAKER_01: or an engineering team,
41:46
SPEAKER_01: you're typically goal aligned.
41:47
SPEAKER_01: You all want to achieve the same result.
41:49
SPEAKER_01: You know, would this work in Congress with opposing political parties?
41:53
SPEAKER_01: No, no, not in political environments.
41:56
SPEAKER_01: Fortunately, we don't operate mostly in those environments.
41:59
SPEAKER_00: Well,
41:59
SPEAKER_00: yeah,
41:59
SPEAKER_00: and I think,
42:00
SPEAKER_00: you know,
42:01
one nice thing about how the tech industry seems to be evolving
42:03
from my perspective
42:04
SPEAKER_00: is it's more and more common and accepted,
42:07
SPEAKER_00: even at large companies,
42:08
SPEAKER_00: that you do want teams to have clear goals,
42:10
SPEAKER_00: like have those goals,
42:11
SPEAKER_00: because if you don't have it,
42:12
SPEAKER_00: you know,
42:13
SPEAKER_00: everyone's going to go in different directions.
42:14
SPEAKER_00: So I think it's becoming more common.
42:16
SPEAKER_00: Also, companies don't do it.
42:17
SPEAKER_00: They fizzle out pretty quickly.
42:19
SPEAKER_00: Yeah.
42:20
SPEAKER_00: Similar question on design.
42:23
SPEAKER_00: There's two schools of thoughts when it comes to design.
42:26
One is let's design up front and the other one is let's not
42:28
design up front.
42:29
Let's just do prototyping or just build something and let the
42:32
code decide.
42:33
SPEAKER_00: Do you subscribe to either of these approaches?
42:36
SPEAKER_00: Taking time up front or just dropping into and prototyping?
42:39
Or have you seen times or types of projects where one just
42:43
works better than the other?
42:45
My personal belief is that design permeates the entire
42:49
development process.
42:50
SPEAKER_01: You do it upfront,
42:51
SPEAKER_01: you do it while you're coding,
42:52
SPEAKER_01: you do it while you're testing,
42:54
SPEAKER_01: you do it while you're fixing bugs,
42:55
SPEAKER_01: that you should constantly be thinking about design.
43:00
SPEAKER_01: I think you should always do at least a little bit of design upfront.
43:04
SPEAKER_01: Again, not waterfall method.
43:08
It's important to realize that our software systems are so
43:11
complicated that we are
43:13
SPEAKER_01: not able to predict the consequences of our design decisions.
43:17
SPEAKER_01: We simply can't.
43:18
But I think it's really important to do some design and to have
43:22
some hypotheses to work from.
43:25
SPEAKER_01: And then you start implementing.
43:27
SPEAKER_01: And of course,
43:27
SPEAKER_01: once you get in battle,
43:28
all your plans kind of fall apart and you'll discover lots of
43:31
problems with it.
43:32
And so you have to be prepared to revise as soon as you
43:35
discover problems.
43:36
SPEAKER_01: But if you don't do any design up front,
43:37
I think you're wasting your time on code that's just very
43:41
unlikely to be useful.
43:43
The only time I'd argue for coding without design is if you're
43:46
so young and
43:47
SPEAKER_01: inexperienced that you really have no clue how to do design.
43:50
SPEAKER_01: Then you may just have to write some code and start learning from it.
43:54
But in any case,
43:55
absolutely be prepared to redesign as you discover problems.
44:00
SPEAKER_00: Yeah.
44:01
SPEAKER_00: I had one of my colleagues a long time ago, many years ago.
44:05
He said something super interesting because we were talking
44:07
about why software is hard.
44:09
SPEAKER_00: And we were experienced engineers at this point.
44:11
Why do some projects take a lot longer even if we do proper
44:14
planning up front?
44:15
SPEAKER_00: Why are some projects actually pretty easy?
44:18
SPEAKER_00: And he said something interesting.
44:18
SPEAKER_00: He's like, software...
44:20
Like building software is a little bit like we're in a terrain
44:24
and we need to march
44:26
SPEAKER_00: to that location.
44:28
SPEAKER_00: We see the target, but the terrain is unknown.
44:31
SPEAKER_00: And sometimes you just walk there and it's exactly how you'd expect.
44:34
SPEAKER_00: Other times you're walking and oh,
44:36
suddenly there's a big kind of boulder appears out of nowhere
44:39
and you kind of climb
44:40
SPEAKER_00: over it.
44:40
SPEAKER_00: Then another one comes.
44:41
SPEAKER_00: Sometimes you walk and like a mine explodes right in front of you.
44:44
And suddenly you have this massive hole and you didn't know
44:47
this was a minefield.
44:49
SPEAKER_00: And he said,
44:50
and this analogy kind of resonated with me because I realized a
44:55
lot of it is about
44:57
SPEAKER_00: like how,
44:58
SPEAKER_00: how much unknowns are unknowns.
45:00
SPEAKER_00: And the approach is just very different, right?
45:02
Like if you're building a tech stack or product that you've
45:04
done before versus
45:06
SPEAKER_00: something that is completely new,
45:07
SPEAKER_00: if are using new technology,
45:09
SPEAKER_00: are using a beta version of a framework that could have issues,
45:12
SPEAKER_00: but maybe it'll work and so on.
45:14
Yeah,
45:15
I think a lot of it has to do whether you're in a domain you've
45:18
been in before or not.
45:20
SPEAKER_01: It's not that you got lucky and there was a flat field.
45:23
SPEAKER_01: I think it's more that,
45:24
SPEAKER_01: oh,
45:25
I've actually walked through this mountain range before and so
45:27
I know the right paths.
45:29
SPEAKER_01: And so,
45:30
SPEAKER_01: you know,
45:30
if you're building a driver for a new device and you've built
45:34
drivers for five
45:35
SPEAKER_01: devices before that,
45:36
SPEAKER_01: you kind of know what the main problems are and the process is much more
45:40
SPEAKER_01: predictable and smooth.
45:42
SPEAKER_01: If you're in a new environment...
45:44
SPEAKER_01: Well, I don't know.
45:45
SPEAKER_01: Maybe I'm just unlucky,
45:46
but I don't think I've ever had a smooth experience when I'm in
45:49
a new environment.
45:50
SPEAKER_01: It's just too hard to predict.
45:52
SPEAKER_00: Neither have I.
45:53
SPEAKER_00: The only kind of new environment,
45:55
SPEAKER_00: but it's not really a new environment,
45:56
like a new version of the framework and it's not a big change
45:59
or a new language release,
46:02
which is backwards compatible with all the important stuff and
46:05
you're not using the
46:05
SPEAKER_00: new features,
46:06
SPEAKER_00: that kind of stuff.
46:06
SPEAKER_00: But it's kind of fake, right?
46:07
SPEAKER_00: It's kind of the same as before.
46:12
SPEAKER_00: One thing I'd like to get into is the writing of this book.
46:15
SPEAKER_00: Because again,
46:16
SPEAKER_00: this book,
46:17
SPEAKER_00: it feels to me,
46:17
SPEAKER_00: it has just a lot of really kind of practical insights.
46:21
SPEAKER_00: Now,
46:22
SPEAKER_00: first of all,
46:23
I haven't seen many books written about software design or
46:26
software architecture specifically.
46:28
How did you get the idea to even start writing a book about
46:32
this pretty hard to tangle domain?
46:37
It's kind of a long process,
46:38
but the path leads through the course I taught at Stanford.
46:42
SPEAKER_01: So the background for this is, as I mentioned earlier, I love coding.
46:46
SPEAKER_01: I'm one of the few professors that still writes large amounts of code.
46:50
SPEAKER_01: I try to write 5,000 or 10,000 lines of code a year, at least.
46:52
SPEAKER_01: It's been a significant fraction of my time coding.
46:55
SPEAKER_01: And I love design.
46:56
SPEAKER_01: I think design is one of the most amazing, creative...
47:01
SPEAKER_01: forms that has ever existed in the history of humankind.
47:04
SPEAKER_01: It's just really fascinating, beautiful, challenging domain.
47:09
SPEAKER_01: And so I've often, I thought, think about it.
47:12
I try to think what is a good design and how do I get to,
47:15
how do I design software that's good?
47:16
SPEAKER_01: What are the techniques for that?
47:19
SPEAKER_01: But over time I noticed to my shock, nobody teaches it.
47:24
SPEAKER_01: Literally other than the course I eventually started at Stanford,
47:27
SPEAKER_01: I don't think there's a single course anywhere in the world
47:30
SPEAKER_01: where software design,
47:32
SPEAKER_01: not tools or processes,
47:33
SPEAKER_01: but the act of software design is the primary element of the course.
47:36
And so this just kind of graded on me for,
47:39
I don't know,
47:40
a decade or more.
47:41
SPEAKER_01: And once I got back to academia at Stanford,
47:44
SPEAKER_01: and now I'd had this experience in industry,
47:46
so I'd had a lot more software development experience and more
47:48
ideas myself,
47:50
SPEAKER_01: I started thinking about this,
47:51
SPEAKER_01: and I finally decided I'm just going to,
47:54
SPEAKER_01: who knows what's going to happen,
47:55
SPEAKER_01: but I'm just going to try teaching a course and see what I can do.
47:58
And so that forced me to start thinking about my ideas and try
48:01
and capture them in
48:03
SPEAKER_01: simple principles.
48:04
SPEAKER_00: You said no one teaches design.
48:06
SPEAKER_00: I'll tell you the perspective from someone working at a tech company.
48:12
Usually we don't interview new grads or people with a few years
48:16
of experience on
48:17
SPEAKER_00: software architecture topics.
48:18
Usually there's interviews coding and then software
48:20
architecture or design a complex system.
48:22
SPEAKER_00: And the reason being,
48:23
SPEAKER_00: well,
48:24
you need to work in the industry for several years to start to
48:27
get a sense for this thing.
48:29
SPEAKER_00: But I have a feeling you kind of, you know, you turned this upside down.
48:32
SPEAKER_00: You've kind of proven or,
48:34
SPEAKER_00: well,
48:34
you're attempting to do with the class that design can be
48:38
taught even for students
48:41
SPEAKER_00: who have recently learned to code.
48:44
What was your approach and what has your response been from the
48:47
people who've done it,
48:48
SPEAKER_00: especially now that,
48:49
SPEAKER_00: you know,
48:49
some of those folks have been out in the industry for years and
48:52
I'm sure they're
48:53
coming back with some of their experience because they now have
48:55
a skill set that,
48:56
SPEAKER_00: you know,
48:56
SPEAKER_00: a lot of their peers do not.
48:58
SPEAKER_01: Yeah, so I decided to teach this class.
49:00
SPEAKER_01: And then the question is, well, how do I teach it?
49:02
SPEAKER_01: And the model I used was my English writing classes from high school.
49:07
SPEAKER_01: I don't know if this is the way it's still done today.
49:08
SPEAKER_01: But back when I took English,
49:10
SPEAKER_01: the way you learn to write is you would get an assignment,
49:12
SPEAKER_01: you'd write something,
49:13
SPEAKER_01: your teacher would mark it up.
49:14
SPEAKER_01: And then you would rewrite it and submit it again.
49:16
SPEAKER_01: And you might do several iterations on it.
49:19
SPEAKER_01: And I think the key elements are first getting feedback.
49:23
SPEAKER_01: So you have somebody that can criticize your work.
49:27
SPEAKER_01: And then second, redoing to incorporate that feedback.
49:30
SPEAKER_01: And it's the process of redoing something,
49:33
SPEAKER_01: I think,
49:34
SPEAKER_01: where you really internalize the feedback and the concepts.
49:39
SPEAKER_01: So that's the way the class is taught.
49:40
SPEAKER_01: It's over a course of a quarter.
49:42
SPEAKER_01: People do basically three stages where they build something significant.
49:45
SPEAKER_01: And then we do extensive code reviews.
49:46
SPEAKER_01: For example,
49:47
SPEAKER_01: I read every line of code from all the teams in the class,
49:49
SPEAKER_00: which means that- And what do people build?
49:51
SPEAKER_00: What is the project?
49:52
SPEAKER_00: Or what was one of the projects?
49:54
SPEAKER_01: So actually,
49:55
the first two projects happen to be the Raft consensus protocol
49:57
divided up into two phases.
49:58
And that actually turns out to have some really interesting
50:01
design problems that
50:02
SPEAKER_01: confound students and lead to lots of mistakes.
50:04
So it's this process of,
50:06
and when they start off,
50:07
I give them no clues,
50:08
no hints,
50:09
no structure.
50:10
SPEAKER_01: They have to do it completely from scratch.
50:12
This is the first time in their lives they've ever done
50:14
anything like that.
50:15
SPEAKER_01: So it's actually both very fun and very scary for the students.
50:20
And then we do this extensive code review where they review it
50:23
in class and other
50:24
SPEAKER_01: students read their projects and give feedback.
50:27
And then I read every line of code and I spend about an hour
50:29
with each team.
50:30
They typically get 50 to 100 comments from me on their 2,000 to
50:34
3,000 lines of code
50:35
SPEAKER_01: they've written.
50:36
SPEAKER_01: And then they go back and they rework.
50:38
SPEAKER_01: And I think that's when the aha moments come from students,
50:41
SPEAKER_01: when they get the feedback from me where I can point out
50:45
SPEAKER_01: code that's complicated.
50:46
SPEAKER_01: People generally know that code is complicated.
50:48
SPEAKER_01: But then I can point out, here's why it's complicated.
50:50
SPEAKER_01: Because you didn't follow this principle that we've been talking about.
50:54
SPEAKER_01: And here's how, if you apply the principle, you can make it simpler.
50:59
And then they come back with their second projects,
51:01
and the second projects are so much better.
51:03
And you can tell the students are really excited because they
51:08
can kind of feel their power.
51:10
SPEAKER_01: They can feel that I was able to make this a lot better.
51:14
And so,
51:15
you know,
51:16
I was worried about how the students would react to the class.
51:18
SPEAKER_01: So it's an extremely positive experience for the students.
51:21
SPEAKER_01: You can tell over the course of the quarter,
51:23
SPEAKER_01: the way they think about software has changed really in significant ways.
51:27
SPEAKER_01: And actually, I warned them at the end of the quarter.
51:30
SPEAKER_01: I say,
51:31
SPEAKER_01: I just want to warn you,
51:31
SPEAKER_01: when you go into companies,
51:33
you're going to find you know a lot of stuff that people in the
51:35
companies don't know,
51:36
SPEAKER_01: even much more senior engineers.
51:38
So then we talk about how do you deal with that because as a
51:40
junior employee,
51:41
SPEAKER_01: you may not have much ability to change the company.
51:43
SPEAKER_01: But anyhow, so I totally, totally believe design can be taught.
51:49
SPEAKER_01: Now, you still need experience.
51:50
It's not like you're not going to be a world-class programmer
51:53
after one quarter in my course.
51:54
SPEAKER_01: Oh, yeah.
51:55
But I think they can start the process in motion and give you a
51:59
new way of thinking
51:59
about software that you've never thought about in your classes
52:02
up till now.
52:03
SPEAKER_00: Yeah,
52:03
SPEAKER_00: and I think you can probably,
52:04
SPEAKER_00: like,
52:05
SPEAKER_00: my sense is that the students who go through this class and,
52:09
SPEAKER_00: you know,
52:10
SPEAKER_00: they build up their experience.
52:11
SPEAKER_00: They also learn about themselves.
52:13
SPEAKER_00: They learn how they can challenge themselves, how they can talk about it.
52:18
SPEAKER_00: Other software developers take,
52:20
SPEAKER_00: you know,
52:20
SPEAKER_00: like when you enter the industry,
52:22
SPEAKER_00: like in the first few years,
52:23
SPEAKER_00: you're just going to like learn the hard way.
52:25
SPEAKER_00: Like I remember that when I was a new grad or a junior developer,
52:30
SPEAKER_00: you know,
52:30
SPEAKER_00: started out of college,
52:31
SPEAKER_00: right?
52:32
SPEAKER_00: I was actually still doing college,
52:33
but I was working at a workplace and a senior developer told me
52:37
I need to do this.
52:37
SPEAKER_00: You know, did the planning.
52:39
SPEAKER_00: We're going to use this technology.
52:40
SPEAKER_00: You need to implement this and this.
52:42
SPEAKER_00: And I just had a bad feeling about it, but I did it.
52:46
SPEAKER_00: And it just became worse and worse and more and more complicated.
52:49
And the solution that it was some in-house database and it had
52:53
performance issues,
52:54
SPEAKER_00: it got really bad.
52:56
SPEAKER_00: And the senior developers stepped away.
52:59
SPEAKER_00: And in the end...
53:01
SPEAKER_00: Weeks into the project,
53:02
SPEAKER_00: the customer is frustrated because like a page load took 15 seconds,
53:07
SPEAKER_00: which is like it's not it was not OK.
53:10
SPEAKER_00: And then I just like over a weekend, I worked.
53:13
SPEAKER_00: I must have worked for like, I don't know, 20 plus hours.
53:15
SPEAKER_00: I just rewrote the whole thing the way I would have done it.
53:19
SPEAKER_00: And it all of the things were fixed, etc.
53:21
SPEAKER_00: But.
53:23
It felt to me like I was kind of like,
53:25
I was thinking like,
53:26
am I being crazy?
53:27
SPEAKER_00: Like, like this experienced person told me to do this.
53:30
SPEAKER_00: I just didn't really have the vocabulary.
53:31
SPEAKER_00: I didn't have the, the faith in myself as well that, that I can do this.
53:37
SPEAKER_00: So, and yeah,
53:38
SPEAKER_00: Everyone goes through these things eventually, right?
53:40
SPEAKER_00: Like you kind of learn,
53:41
SPEAKER_00: you burn yourself,
53:42
but I feel you might be giving those students a bit of a
53:45
shortcut to maybe avoid
53:47
SPEAKER_00: some of these pitfalls.
53:49
SPEAKER_01: I suspect that experience was really good for you.
53:52
SPEAKER_01: Oh, it was really good, totally.
53:53
The opportunity to do it the wrong way and see your gut feeling validated.
54:00
So next time around,
54:01
you can probably kind of put some words to that and talk more...
54:07
SPEAKER_01: with more authority about why that's a problem,
54:10
and then going back and doing it the right way and seeing how
54:12
much better it is.
54:12
SPEAKER_01: I mean, that must have been a really great experience for you.
54:15
SPEAKER_00: The cool thing is that I think all these things are really good learning.
54:19
SPEAKER_00: Salvation through suffering, maybe.
54:21
SPEAKER_00: Yeah, but I feel sometimes that's the most memorable learning, no?
54:25
SPEAKER_01: Honestly, I think almost all learning is about making mistakes.
54:31
That the way you learn,
54:32
the most powerful ways to learn are to make mistakes,
54:37
SPEAKER_01: see, understand why there are mistakes and then fix them.
54:40
SPEAKER_01: And to me,
54:41
SPEAKER_01: education,
54:42
it's about basically creating a safe space where people can
54:46
make mistakes and learn
54:47
SPEAKER_01: from them.
54:48
SPEAKER_01: And I tell the students in the class about this.
54:50
I tell them,
54:50
you know,
54:50
you're going to get a tremendous amount of criticism.
54:52
SPEAKER_01: I tell them, I am going to pick every single knit with your coat.
54:57
SPEAKER_01: You're going to probably be mad at me for things I'm picking,
54:59
but I'm going to show you every single thing that's wrong
55:01
because I want you to be
55:02
SPEAKER_01: aware of that.
55:03
And one of the things I hope students get out of the class is
55:06
realizing that's a
55:07
SPEAKER_01: really productive experience.
55:09
SPEAKER_01: It's actually good for me to have people come in and challenge me,
55:12
SPEAKER_01: scrutinize my code,
55:13
SPEAKER_01: and give me feedback.
55:13
SPEAKER_01: Because I think a lot of developers out there are kind of sensitive.
55:18
SPEAKER_01: Maybe they worry that if somebody criticizes their code,
55:22
SPEAKER_01: maybe that means they weren't such a good coder.
55:24
Or maybe they think if I have to come up with a second idea,
55:27
maybe I'm not that smart.
55:29
SPEAKER_01: Only dumb people have to do things twice.
55:31
SPEAKER_01: Smart people always get things right the first time.
55:33
And so then you latch onto this,
55:34
I can't ever admit that my first idea isn't great.
55:37
SPEAKER_01: And so I think it's really important.
55:38
SPEAKER_01: The whole idea of making mistakes is so important and so constructive.
55:43
SPEAKER_01: We need to honor that, I think, as engineers.
55:47
slightly different topic but you and uncle bob robert martin
55:51
had an interesting
55:52
discussion about his book clean code online where you you you
55:55
both like wrote uh
55:58
your thoughts on different parts and there were a few parts
56:01
where you your opinions
56:03
diverged and i was interested in getting into some of these so
56:07
first was on short
56:09
SPEAKER_00: methods and the methods doing just one thing you know
56:12
SPEAKER_00: Robert Martin is a big fan of doing so.
56:15
He's saying this will lead to cleaner code,
56:17
clear responsibility,
56:18
and so on.
56:19
SPEAKER_00: And you had a slightly different take on this.
56:23
SPEAKER_01: Boy, I sure do.
56:24
SPEAKER_01: So I mentioned earlier on that design is about trade-offs.
56:28
And if you take any idea and take it to the extreme,
56:32
you end up in a bad place.
56:34
SPEAKER_01: And so I think clean code has done that in many places.
56:38
SPEAKER_01: This was my biggest overall concern.
56:41
SPEAKER_01: Method size is one of them.
56:43
SPEAKER_01: Of course,
56:43
I think we agree that really long methods are probably harder
56:47
to understand and
56:48
SPEAKER_01: deal with than shorter methods.
56:50
There's some value in shortness,
56:54
but it isn't the method length per se that's most important.
56:57
SPEAKER_01: To me, it's this notion of depth.
56:59
SPEAKER_01: Are we hiding complexity?
57:01
And so what happened in clean code is that shortness was taken
57:06
as an absolute good
57:08
SPEAKER_01: with no limits on it.
57:09
SPEAKER_01: The shorter, the better.
57:11
And so a three-line method is better than a five-line method,
57:14
according to clean code.
57:16
SPEAKER_01: And the problem with that is that
57:19
SPEAKER_01: Well,
57:20
SPEAKER_01: maybe that one method is a little bit easier to understand,
57:23
SPEAKER_01: but by having shorter methods,
57:25
SPEAKER_01: you now have a lot more methods.
57:27
SPEAKER_01: And so you have a lot more interfaces.
57:29
And now the complexity of the interfaces ends up actually
57:33
making the system more
57:34
SPEAKER_01: complicated than it was before.
57:37
SPEAKER_01: And in particular, his style...
57:40
SPEAKER_01: He is comfortable if methods are entangled,
57:44
SPEAKER_01: having multiple short methods where,
57:46
SPEAKER_01: in fact,
57:46
they're so entangled that you can't understand one method
57:50
without actually looking
57:50
SPEAKER_01: at the code of the other methods at the same time.
57:53
SPEAKER_00: Yeah, so this might as well.
57:54
SPEAKER_01: To me, I see no benefit of that.
57:55
SPEAKER_01: I think, to me, that has made things worse, not better.
57:58
That if things are really related,
58:00
you're better off pulling them together.
58:02
So the thing about the notion of depth is it kind of captures
58:06
the trade-offs.
58:07
SPEAKER_01: That we want to have a lot of functionality,
58:10
SPEAKER_01: but it needs to have a relatively simple interface.
58:13
And so I think that notion will keep you from going astray in
58:19
either one direction or the other.
58:20
SPEAKER_01: Whereas this,
58:21
SPEAKER_01: for example,
58:22
SPEAKER_01: the single responsibility principle,
58:25
SPEAKER_01: the do one thing principle,
58:26
that just pushes you relentlessly in one direction without any
58:29
bounds and you get
58:30
SPEAKER_01: in trouble that way.
58:32
SPEAKER_00: And it's interesting how you talked about methods being short,
58:38
SPEAKER_00: doing one thing,
58:38
SPEAKER_00: and you can have a lot of them,
58:40
SPEAKER_00: or you can group them and have bigger methods that do more things,
58:43
SPEAKER_00: but they're more sensible.
58:44
SPEAKER_00: I was thinking,
58:45
SPEAKER_00: as you're talking about this,
58:47
SPEAKER_00: in the industry,
58:47
SPEAKER_00: we've had a similar thing with microservices.
58:50
So I happened to work at Uber at the time where it was
58:52
popularized that the company
58:54
SPEAKER_00: had more than 5,000 microservices.
58:56
SPEAKER_00: And we had a lot of really small microservices.
58:58
SPEAKER_00: And what happened over the years is,
59:01
SPEAKER_00: at least in my,
59:02
SPEAKER_00: I cannot speak for the whole company,
59:03
SPEAKER_00: but I can talk about the domain I was,
59:04
SPEAKER_00: which was in the payments domain.
59:06
SPEAKER_00: We had a lot of small services because they were easy to spin up.
59:09
SPEAKER_00: They did like one thing or two things or a few things.
59:11
SPEAKER_00: And after a while, we realized like, huh, it's,
59:14
SPEAKER_00: It's just really tough to maintain,
59:16
SPEAKER_00: to know which lives there,
59:18
SPEAKER_00: a lot of communication back and forth.
59:19
SPEAKER_00: So we started to just pull them together and create,
59:21
SPEAKER_00: I would say,
59:23
SPEAKER_00: mid-sized services that kind of had a domain responsibility.
59:28
SPEAKER_00: And it wasn't either extreme, but I think we saw that one extreme.
59:32
SPEAKER_00: It sounds good.
59:33
SPEAKER_00: It sounded really good, by the way, initially, and it has benefits.
59:36
SPEAKER_00: But over time, it just wasn't as practical.
59:38
SPEAKER_00: So it's pretty...
59:39
somewhat similar to what to what you say like extremes on one
59:43
end are not great
59:44
it's not great to have like one massive service that does
59:46
everything you know we
59:48
uber used to have that it was called api and it did everything
59:51
and then it got
59:51
broken into smaller things and then it came back into like kind
59:54
of domains or
59:55
reasonably sized one so so you could actually keep track in
59:58
your head you could
59:59
understand here are the different parts that are there okay you
1:00:02
can go inside and
1:00:04
SPEAKER_00: then you can understand the part so there's i think there's a level of
1:00:08
SPEAKER_00: When does it make sense?
1:00:10
SPEAKER_00: How can you follow those kind of things as well?
1:00:12
SPEAKER_01: I think there's a,
1:00:13
SPEAKER_01: you know,
1:00:15
SPEAKER_01: again,
1:00:15
SPEAKER_01: you can err on both sides,
1:00:16
SPEAKER_01: but I think these days people often err on the side of over decomposing.
1:00:20
SPEAKER_01: And I think,
1:00:22
SPEAKER_01: so clean code,
1:00:23
SPEAKER_01: for example,
1:00:24
advocates that what I consider to be over decomposing that
1:00:26
causes problems.
1:00:28
And so one of the things I tell my students is often you can
1:00:32
make something deeper
1:00:33
SPEAKER_01: by actually combining things together.
1:00:36
SPEAKER_01: If they were closely related,
1:00:39
you may discover that if you bring them together into one class
1:00:41
or one method or
1:00:42
SPEAKER_01: one module or one subsystem,
1:00:44
you end up with the combined functionality but with a simpler
1:00:47
overall API and
1:00:50
without having two separate things with a lot of dependencies
1:00:52
between them,
1:00:52
SPEAKER_01: which is really bad.
1:00:54
SPEAKER_01: Again, you can overdo this.
1:00:57
SPEAKER_01: Everything is trade-offs,
1:00:58
but you can often make things better by making the units a
1:01:01
little bit larger.
1:01:02
Another area of disagreement was test-driven development that
1:01:06
we touched on a little bit.
1:01:09
SPEAKER_00: Robert Martin is a big fan of using TDD as a way to write code,
1:01:13
SPEAKER_00: write the test first,
1:01:14
SPEAKER_00: then write the code that makes it pass.
1:01:16
SPEAKER_00: This method was also pretty popular in the early 2000s.
1:01:20
SPEAKER_00: It's kind of gotten a little bit out of style.
1:01:22
SPEAKER_00: Your take was different as well.
1:01:25
SPEAKER_01: Yeah, I'm not a fan of TDD because I think it works against design.
1:01:30
SPEAKER_01: So again, to me, tests are important.
1:01:32
SPEAKER_01: I love unit tests.
1:01:33
SPEAKER_01: I write them for everything I do.
1:01:34
SPEAKER_01: They're essential.
1:01:35
If you're a responsible developer,
1:01:37
you write unit tests with very high coverage.
1:01:39
SPEAKER_01: So let's agree on that.
1:01:42
SPEAKER_01: But we want the development process to be focused on design.
1:01:45
I think that should be the center of everything we do in
1:01:48
development should be
1:01:49
SPEAKER_01: organized towards getting the best possible design.
1:01:52
And I think TDD works against that because it encourages you to
1:01:56
do a little tiny
1:01:57
SPEAKER_01: increment of design.
1:01:58
I write one test and then I implement the functionality to make
1:02:02
that test pass.
1:02:03
SPEAKER_01: Then I write one more test.
1:02:06
SPEAKER_01: and write the functionality to make that test pass.
1:02:08
There's no point in the process where you're encouraged to step
1:02:11
back and think
1:02:12
SPEAKER_01: about the overall task,
1:02:14
SPEAKER_01: the big picture.
1:02:16
SPEAKER_01: How do all these pieces fit together?
1:02:18
SPEAKER_01: What's the most pleasing,
1:02:19
SPEAKER_01: simple,
1:02:20
clean architecture that will solve 10 problems rather than
1:02:24
coming up with 10 point
1:02:26
SPEAKER_01: solutions to individual problems?
1:02:28
And so it results in what I believe the risk is you can end up
1:02:32
in an extremely
1:02:33
SPEAKER_01: tactical style of development that produces just a horrible mess.
1:02:37
SPEAKER_01: So that's my concern.
1:02:39
SPEAKER_01: And we had this long back and forth about it.
1:02:40
And I think the main reason that Bob likes TDD is it ensures
1:02:45
that the tests get
1:02:46
SPEAKER_01: written because you have to write the test before the code.
1:02:49
SPEAKER_01: And so I agree the test should be written.
1:02:51
But I don't think there's anything – he was not able to
1:02:53
convince me that there's
1:02:54
SPEAKER_01: any particular advantage
1:02:56
in writing the test before the code other than ensuring that
1:02:59
the tests get written.
1:03:01
SPEAKER_01: I can't see any reason that makes the design better.
1:03:03
SPEAKER_01: And I can see a lot of reasons why it might make the design a lot worse.
1:03:07
I think an interesting question is,
1:03:08
what should be your units of development?
1:03:10
SPEAKER_01: Development is always in chunks of work.
1:03:12
SPEAKER_01: What should those chunks be?
1:03:13
And I would argue those chunks should be abstractions,
1:03:17
not individual tests.
1:03:18
SPEAKER_01: That's too small of a chunk again.
1:03:20
SPEAKER_01: You want to think in a big enough chunk that you can consider trade-offs
1:03:26
and try and come up with a fairly general purpose solution that
1:03:29
will solve many problems.
1:03:32
SPEAKER_01: By the way,
1:03:33
SPEAKER_01: one of the most important elements of design,
1:03:36
SPEAKER_01: I think,
1:03:36
is pushing yourself towards general purpose to avoid
1:03:39
specialization as much as you
1:03:40
SPEAKER_01: possibly can.
1:03:42
And so the TDD approach encourages you to do something very
1:03:45
specialized to pass
1:03:46
each test rather than thinking about the general purpose thing
1:03:49
that solves many
1:03:50
SPEAKER_01: problems in one place.
1:03:51
SPEAKER_00: Oh, all right.
1:03:53
SPEAKER_00: Yeah, that is true.
1:03:54
SPEAKER_00: That is true.
1:03:54
SPEAKER_00: In fact,
1:03:55
I remember at some point when we did some TDD mobbing where we
1:03:59
would pass the
1:03:59
SPEAKER_00: keyboards around and someone would write a test,
1:04:02
SPEAKER_00: someone would make it pass.
1:04:03
It felt a bit artificial because when you wrote more code that
1:04:07
you needed to come,
1:04:08
SPEAKER_00: they're like,
1:04:08
SPEAKER_00: no,
1:04:09
SPEAKER_00: don't write that.
1:04:09
SPEAKER_00: That doesn't make, just make the test pass.
1:04:11
SPEAKER_00: So it almost felt a little bit of artificial.
1:04:14
SPEAKER_00: And again,
1:04:15
SPEAKER_00: I'm sure there are times and cases where it could be useful,
1:04:18
SPEAKER_00: maybe in a more formal way,
1:04:20
SPEAKER_00: maybe where it's more about adding,
1:04:23
SPEAKER_00: extending additional code where it's like very heavy in business logic.
1:04:26
SPEAKER_00: Maybe that could be a good fit, but...
1:04:30
There might be a reason that it kind of slowly became less
1:04:33
popular and we're not
1:04:34
SPEAKER_00: talking about it too much these days.
1:04:35
The one place where I'd recommend writing the test first is
1:04:40
when you're fixing a bug.
1:04:42
SPEAKER_01: I would argue write the test that will detect the bug and then fix it.
1:04:47
Although actually what I typically do is I honestly I kind of
1:04:50
cheat on this one.
1:04:52
SPEAKER_01: I write the fix and then I write the test for the fix.
1:04:57
SPEAKER_01: And then I back out the fix and make sure the test fails.
1:05:02
But anyhow,
1:05:03
that's one place where I think doing the test early can be useful.
1:05:08
SPEAKER_00: Now, one more area that you disagreed is comments.
1:05:11
So Uncle Bob says,
1:05:15
unsurprisingly,
1:05:16
that you should have as few comments in the code.
1:05:18
SPEAKER_00: The code should speak for itself.
1:05:21
SPEAKER_00: You also did not fully subscribe to this one.
1:05:24
SPEAKER_01: If the code could fully speak for itself, that would be wonderful.
1:05:27
SPEAKER_01: I would have no objection.
1:05:29
SPEAKER_01: But it can't, and it never will, as far as I'm concerned.
1:05:32
SPEAKER_01: There's just so much stuff that can't be described in the code itself.
1:05:37
SPEAKER_01: And we ended up discussing examples where he said, look at this code.
1:05:40
SPEAKER_01: It needs no comments, right?
1:05:41
And then I said,
1:05:43
well,
1:05:43
here's five questions people have that I don't see answered in
1:05:45
this code.
1:05:48
SPEAKER_01: Then he kind of hedged about that.
1:05:49
SPEAKER_01: I don't know.
1:05:52
SPEAKER_01: He's very, very biased against comments.
1:05:54
SPEAKER_01: I'm not sure why, if he has some scarring experience.
1:05:59
I believe he basically said he thinks that people lose more
1:06:04
time by being misled by
1:06:06
comments that are out of date than time lost because you
1:06:11
haven't had adequate comments.
1:06:13
SPEAKER_01: That certainly is not my experience.
1:06:16
SPEAKER_01: Occasionally there are comments that are out of date,
1:06:18
SPEAKER_01: but rarely and even then there's usually useful information.
1:06:22
SPEAKER_01: And then he also argued that,
1:06:24
SPEAKER_01: well,
1:06:24
SPEAKER_01: if you're working on a project that you and other developers work,
1:06:27
you don't need any comments because everybody's got it all
1:06:29
loaded into their minds.
1:06:31
SPEAKER_01: And I just don't agree with that.
1:06:33
SPEAKER_01: Now,
1:06:33
SPEAKER_01: maybe his mind is better than my mind,
1:06:35
SPEAKER_01: but,
1:06:36
SPEAKER_01: you know,
1:06:36
I can't keep everything in my mind that I forget code within a
1:06:39
few weeks of when
1:06:40
SPEAKER_01: I've written it.
1:06:40
SPEAKER_01: So I need those comments.
1:06:42
So the bottom line is there's just a lot of stuff that you
1:06:45
can't get from the code.
1:06:46
SPEAKER_00: And then what is your kind of approach on like, how do you do comments?
1:06:51
SPEAKER_00: What do you like to put into comments?
1:06:53
Or is it just like whenever you feel like it just put there
1:06:55
because it's going to
1:06:57
SPEAKER_00: be additional information that could help later?
1:06:58
SPEAKER_00: Yeah.
1:07:00
SPEAKER_01: Well,
1:07:00
SPEAKER_01: again,
1:07:01
the number one rule is comments should tell you things that
1:07:04
aren't obvious from the code.
1:07:08
SPEAKER_01: There are a lot of bad comments out there where people are basically just
1:07:11
SPEAKER_01: duplicating stuff that's obvious from the code.
1:07:13
SPEAKER_01: So no need for comments in those situations.
1:07:16
SPEAKER_01: In my student projects in my class,
1:07:18
SPEAKER_01: I often take comments out,
1:07:19
SPEAKER_01: tell students,
1:07:19
SPEAKER_01: this comment just repeats the code.
1:07:20
SPEAKER_01: You don't need it.
1:07:22
SPEAKER_01: I think where comments are most important is for interfaces.
1:07:25
SPEAKER_01: This is where they're really, really important because...
1:07:29
The assumption of interface is you don't want people to have to
1:07:31
read the code of
1:07:32
SPEAKER_01: the thing that you're communicating with,
1:07:35
SPEAKER_01: talking with.
1:07:35
SPEAKER_01: You just want to look at the interface.
1:07:38
It is impossible in the functional signatures of a module to
1:07:44
provide all the
1:07:44
SPEAKER_01: information people need to use that module.
1:07:47
SPEAKER_01: That's where comments are most important there.
1:07:49
SPEAKER_01: To me, that's the most important.
1:07:51
The second most important thing is documenting the member
1:07:54
variables of classes.
1:07:56
SPEAKER_01: That needs really extensive documentation.
1:07:58
SPEAKER_01: And then I tend to find that inside methods,
1:08:02
I don't tend to need a lot of comments because if you know what
1:08:05
the method's trying
1:08:06
SPEAKER_01: to do,
1:08:06
SPEAKER_01: the code typically speaks for itself pretty well there.
1:08:11
I tend to have comments where things are tricky or where there
1:08:13
was unexpected stuff
1:08:14
SPEAKER_01: I'd only discovered when there were bugs and things like that.
1:08:17
SPEAKER_01: But often my methods won't have any internal comments.
1:08:20
SPEAKER_01: They'll just be the interface comment.
1:08:22
SPEAKER_00: I think comments are going to have a bit of a resurgence of this debate,
1:08:26
SPEAKER_00: potentially,
1:08:27
SPEAKER_00: because AI tools increasingly generate more code.
1:08:30
SPEAKER_00: They often generate whole methods.
1:08:33
SPEAKER_00: And what I'm noticing is when I'm telling one of these AI assistants,
1:08:38
SPEAKER_00: like generate something that does this for me,
1:08:40
SPEAKER_00: it generates the code,
1:08:40
SPEAKER_00: but it often adds inline methods,
1:08:42
SPEAKER_00: which explains what it does.
1:08:44
SPEAKER_00: And actually,
1:08:45
SPEAKER_00: in that case,
1:08:45
SPEAKER_00: because it's just coming so quickly,
1:08:47
SPEAKER_00: it actually kind of helps me because I'm
1:08:50
SPEAKER_00: I know these tools hallucinate,
1:08:52
and I actually want to make sure what it does so it kind of
1:08:54
helps me understand.
1:08:56
SPEAKER_00: At the same time, it's a good question of why it's doing it.
1:08:58
SPEAKER_00: You know,
1:08:58
SPEAKER_00: these are trained on typically code that's out there,
1:09:01
SPEAKER_00: either open source or who knows what kind of licensing.
1:09:04
SPEAKER_00: So it probably is copying however it's seen it.
1:09:08
SPEAKER_00: But this,
1:09:10
SPEAKER_00: you know,
1:09:11
SPEAKER_00: usually I would agree with you,
1:09:12
SPEAKER_00: but in this case,
1:09:13
SPEAKER_00: maybe comments are not a bad thing.
1:09:15
SPEAKER_00: Who knows?
1:09:16
SPEAKER_00: It's an interesting area.
1:09:17
SPEAKER_01: Yeah, so I...
1:09:19
I'm a little hesitant to say this because I'm fearing I may be
1:09:22
justifying bad habits.
1:09:23
But one thing I found is that AI tools can,
1:09:28
to some degree,
1:09:29
compensate for the lack of comments.
1:09:31
So I've been working in the Linux kernel,
1:09:34
building a new network transport.
1:09:36
SPEAKER_01: And you know,
1:09:38
SPEAKER_01: Linux kernel is not a bad piece of software,
1:09:40
SPEAKER_01: but it's pretty significantly under commented in my view.
1:09:43
And I spent a lot of my time just trying to figure out what is
1:09:46
going on in Linux.
1:09:47
SPEAKER_01: What are the interfaces?
1:09:48
SPEAKER_01: How do I hook into this?
1:09:49
SPEAKER_01: ChatGPT has become my very best friend.
1:09:53
It's amazingly capable at answering questions about the Linux
1:09:57
kernel that I can't
1:09:58
SPEAKER_01: answer via Google search or any other way.
1:10:01
SPEAKER_01: It's not always correct.
1:10:02
SPEAKER_01: Sometimes it hallucinates, but it's often right.
1:10:05
SPEAKER_01: And even when it's wrong,
1:10:07
it typically gets me in the right vicinity and helps me to
1:10:10
figure out where to look
1:10:11
SPEAKER_01: to figure out how to answer my questions.
1:10:13
SPEAKER_01: So I think the AI tools may be able to help.
1:10:18
SPEAKER_01: But even saying that,
1:10:20
SPEAKER_01: if the Linux had just spent a little,
1:10:22
SPEAKER_01: a tiny amount of time putting comments in,
1:10:24
it would have made things so much easier than using ChatGPT to
1:10:28
try and figure it out.
1:10:29
SPEAKER_01: So I don't think the need for comments is going to go away completely.
1:10:33
And we shouldn't use AI tools as an excuse for people not to
1:10:36
write comments.
1:10:36
SPEAKER_01: At least not yet.
1:10:40
SPEAKER_00: So before the podcast,
1:10:41
one interesting thing that you mentioned is you are actively
1:10:44
writing code.
1:10:44
In fact,
1:10:45
after this podcast,
1:10:46
I think you're going to be getting back to writing code.
1:10:49
SPEAKER_00: What are you working on right now?
1:10:51
SPEAKER_00: You mentioned something with the Linux kernel.
1:10:53
SPEAKER_01: Yeah.
1:10:54
SPEAKER_01: So one of my PhD students,
1:10:56
SPEAKER_01: Ben Montessori,
1:10:57
SPEAKER_01: as his PhD dissertation six or eight years ago,
1:11:01
SPEAKER_01: developed a new transport protocol called HOMA,
1:11:03
SPEAKER_01: H-O-M-A.
1:11:05
SPEAKER_01: which is intended for use in data centers.
1:11:07
SPEAKER_01: And the results he got in his dissertation are really fabulous.
1:11:10
It's 10 to 100 times faster than TCP for a whole lot of
1:11:13
interesting cases.
1:11:15
SPEAKER_01: And so rather than let this just come and go as a
1:11:20
SPEAKER_01: PhD project that nobody ever cares about.
1:11:21
I've taken it as my own personal project to see if it is
1:11:25
actually possible to bring
1:11:26
this into widespread use and displace some of the TCP traffic
1:11:30
in data centers.
1:11:31
So I have developed a Linux kernel implementation of that,
1:11:34
which I'm continuing to enhance.
1:11:36
SPEAKER_01: And I'm now in the process of upstreaming that into the kernel.
1:11:40
And so actually what I'm really dealing with is a whole bunch
1:11:41
of comments I've
1:11:42
gotten from the Linux kernel developers about this and trying
1:11:44
to fix all the
1:11:45
SPEAKER_01: problems they pointed out.
1:11:46
SPEAKER_01: Here's another example of code reviews and the benefits of all of that.
1:11:50
SPEAKER_01: And indeed,
1:11:50
SPEAKER_01: this afternoon,
1:11:51
I'm getting ready to submit my next round of patches to the
1:11:55
NetDev mailing list.
1:11:56
SPEAKER_00: How are you finding,
1:11:57
is this your first contribution to a Linux kernel or have you
1:11:59
previously worked on it?
1:12:01
SPEAKER_01: Yeah, this is my first involvement with a Linux kernel.
1:12:04
SPEAKER_00: How are you finding the process?
1:12:05
SPEAKER_00: Because we just had an episode on Linux.
1:12:09
SPEAKER_00: with one of the main Linux kernel maintainers.
1:12:13
SPEAKER_00: And I'm curious, is it overwhelming?
1:12:16
SPEAKER_00: Is it easier?
1:12:17
SPEAKER_00: Is it harder than what you thought?
1:12:18
So I've been warned that it might be difficult and painful and
1:12:22
take a long time.
1:12:25
SPEAKER_01: It's taking a fair amount of time.
1:12:27
I think it's been,
1:12:29
we may be coming up on six months since I made my first
1:12:31
submission of this.
1:12:32
SPEAKER_01: But I have to say that the people have been very reasonable.
1:12:37
SPEAKER_01: And the feedback I've gotten has been high quality feedback.
1:12:40
SPEAKER_01: So I've had to fix a lot of things.
1:12:42
But these were all things where either I misunderstood
1:12:45
something about the kernel
1:12:47
or they show me better ways to do it or pointed out
1:12:50
complexities in my design,
1:12:51
SPEAKER_01: which there were plenty of.
1:12:53
SPEAKER_01: And so I have no objection to the process so far.
1:12:56
SPEAKER_01: And I'm actually pretty happy with it.
1:12:59
SPEAKER_01: And HOMA is getting a lot better because of this.
1:13:01
I hope will eventually reach closure and it'll find its way
1:13:04
into the kernel.
1:13:05
SPEAKER_01: But it has seemed pretty reasonable to me so far.
1:13:09
SPEAKER_00: This is really encouraging to hear and good luck with that.
1:13:13
What are ideas from the history of software design or even
1:13:16
software engineering
1:13:17
that you think might make a renaissance in the near future as
1:13:20
we're looking at
1:13:22
SPEAKER_00: focus on tooling,
1:13:22
SPEAKER_00: distributed systems,
1:13:24
SPEAKER_00: obviously AI tooling?
1:13:26
I'm not sure I can think of any idea that has come and gone and
1:13:30
is going to come back again.
1:13:31
SPEAKER_01: So I think,
1:13:34
SPEAKER_01: you know,
1:13:34
I think there are ideas that have come and gone because we've
1:13:37
learned how to do
1:13:38
SPEAKER_01: things better.
1:13:41
SPEAKER_01: But hopefully we're getting better and better at this.
1:13:44
SPEAKER_01: We're not just oscillating from good to bad, good to bad, back and forth.
1:13:47
SPEAKER_01: So I can't think of,
1:13:50
SPEAKER_01: there's no idea I can think of,
1:13:52
SPEAKER_01: you know,
1:13:52
SPEAKER_01: that people have forgotten about,
1:13:53
SPEAKER_01: wants to do and forgot about this,
1:13:54
SPEAKER_01: going to come back into play again.
1:13:57
And then the book,
1:14:00
this was first published in 2018,
1:14:02
so that's coming up seven years now.
1:14:05
SPEAKER_00: If you were to write this book today,
1:14:08
are there parts that you would add to it that you would rewrite
1:14:11
or even remove?
1:14:13
SPEAKER_01: Yeah.
1:14:14
SPEAKER_01: So first of all, I never actually finished the explanation of the book.
1:14:16
SPEAKER_01: So the book came about after the class.
1:14:18
When I started giving talks about the class,
1:14:19
people said,
1:14:20
you should write a book about this.
1:14:22
SPEAKER_01: And so I had a sabbatical in whatever it was, 2017, 2018.
1:14:25
SPEAKER_01: I used my sabbatical to write the book.
1:14:29
SPEAKER_01: So feedback on those.
1:14:30
SPEAKER_01: So first of all,
1:14:31
there have been some things where I've adjusted my opinion
1:14:34
since writing the book,
1:14:35
but there's already been a second edition of the book where I
1:14:37
fixed most of those.
1:14:40
SPEAKER_01: And the
1:14:41
SPEAKER_01: And hopefully the book you have is actually the second edition,
1:14:43
SPEAKER_01: in fact,
1:14:44
SPEAKER_01: if you've gotten it in the last couple of years.
1:14:46
SPEAKER_00: It is first edition.
1:14:47
SPEAKER_00: I need to update the book.
1:14:48
SPEAKER_00: OK.
1:14:49
SPEAKER_01: It has not changed dramatically.
1:14:51
But the biggest change is more emphasis on this notion of being
1:14:55
general purpose and
1:14:57
SPEAKER_01: eliminating specializations.
1:14:59
And that's something I learned actually not from the book but
1:15:01
from the class,
1:15:02
SPEAKER_01: from observing student projects in the class over a period of years.
1:15:05
I realized this idea is really fundamental to teaching students
1:15:09
how to write less
1:15:09
SPEAKER_01: complicated code.
1:15:11
SPEAKER_01: So that's already in the book.
1:15:14
SPEAKER_01: There's no big thing that I would want to change right now.
1:15:20
SPEAKER_01: As I mentioned earlier,
1:15:21
I think the part of the book that is most dangerous is this
1:15:26
part of exception handling,
1:15:27
SPEAKER_01: which,
1:15:27
SPEAKER_01: as I mentioned,
1:15:28
is easy for people to misinterpret and apply in ways that I
1:15:31
actually wouldn't agree with.
1:15:33
SPEAKER_01: So if I were rewriting the book from scratch –
1:15:38
I might think about that more carefully to make sure I choose
1:15:41
my wording more
1:15:42
SPEAKER_01: carefully to help people avoid misinterpretation of that.
1:15:46
SPEAKER_01: Now,
1:15:47
SPEAKER_01: one thing I hoped when I wrote the book,
1:15:49
one thing I was hoping was that people would come in with new
1:15:51
ideas that I hadn't
1:15:51
thought of and that I would learn from that and then get more
1:15:55
ideas and gradually,
1:15:56
SPEAKER_01: you know,
1:15:56
SPEAKER_01: I'd be adding more and more stuff to the book.
1:15:59
SPEAKER_01: So that has not happened very much so far.
1:16:03
SPEAKER_01: I would have been delighted to have more.
1:16:05
SPEAKER_01: I'd love for people to come and say, you are totally wrong.
1:16:08
SPEAKER_01: This idea here in the book is totally wrong.
1:16:09
SPEAKER_01: Here's why.
1:16:10
SPEAKER_01: Here's how you should do it instead.
1:16:11
And there's not actually been as much of that as I had actually
1:16:15
hoped for when I wrote the book.
1:16:18
I have a theory about why this might happen,
1:16:22
which is that your class is so unique.
1:16:25
SPEAKER_00: Software design in the wild is typically,
1:16:27
SPEAKER_00: you have a problem,
1:16:29
SPEAKER_00: you build a solution,
1:16:30
SPEAKER_00: you might explore some different trade-offs on the whiteboard,
1:16:33
SPEAKER_00: but then you build it,
1:16:34
SPEAKER_00: and then you move on,
1:16:35
SPEAKER_00: and then you might go back and fix it,
1:16:37
SPEAKER_00: you might have to maintain it,
1:16:38
SPEAKER_00: you're going to learn about it.
1:16:40
What you don't have is you don't have this ideal situation
1:16:43
where let's say you have
1:16:43
like two or three different teams building different things and
1:16:46
then you compare it
1:16:47
SPEAKER_00: because in the industry or in tech companies,
1:16:49
SPEAKER_00: you just don't have that luxury.
1:16:50
SPEAKER_00: And even if it's a bit wasteful.
1:16:54
SPEAKER_00: So you never really have a situation where you can repeat something.
1:16:57
SPEAKER_00: My sense was that with your class, you actually could do this.
1:17:00
SPEAKER_00: You could have a group of students go through.
1:17:03
SPEAKER_00: Well, actually in the class.
1:17:06
SPEAKER_00: Same problem, people solve it different ways.
1:17:08
SPEAKER_00: You can now see the differences, they can see the differences.
1:17:11
And I'm wondering if it's just a thing that maybe this setup
1:17:16
needs to happen in
1:17:17
SPEAKER_00: some level of either academia or nonprofit or somewhere where it is...
1:17:22
doable I'm not sure because I have been thinking of because
1:17:26
this this makes this
1:17:27
book really special like your observation was not just like a
1:17:30
lot of software
1:17:30
architecture books are like oh here's stuff that I found over
1:17:33
working on these
1:17:34
projects which are all one-offs but I learned these things and
1:17:37
you're saying I've
1:17:38
seen this thing work better across the students and those who
1:17:43
did it you know had
1:17:45
SPEAKER_00: better outcome repeatedly
1:17:47
Yeah,
1:17:47
that's something we can do in academia,
1:17:49
I think,
1:17:50
better than industry.
1:17:51
SPEAKER_01: Because in industry, you don't have time for the revision.
1:17:55
SPEAKER_01: And you're right.
1:17:55
One of the things about the class I think that is really good
1:17:58
is there are nine teams,
1:17:59
SPEAKER_01: nine two-person teams in the course.
1:18:01
SPEAKER_01: They all do the same projects.
1:18:05
SPEAKER_01: And then they review each other's projects.
1:18:07
SPEAKER_01: So during the code reviews,
1:18:09
SPEAKER_01: each student will read not the whole project,
1:18:12
SPEAKER_01: but a big chunk of two other projects and then review them in class.
1:18:16
SPEAKER_01: And so your partner is reviewing two different projects also.
1:18:20
So between the two of you,
1:18:21
you've seen basically half of the rest of the work in class.
1:18:25
SPEAKER_01: And I think that's also a really great source of learning from students.
1:18:27
SPEAKER_01: They really enjoy looking at each other's code and thinking about it.
1:18:31
SPEAKER_01: And then after the first project,
1:18:32
SPEAKER_01: they ask me,
1:18:32
SPEAKER_01: they say,
1:18:34
am I allowed to use ideas from this other project when I revise
1:18:37
my project?
1:18:38
Because normally in classes,
1:18:39
you can't use anybody else's ideas in your work.
1:18:41
SPEAKER_01: And I say, oh, absolutely.
1:18:43
SPEAKER_01: You are encouraged to steal and cannibalize all the best ideas.
1:18:47
SPEAKER_01: So that's something I think,
1:18:49
SPEAKER_01: yeah,
1:18:49
SPEAKER_01: where I think actually doing it in academia,
1:18:52
SPEAKER_01: we can probably do a better job in industry.
1:18:54
SPEAKER_01: In industry, you don't have enough time.
1:18:56
SPEAKER_01: You can't let a student,
1:18:57
SPEAKER_01: a person spend whatever it is,
1:18:59
SPEAKER_01: 15 hours a week for 10 weeks going through an exercise like this.
1:19:03
SPEAKER_01: You have too much other stuff for them to do.
1:19:06
SPEAKER_00: But the outcome has been really nice.
1:19:08
SPEAKER_00: So as closing,
1:19:10
what are one or two books you'd recommend for software
1:19:12
engineers to get better at
1:19:13
SPEAKER_00: their craft?
1:19:14
SPEAKER_00: Well, obviously, we have your book, but outside of these.
1:19:18
So unfortunately,
1:19:20
there's not a lot of other stuff out there that I really like.
1:19:24
SPEAKER_01: There are a couple of things.
1:19:25
SPEAKER_01: Unfortunately, I don't remember the names of them.
1:19:28
SPEAKER_01: But if people go to my homepage on the web and look,
1:19:31
SPEAKER_01: there's a link from there that will take you to the software design book.
1:19:34
SPEAKER_01: And there's a short web page there.
1:19:36
And that has some other recommendations at the bottom that
1:19:38
people can look at.
1:19:40
SPEAKER_00: We're going to link this in the show notes below.
1:19:43
SPEAKER_00: And how could listeners be helpful to you or help you?
1:19:46
SPEAKER_01: Well, I'm always interested in constructive criticism.
1:19:50
SPEAKER_01: I don't claim to have all of the answers.
1:19:52
SPEAKER_01: I have my experiences and things I think I've learned,
1:19:55
SPEAKER_01: but we're not done with software design yet.
1:19:59
SPEAKER_01: I'm sure there's a lot more to learn about that.
1:20:01
So I'd love to hear if people have ideas or if you think
1:20:04
something I say is wrong,
1:20:06
SPEAKER_01: I'd like to hear about it.
1:20:06
SPEAKER_01: I'd love to hear...
1:20:08
SPEAKER_01: What you think is wrong and why you think that's wrong.
1:20:11
SPEAKER_01: The main thing,
1:20:12
SPEAKER_01: you know,
1:20:12
SPEAKER_01: both in the class and in the book,
1:20:14
what I'm hoping to do is to encourage more awareness and
1:20:19
consciousness about
1:20:20
SPEAKER_01: software design in the developer community.
1:20:22
SPEAKER_01: Get people thinking and talking about it.
1:20:25
SPEAKER_01: And if we do that,
1:20:26
I'm hoping that we can raise the overall level of design in the
1:20:29
software that we build.
1:20:31
SPEAKER_00: Yeah,
1:20:31
SPEAKER_00: and I'm thinking,
1:20:33
especially now that we're going to see more code generated just
1:20:36
by nature.
1:20:36
SPEAKER_00: As you mentioned,
1:20:38
SPEAKER_00: design will be more important at all levels,
1:20:41
SPEAKER_00: not just like the senior engineering level,
1:20:43
SPEAKER_00: but as you're like creating your own thing.
1:20:45
SPEAKER_00: So hopefully we'll see more of this.
1:20:47
SPEAKER_00: Well, John, this was really nice and really interesting discussion.
1:20:51
SPEAKER_00: And thank you so much for spending your time on this.
1:20:53
SPEAKER_00: Thank you for inviting me.
1:20:54
SPEAKER_00: I really enjoyed the discussion as well.
1:20:56
SPEAKER_00: I hope you enjoyed this conversation as much as I did.
1:20:58
SPEAKER_00: Thanks very much to John for sitting down with us.
1:21:01
If you've not read his book,
1:21:02
A Philosophy of Software Design,
1:21:03
I can very much recommend it.
1:21:05
SPEAKER_00: For more in-depth reading on software design,
1:21:07
SPEAKER_00: design docs and related topics,
1:21:09
SPEAKER_00: check out the Pragmatic Engineer Deep Dives,
1:21:10
SPEAKER_00: which are linked in the show notes below.
1:21:13
SPEAKER_00: If you've enjoyed this podcast,
1:21:14
SPEAKER_00: please do subscribe on your favorite podcast platform and on YouTube.
1:21:18
SPEAKER_00: A special thank you if you also leave a rating.
1:21:20
SPEAKER_00: Thanks and see you in the next one.