Podcast: Uncle Bob Martin on Clean Software, Craftsperson, Origins of SOLID, DDD, & Software Ethics
MMS • RSS
Wes Reisz sits down and chats with Uncle Bob about The Clean Architecture, the origins of the Software Craftsperson Movement, Livable Code, and even ethics in software. Uncle Bob discusses his thoughts on how The Clean Architecture is affected by things like functional programming, services meshes, and microservices.
- Michael Feathers wrote to Bob and said if you rearrange the order of the design principles, it spells SOLID.
- Software Craftsperson should be used when you talking about software craftsmanship in a gender-neutral way to steer clear of anything exclusionary.
- Clean Architecture is a way to develop software with low coupling and is independent of implementation details.
- Clean Architecture and Domain Driven Design (DDD) are compatible terms. You would find the ubiquitous language and bounded context of DDD at the innermost circles of a clean architecture.
- Services do not form an architecture. They form a deployment pattern that is a way of decoupling and therefore has no impact on the idea of clean architecture.
- There is room for “creature comforts” in a code base that makes for more livable, convenient code.
- “We have no ethics that are defined [in software].” If we don’t find a way to police it ourselves, governments will. We have to come up with a code of ethics.
The principles in SOLID originated in a paper on design principles and patterns in 2002. Is that correct?
02:10 I think it was 2004 and Michael wrote me an e-mail, and said that if you rearranged the principles they spell SOLID.
02:30 That’s how the word SOLID arose – it turned out to be a good brand and worked out pretty well.
02:40 The principles are old; some are other people’s work – the open/closed principle and the single responsibility principle is Bertram Mayer’s work.
02:50 Barbara Liskov created the substitution principle.
03:00 Other principles I learned over the years and assembled into this batch of principles we now call SOLID.
You’re also known for coining the term “Software craftsmen”. How did that term come about?
03:10 I strongly identified with the term, but coining it isn’t something you should attribute to me.
03:20 I’m not sure that anyone could be credited with coining the term, but the first person to bring it to my attention was Pete McBrean in 2000 called “Software Craftsmenship”
03:35 In the book he described the difference between software as we currently experience it, and how it might be done under an apprenticeship/master model.
03:50 He talked about the Guild structures and the apprenticeship structures of older times.
03:55 He made the suggestion that maybe that’s how we should be doing software, as a tutored profession rather than an educated profession.
04:05 Since then, the term craftsmanship has come to mean the desire and ability to do a good job for your customer.
04:20 The craftsmanship movement is all about doing a good job and finding ways of working together to do the best job possible for your employers and customers.
How is the term evolving?
04:35 There has been a fair bit of fuss because the term has the word ‘man’ in it; we have this issue in software that is puzzling.
04:50 The number of women in this industry is ridiculously, absurdly low.
04:55 Even if you compare it to other STEM fields, we’re still an order of magnitude lower.
05:05 So there’s a deep sensitivity anything that genderizes.
05:15 I got into a discussion with Liz Keo, whom I have an extremely high regard for, and she made the point that anything that may be exclusionary we need to be careful about.
05:30 I wrote a blog post saying that I would avoid the word ‘craftsman’ when it’s being applied to a gender neutral way.
05:50 When we’re in a gender neutral context, I will use the term ‘craftsperson’ or ‘crafter’ or use the plural ‘craftsmen and craftswomen’
06:05 The term ‘crafstmenship’ is a powerful brand and so I wouldn’t want to change that.
There’s a blog post “The clean architecture” with a diagram of concentric circles; entities, use cases, controllers, devices, web and UI. What do you mean by those terms?
07:15 Entities are Jacob Ivenssen’s idea of business objects.
07:20 They are application independent business objects, usable within different applications.
07:30 So an order entry system and an order fulfilment system might have an ‘order’ entity, and might be the same across applications.
07:45 Use cases are application-dependent business rules.
07:55 The validation would go through there would go through there – all the automation would go there.
08:15 The next circle is things like gateways and utilities and the database and the UI and so on.
08:30 You start in the centre, and there are the highest level of components in the system.
08:35 As you move out it gets further and further away from the business and towards the automation process itself.
08:55 The lower level things are on the outside; the higher level things are in the centre.
09:00 The diagram shows four circles; that’s not a rue – a simple application might only have two circles.
09:10 A more complicated application might have six or seven, breaking up bubbles with different entities and use cases.
Can you explain about the dependencies?
09:30 Any dependency in the system must point inwards towards the business rules, no matter where it is.
09:40 If they’re crossing one of the circle boundaries, they’re crossing pointing towards the centre.
09:45 Dependencies are source code dependencies – the source code in those modules will depend upon each other and refer to modules inside, not outwards.
So you’d use dependency injection if you needed to point outwards?
10:15 You’d need some form of polymorphic interface, and dependency injection is one way of doing that.
10:25 Source code structure would be some kind of abstract class or interface.
How does it relate to domain driven design or bounded contexts?
10:45 Domain Driven Design is a wonderful book by Eric Evans from a long time ago.
10:50 He talks about creating the ubiquitous language of the business objects and the relationships between them.
11:00 You would find the innermost circle in the clean architecture would entirely surround the ubiquitous design driven development.
How does this apply to microservices?
11:40 It’s interesting to think about services in terms of architecture.
11:45 Services do not form an architecture; they form a deployment pattern: a decoupling.
11:50 There are different ways of decoupling – to have classes, for example.
12:00 We wouldn’t refer to classes as an architecture, and so we shouldn’t call services as an architecture.
12:05 If we’re using microservices, it’s a perfectly valid decoupling technique, but it has no impact on the idea of the clean architecture.
12:25 The clean architecture isn’t the implementation of how you do the decoupling; it is where you draw the lines and how you cross those lines.
12:35 We structure of the system in terms of the higher level business rules, the lower level business rules, the more implementation related stuff and so on.
12:45 You could have microservices that deal of nothing but business rules, or microservices that deal with interactions, or with GUI or databases.
13:00 They would fit in the circles, and you would manage the dependencies between them.
I fell into the monolith trap of thinking that this could describe a set of distributed microservices.
13:15 We are too hung up on this microservices idea.
13:25 It’s like dependency injection – it was a good idea, but we went way overboard with it.
13:35 Now we’re trying to do the cleanup – how much should we use with this stuff, how much shouldn’t we use.
13:40 The same is true with microservices – it has become the grand solution to any problem, and in another five years from now we’ll look back and find it didn’t solve that many problems.
What advantages does the clean architecture give you?
14:00 The highest level decisions are the ones that make (or save) the most money for the company.
14:05 The family jewels are buried down inside the centre bubble of the clean architecture.
14:15 Because all of the dependencies point inwards, changes at the outer levels cannot affect the inner levels.
14:20 Changes to the gui, database, framework can’t change or force recompilation of the business rules.
14:35 That’s really the goal – what do we want to protect, and what do we want to protect it from?
14:40 We want to protect the business rules from changes to the GUI.
14:50 We don’t want to recompile and retest all the business rules because somebody changes the font size in the GUI.
How does the clean architecture change with things like service meshes
15:30 I’m always skeptical of frameworks and tools that say they are going to answer all of the details.
15:40 They probably aren’t going to get rid of all of that; maybe at the service interaction they’re going to simplify a bit of that.
15:50 Where do these sit in the clean architecture? It’s all in the outer ring, in the implementation details.
16:00 The framework that would do the heavy lifting would be in some of the outermost levels of the circle.
16:05 That has a profound implication – it means that none of the circles inside can know about it.
16:10 It somehow has to do its work outside of its circle so that all the dependencies point inwards.
16:20 None of the inside modules can’t depend on the framework and know that it exists.
You wrote another blog post about Sara Kay’s livable code keynote. What appealed to you?
17:50 Her argument was that it’s where you want to live between the two extremes.
18:00 You can’t live healthily in a house that’s full of junk.
18:05 You also can’t live in a house that is in perfect order for a photoshoot.
18:15 A house that’s livable has certain local disorganisations to create convenient affordances.
18:35 You want the bag of pretzels on the table while you’re watching TV, even though the bag of pretzels doesn’t belong on the table.
18:50 Things like that happen in code – they ought to be temporary or transient.
19:00 On the other hand, we want certain conveniences that are ready to use.
19:10 It was a thought that I had never heard it put that way before.
19:15 It struck me that in my writings I had danced around the issue.
19:30 There’s always a slippery slope – if you say that your code should be livable, then people will make a horrible mess and claim that it’s livable.
19:40 We don’t want that – but we also don’t want sterile perfection.
Can you give an example?
19:50 Brett gave a paper a while ago called “Worse is better”.
19:55 He describes a well organised system that needs to be refactored.
20:05 The new feature won’t go in, as there’s no affordances to fit it in.
20:20 One technique is to take the structure that you had and undo it.
20:25 In this case, he’s talking about taking functions that had been extracted and inlining them again.
20:30 You do the work that you did to create the functions you had in the first place, and inline them all.
20:40 Then you can restructure it again with the feature in mind.
20:45 You might make a mess, in order to restructure and then clean it again.
20:50 There’s a bunch of different analogies you could use for this.
21:00 For example, in the clean architecture, the boundaries are tough and you can’t cross the boundaries in the right way.
21:15 Maybe it might be more convenient in certain circumstances if you didn’t perfectly separate the application independent business rules with the application dependent business rules.
21:35 You might say in that specific case, you might want the pretzels on the table.
Are there benefits to keeping the code inlined instead of cleanly separated?
21:45 There are corner cases – the embedded folks would raise their hands at this point, with nanoseconds to deal with.
22:00 If you’re in a resource constrained environment and function calls take time and stack space, then you may not have the ability to indulge yourself with function extractions.
22:10 What I would do is to do the function extractions anyway, and then time everything.
22:15 In cases where I was blowing real-time deadlines, I would start popping those function bubbles.
Where do you feel we are with ethics in software?
22:35 We have no defined ethics.
22:40 The great example of that is the Volkswagen fiasco of a few years ago.
22:50 The CEO of Volkswagen testified before congress.
22:55 The quote was “It was a couple of software developers who did this for whatever reason”
23:05 As weasely and as nasty as it was, it was true.
23:10 It was (probably more than) a couple of developers who did that.
The developers didn’t decide to do that – there was an endemic cultural problem, not a software developer issue.
23:30 It was an endemic cultural problem that was a lack of ethics.
23:40 It was both a lack of ethics at the business side, of course.
23:45 The developers did however write that code, for whatever reason.
23:50 I imagine them sitting there writing the ‘if’ … they knew what they were writing.
24:00 They crossed an ethical line.
24:05 You can argue that it was the manager’s fault – managers who went to jail should have gone to jail.
24:15 The developers however, crossed an ethical line – they should not have done that.
24:20 You can’t use an argument that “my job depends on me breaking the law”.
24:30 There’s no way to make that work – knowingly violating the law or ethics and using the fact that management told me to do it as an excuse.
24:45 That’s the state of our ethics.
So what do we do about this?
24:50 If we do nothing about it, then eventually an ethics will be imposed on us by law.
25:00 That will happen when a software person kills a bunch of people.
25:10 If we don’t want government to decide what our ethics is, we have to do it.
25:20 That’s what doctors and lawyers and plumbers did – they decided what ethics would be and started enforcing it internally.
25:30 That’s what we have to do – we have to come up with a code of ethics.
25:45 If you want to be a software developer in good standing then you have to adopt that set of ethics.
25:50 How we enforce that, I don’t know – do we create a board?
25:55 Something has to be done – otherwise we’re going to have laws passed about this by people who don’t necessarily understand the technology.
What are you working on now?
26:10 I’m working on an video series of teaching functional programming to those who don’t know about functional programs.
26:15 I’m using Clojure which sits on top of the JVM and looks a lot like lisp.
26:25 It’s functional and dynamically typed, which makes it easy to approach.
26:40 There’ll be a dozen or so looking at what a functional program is, what the tools are and so on.
How does the clean architecture work for functional programming?
27:05 It doesn’t shift at all – it remains the same.
27:10 The clean architecture requires some kind of indirection – that might be polymorphism in an object oriented language, or it might be a set of pointers to functions in a non-object oriented language.
27:30 People often make the assumption that functional programming and object oriented programming are mutually exclusive, which isn’t the case.
27:40 You can do object programming in a functional language, or you can do functional programming in an object oriented language.
27:45 The languages have to give you certain affordances, but you can mix the two modes.
27:55 Functional programming is programming without mutating state.
28:00 You can do that with objects that never change their state, and have methods which create new objects without changing any of the existing state.
28:15 You can have functional programs that use indirection and polymorphism just like objects too.
You have to be careful with mixing OO concepts and pure functions
28:35 If you mix in objects whose states change, that’s true.
28:45 That happens in Clojure, which sits on top of the JVM and they use objects whose state may change.
28:50 As long as those objects don’t change their internal state, it’s fine.
29:05 The two concepts fit together nicely.
The Clean Architecture
Craftsman, Craftswoman, Craftsperson
Domain-Driven Design: Tackling Complexity in the Heart of Software
Martin, Robert C. (2002). Agile Software Development: Principles, Patterns, and Practices
Martin, Robert C. (2009). Clean Code: A Handbook of Agile Software Craftsmanship
Martin, Robert C. (2011). The Clean Coder: A Code of Conduct for Professional Programmers
Martin, Robert C. (2017). Clean Architecture: A Craftsman’s Guide to Software Structure and Design
More about our podcasts
You can keep up-to-date with the podcasts via our RSS feed, and they are available via SoundCloud and iTunes. From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.