I am Robert C. Martin (Uncle Bob). Ask me anything.
Hey there, 👋
Most of you might know me as Robert "Uncle Bob" Martin from Cleancoder.
I am a software professional since 1970. I have spent the last 40 years contributing toward the betterment of the field, from kickstarting the Agile Alliance to authoring landmark books about Agile Programming, Clean Code, and more.
This is your opportunity to ask me anything regarding programming on Hashnode. I will start answering them live from 2 pm CST on 24th January.
What traits do you look for in engineers when hiring them?
Coding ability is nowhere near enough. Programers need to be good communicators. They need to be articulate, creative, caring, problem solvers. They need to be able to focus deep and long. They also need to be able to talk to business analysts, customers, and managers. They need to be able to see deep details, and also get the big picture. It's a tough mix of attributes to find.
S/W Engineering, Social Media, Webinars, Instructional Videos, Blogging
What do you think about “low code/no code” software-development tools that attempt to allow anyone to create business applications? Microsoft offers their "Power Platform", Salesforce provides "App Cloud/Lightning", Google has "App Maker" and there are many other offerings (Mendix, Appian, Quick Base, Outsystems, etc.). Recent news seems to hint that Amazon Web Services is getting ready to add their offering.
They make me laugh. It's an old problem. It's been tried many times. It never works quite the way people think it will. In the end, there will always be lots and lots of code.
Take great care that whatever platform you use allows you to write tests. One of the biggest failings of platforms like that is that they don't allow you to test what you write.
What does your daily life look like? How do you spend your free time?
I am a pilot, and am going for my instrument rating. Learning to fly well take a lot of time. It's also very rewarding.
I write a lot of code. I write books. I write articles, I write scripts for videos. I act in those videos. I review those videos.
I'm pretty busy most of the time.
When I have a free moment, I read, or play Minecraft.
I like watching Youtube videos about flying, or about science. I like PBS SpaceTime, and Veritasium, and Smarter Every Day. I also like conservative political podcasts.
I keep pretty busy.
And if there's nothing else left, I read science fiction.
Hi, what situation(s) have you found where it doesnt make sense to use TDD?
TDD is difficult to use in situations where you don't know the answer. It's hard to write a test when you don't know what to assert.
So, for example, GUIs. It's hard to write a test for a GUI because you don't really know what you want the screen to look like. Most of the time we fiddle around with the code. We mess with the CSS, and the HTML, we change font sizes, locations, margins, padding, colors, etc. Our eyeballs are the tests.
There are other areas of code that are like that. You don't know what you want the code to do. You have to fiddle with the code until it does something you recognize as "good".
This is a very small percentage of most projects. Most projects have vast suites of highly testable business rules, highly testable formatting rules, highly testable database rules, and a relatively few untestable GUI tweaks.
Hi Robert Our company will make a 5k marathon clean code running! next month, our tshirt in the back will have this "Best Practices Tips" to recommend.
- Apply a design pattern
- Follow code conventions
- Use meaningful names
- Comment your code
- Include unit testing
- Use Code revision tools
What do yo think about the suggestions!!
Great job with the clean code & architecture book!
Hi Uncle Bob,
How social are your unit tests, If your domain code has a few well defined public api methods but multiple modules that service these public api methods, would you drive all test coverage from the public api methods or test each module independently at their boundaries?
How about mocking and stubbing external calls which make test suites unpredictable. Clearly we should mock and stub, but how should we mock and stub, should we define gateway interfaces to abstract the explicit clients or mock the explicit clients directly. If gateway interfaces, should they be client specific or more generic and use case specific?
I try not to couple my unit tests to the lowest level code in the system. When I write unit tests using the TDD style, I try to simultaneously create an API that hides the lower level details from the tests.
These APIs are not public, per se. They are relatively low level interfaces used by other modules to access the code that is yet one level deeper. These little APIs keep my tests from becoming fragile.
I try to minimize the number of test doubles and mocks that I use. I mock across architectural boundaries, but within a component I tend not to mock much at all. In particular, I eschew the use of mocking tools. I find it easier, and better, to write my own mocks.
In regards to your “future of programming” talk. I have been seeking a body or licensure for a “commercial software developers licence”, analogous to a doctor or chartered account licence.
Do you know of any, and what are your thoughts on such a licence?
Do you see a software developers license being significantly different than that of other professions?
Is TDD applicable for projects that involve what's loosely termed "R & D" to revamp algorithms for an existing code base with the intent to assess viability for production release?
Of course. TDD is the discipline of stating what you intend to do, and then doing what you said you intended. This is extremely useful in an R&D environment because those tests may be the only thing that captures your actual intent.
Many people suggest that TDD should not be done in R&D because you don't know where you are going, and you don't know what the answers are.
While that's true at the macro scale, it's not at all true at the micro scale where TDD lives.
For example, say you are building a huge finite element simulator to study the airflow over a new airplane wing. You don't now what this simulator is going to tell you. But you do know the physical rules for air flowing across each finite element. So you can write the tests for those simple physical rules, and you can write them first in the TDD style. And you'd better, too. Because if you make a mistake in writing the code for those physical rules, you'll never know.
Indeed, many scientific papers have had to be recalled because simple bugs were found in the code of their models.
What to do with legacy code?
I have (almost) always have been part of the initiator group of developers of a product. It is the second time that I have to work on some inherited "thing" - some legacy. And I am not making any damn progress in any direction. Where to start? How to dismantle this thing into meaningful pieces? How to make "progress" - assuming it has any meaning in this context?
This is the hardest thing programmers can do. It's also the thing that most programmers spend their time on.
The trick is to understand that there is no easy solution. It took years to make the mess. It will take years to clean the mess.
So you simply have to begin. Very gradually, and very carefully, clean up the mess.
Do not turn this into a project. Do not tell your boss "We need 3 months to clean this up and then everything will be great". This project will fail, and you will never be trusted again.
Instead, follow the Boy Scout Rule. Every time you check the code in, check it in a bit cleaner than you checked it out. Do some random act of kindness to the code. Don't do too much, because the risk is too high. Just little tiny cleanups at every checking. And never, ever, EVER, check it in dirtier than you checked it out.
If you do this, and if everyone does this, then the code will eventually get better and better. Soon you'll find that parts of the code are decoupled enough to write some tests. The more tests you write the easier it will be to clean the code.
Read Michael Feathers' "Working Effectively with Legacy Code".
There are tons of really good books, but we all have a personal favorite. Which one is yours?
Kevlin Henney in his presentation Seven Ineffective Coding Habits of Many Programmers makes an interesting argument at 43:00. He argues that we should write test fixtures that test the entire class for specific example data, instead of writing tests for each method with their own little examples. What are your thoughts about this?
First of all I want to say a big THANK YOU for the impact your books did to my career!
I have several questions for you:
1 - Are you still interested in a new things, and if Yes, what are you studying at the moment? 2 - Could you please recommend some good books, not necessarily about Computer Science? 3 - Could you please tell something about how you conduct job interviews (if you still do that) and what are you looking for in a candidate (apart from tests, clean code, etc).
1 - Are you still interested in a new things, and if Yes, what are you studying at the moment?
Yes, but there aren't many truly new things nowadays. I like Clojure a lot. I like Event Sourcing structures a lot too. I like functional databases.
2 - Could you please recommend some good books, not necessarily about Computer Science?
You should read the "Bobiverse" trilogy. It's hysterical. goodreads.com/series/192752-bobiverse
3 - Could you please tell something about how you conduct job interviews (if you still do that) and what are you looking for in a candidate (apart from tests, clean code, etc).
I don't interview folks anymore. My favorite technique is to sit down and code with them for an hour or so. One company I know hires people as apprentices, and puts them through a multi-month probationary period during which they must study, write, and produce several challenge projects before they are allowed to work on real systems.
Hi Uncle Bob,
Firstly, your clean code videos have been invaluable in helping me become a more professional developer, thank you.
The Agile manifesto and development practices was revolutionary paradigm-shift for the software industry. I was wondering if you've thought about what the next revolutionary change in thinking that will move the industry forward might be like?
Don't you think the term "dependency inversion" is really far from accurate? There is no real "inversion" in it, the fact that the implementation class is usually drawn under the interface does not justify the name.
The name comes from the fact that the flow of control and the source code dependency oppose each other. Control flows from the caller to the callee. But the module containing the callee depends backwards towards the called interface.
-----flow of control--------->
I get the explanation. I'm risking to appear meticulous, but then it is either 'Reverse flow dependency' or 'partial dependency inversion'. Because 'dependency inversion' according to language semantic is about one object which has been inverted. But your description includes two objects - dependency and code flow - and, if we are talking only about dependencies, then only one of 2 dependencies is inverted.
The Clean Architecture appears to advocate an independence of 'feature laden' frameworks, for the business logic at the center of the circle. Then you look at any framework's tutorials (React comes to mind), and tasks like management of timeouts, and calls out through the boundary layer are demonstrated using the latest features of the framework. If it's Cleaner to not use your UI framework for state management, how come the tutorials are pointing you away from Clean?
The authors of frameworks are not architects. Their goal is to provide you with useful tools. They generally have no interest in the architectural structure of your system.
Take care. There are very many frameworks that tempt you to couple strongly too them. Often those couplings are so tight that there is no way to undo them. A good architect is careful about this and builds firewalls between business rules and frameworks.
Hi Uncle Bob :)
Will AI eventually replace developers?
I know that you already answered to this quiz in the past but I was wondering do you still think so?
No. Or at least not until we develop computer systems that have human-like intelligence.
Why? Because of what programmers do, and who programmers are. Programmers are detail managers. We break problems down into the tiniest of little details. Much tinier than our bosses or customers or stakeholders believe is possible or necessary. And each one of those details requires a decision that only a human can make.
Many folks have tried to build system that will make programmers obsolete. One of the first of these was COBOL. The goal of COBOL was to make programming so much like English that customers and stakeholders could write the functional specification, and then just execute it.
That didn't work. The demand for COBOL programmers grew quickly, and so did their salaries.
Since then folks have tried lots of other strategies. One of the latest was MDA (Model Driven Architecture). The idea was that customers, stakeholders, or business analysts could draw high level UML diagrams and execute them.
That didn't work. The amount of detail necessary to adorn those diagrams with required real detail managers to step in. Real detail managers are programmers.
So, no. AI will not replace programmers any times soon. Nor will AIs be driving cars through all our neighborhoods very soon; and for exactly the same reasons. Human judgement is required.
Hi Uncle Bob,
On most of the Clean Coders videos, you invite us into your home and give us the obligatory science lesson before discussing the topic at hand.
Was there a deliberate yet implicit suggestion that this is the kind of lifestyle you can have as a software engineer?
Nothing deliberate. Nothing implied. What you see is what you get.
I never got a degree. Never went to college. I started as a programmer in 1970 at the age of 18. I worked in COBOL, PL1, FORTRAN, and Assembler. I never looked back.
Now, 48 years later, all those years of experience provide me with the means to make a very comfortable living. But in the early days I lived paycheck to paycheck.
As my experience grew, so did my earnings, but then so did my family obligations. Keeping my head above financial water remained a challenge for over three decades.
I started a business. Employed a lot of people for a time. Don't let anybody tell you that that's a good way to make a lot of money. It doesn't work that way most of the time. Eventually the business failed and left me with very significant debt.
Now, late in life, I can relax a bit. But I don't want to. I love what I do, and I do it really well.
I only hope that all of you can be as happy as I am, and as happy I have been throughout my life as a husband, father, and programmer.
Hey Robert! Thanks for the AMA and please let me thanks you for your great book Clean Code ;)
Thanks again! 😋
Hi Uncle Bob,
Given that the term Object Orientation is so overloaded and given that you (and a lot of us) use a different, much more rigorous, definition than is generally accepted, do you think it's time to come up with a different name for this?
(UBP instead of OOP maybe :P)
Hi Uncle Bob,
It seems today that everybody and their mothers are adopting "micro-services" or service-oriented architecture. So, I would like to get your opinion on the use of this pattern.
Feel free to give your general thoughts, but I had these questions in mind:
- For the average org, is SoA successful more often than not and can successes or failures be directly attributed to SoA?
- Do you see SoA as a lasting trend?
Also, I want to thank you for taking the time to do this AMA! You're an inspiration to us all.
I’m working with EJB these days. But I’m mostly interested in Spring, Hibernation and other related stuff. I’m thinking of learning EJB more because it can help me to perform in my job. Do you think learning EJB could help me become a better programmer?