Slashdot Mirror
Book Review: The Clean Coder
CoryFoy writes "As someone who has been closely involved in both the 'agile software' movement as well as the 'Software Craftsmanship' movement, I have been following the work of Robert Martin for some time. So I was quite interested when I got my copy of his latest book Clean Coder where he 'introduces the disciplines, techniques, tools and practices of true software craftsmanship.' Would his book live up to being a guide for the next generation of developers, or would it go on my shelf as another interesting book that I had read, once?" Read below for the rest of Cory's review.
The Clean Coder: A Code of Conduct for Professional Programmers
author
Robert C. Martin
pages
256
publisher
Prentice Hall
rating
5 Nebulous Rating Units
reviewer
Cory Foy
ISBN
978-0137081073
summary
A good overview of the current agile practices for software developers
Before even getting into the book, it is good to know the style of Robert Martin, affectionately known as "Uncle Bob" to many people. Bob is a former preacher who comes at life — and topics he teaches — with a no-holds-bar approach. So when he approaches topics such as "Professionalism" and the software industry, I come expecting passionate discussion and serious assertions. The Clean Coder is no exception.
The book starts off with an overview of the Challenger space shuttle disaster. As a native Floridian who could see shuttle launches from my house (and, in fact, saw the Challenger explode just as it crested the trees from where we lived) this really resonated with me. The accident was a result of engineers saying no, but management overriding the decision. With this introduction, Bob makes it quite clear that when we choose not to stand up for that which we believe, it can have dire consequences.
We then dive right in, starting with the topic of Professionalism. The assertion is made that the key to professionalism is responsibility — "You can't take pride and honor is something you can't be held accountable for". But how do we take and achieve responsibility? Chapter one lays out two ways. To start, it looks at the Hippocratic Oath, specifically the rule of "First, Do No Harm". The book maps this to software by saying to do no harm to function or structure, ensure that QA doesn't find anything, know that your software works, and have automated QA. In fact, when I work with teams, I teach them that if your testing "phase" finds bugs, it's a problem with your process that needs to be addressed immediately, so the concept of ensuing that QA doesn't find anything is a great concept to bring out.
Then we move on to Work Ethic — specifically around knowing your field. This means continuous learning, practice (through things like Katas and Dojos), collaboration, mentoring, identifying with your employer/customer, and practicing humility. To help with that, Chapters 2 and 3 talk specifically about saying "No" and "Yes". When we say no, and when we want to say no, we should mean it. Saying, "We'll try" means that you, or your team, isn't already giving it their best, and that through some extraordinary effort you'll pull it off. Say no and stick to it. But, when you say Yes, mean it. People are counting on you to be truthful with them.
Chapters 4, 5, and 6 begin to talk about the specific practices of coding. Chapter 4 talks about the coding process itself. One of the hardest statements the book makes here is to stay out of "the zone" when coding. Bob asserts that you lose parts of the big picture when you go down to that level. While I may struggle with that assertion, I do agree with his next statement that debugging time is expensive, so you should avoid having to do debugger-driven development whenever possible. He finishes the chapter with examples of pacing yourself (walking away, taking a shower) and how to deal with being late on your projects (remembering that hope is not a plan, and being clear about the impact of overtime) along with a reminder that it is good to both give and receive help, whether it be small questions or mentoring others.
Chapters 5 and 6 cover Test-Driven Development and Practicing. The long and short is that TDD is becoming a wide-spread adopted practice, in that you don't get as many funny looks from people when you mention TDD as you once did. And that coding at work doesn't equal practicing your tools and techniques — instead you should set aside specific time to become better through coding exercises, reading and researching other areas (languages, tools, approaches), and attending events and conferences.
Chapters 7 and 8 cover testing practices. In Chapter 7 the book looks at Acceptance Tests and the cycle of writing them — specifically at what point the customer is involved (hint: continuously) and how to ensure they stay involved. Chapter 8 goes to more of the unit testing level, and defines some strategies and models for looking at unit testing, including an interesting "Test Automation Pyramid"
Now that we've covered the developer herself, coding and testing, the book moves on to discussing time. Chapter 9 covers Time Management strategies — staying out of "bogs" and "blind alleys", using techniques like the "Pomodoro" technique to create focus, and the law of two-feet — if you are in a meeting and aren't getting value out of it, you should feel free to (respectively) leave, or otherwise modify the meeting to get value from it.
Chapter 10 covers several different methods of estimation. In the teams I work with, estimation is perhaps one of the hardest things — not because estimating can be hard (which it can be) but because either they are held so tightly to the estimates that they are afraid to make them, or, worse, they are told what the estimates are going to be. The book really only skims the surface here, covering several techniques from Planning Poker, to PERT, to "Flying Fingers", but gives a decent overview of how to do those techniques.
Rounding out the discussions of time comes Chapter 11 and talking about Pressure. The key of this chapter is that because you have committed to your principles, practices and disciplines, you should be able to stay calm under pressure. I can certainly say from experience that the worst experiences in my career are when people weren't able to stay calm, and the way the book is laid out, if you are following the practices outlines so far, you should be able to be the voice of reason and calmness.
The last three chapters cover teams and collaboration. Chapter 12 talks about important practices such as shared code ownership, pairing, and respect for other team members. Chapter 13 covers teams and the importance of having teams that gel together. The book finishes with Chapter 14 and discussions of the importance of apprenticeship, mentorship and craftsmanship.
As I mentioned earlier, I've been involved in the "agile" movement for quite some time, and have spoken with Bob on many occasions, so many of the practices in the book weren't new. I did quite appreciate the stories he had to tell about his experiences. However, I think that some people may be turned off by the hard line around "professionalism". Sometimes you do need to say no, and I think it is good to have encouragement from a book to do that. But sometimes things are more complex, and I think that you would have a harder time looking to this particular book for help with the edge cases.
In conclusion, I think this is a book which provides worthwhile information and an interesting look at how people are looking at software development as a profession. If you read between some of the hard lines made, there are some great nuggets to be gleaned from the book for software developers of any level.
You can purchase The Clean Coder: A Code of Conduct for Professional Programmers from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
The book starts off with an overview of the Challenger space shuttle disaster. As a native Floridian who could see shuttle launches from my house (and, in fact, saw the Challenger explode just as it crested the trees from where we lived) this really resonated with me. The accident was a result of engineers saying no, but management overriding the decision. With this introduction, Bob makes it quite clear that when we choose not to stand up for that which we believe, it can have dire consequences.
We then dive right in, starting with the topic of Professionalism. The assertion is made that the key to professionalism is responsibility — "You can't take pride and honor is something you can't be held accountable for". But how do we take and achieve responsibility? Chapter one lays out two ways. To start, it looks at the Hippocratic Oath, specifically the rule of "First, Do No Harm". The book maps this to software by saying to do no harm to function or structure, ensure that QA doesn't find anything, know that your software works, and have automated QA. In fact, when I work with teams, I teach them that if your testing "phase" finds bugs, it's a problem with your process that needs to be addressed immediately, so the concept of ensuing that QA doesn't find anything is a great concept to bring out.
Then we move on to Work Ethic — specifically around knowing your field. This means continuous learning, practice (through things like Katas and Dojos), collaboration, mentoring, identifying with your employer/customer, and practicing humility. To help with that, Chapters 2 and 3 talk specifically about saying "No" and "Yes". When we say no, and when we want to say no, we should mean it. Saying, "We'll try" means that you, or your team, isn't already giving it their best, and that through some extraordinary effort you'll pull it off. Say no and stick to it. But, when you say Yes, mean it. People are counting on you to be truthful with them.
Chapters 4, 5, and 6 begin to talk about the specific practices of coding. Chapter 4 talks about the coding process itself. One of the hardest statements the book makes here is to stay out of "the zone" when coding. Bob asserts that you lose parts of the big picture when you go down to that level. While I may struggle with that assertion, I do agree with his next statement that debugging time is expensive, so you should avoid having to do debugger-driven development whenever possible. He finishes the chapter with examples of pacing yourself (walking away, taking a shower) and how to deal with being late on your projects (remembering that hope is not a plan, and being clear about the impact of overtime) along with a reminder that it is good to both give and receive help, whether it be small questions or mentoring others.
Chapters 5 and 6 cover Test-Driven Development and Practicing. The long and short is that TDD is becoming a wide-spread adopted practice, in that you don't get as many funny looks from people when you mention TDD as you once did. And that coding at work doesn't equal practicing your tools and techniques — instead you should set aside specific time to become better through coding exercises, reading and researching other areas (languages, tools, approaches), and attending events and conferences.
Chapters 7 and 8 cover testing practices. In Chapter 7 the book looks at Acceptance Tests and the cycle of writing them — specifically at what point the customer is involved (hint: continuously) and how to ensure they stay involved. Chapter 8 goes to more of the unit testing level, and defines some strategies and models for looking at unit testing, including an interesting "Test Automation Pyramid"
Now that we've covered the developer herself, coding and testing, the book moves on to discussing time. Chapter 9 covers Time Management strategies — staying out of "bogs" and "blind alleys", using techniques like the "Pomodoro" technique to create focus, and the law of two-feet — if you are in a meeting and aren't getting value out of it, you should feel free to (respectively) leave, or otherwise modify the meeting to get value from it.
Chapter 10 covers several different methods of estimation. In the teams I work with, estimation is perhaps one of the hardest things — not because estimating can be hard (which it can be) but because either they are held so tightly to the estimates that they are afraid to make them, or, worse, they are told what the estimates are going to be. The book really only skims the surface here, covering several techniques from Planning Poker, to PERT, to "Flying Fingers", but gives a decent overview of how to do those techniques.
Rounding out the discussions of time comes Chapter 11 and talking about Pressure. The key of this chapter is that because you have committed to your principles, practices and disciplines, you should be able to stay calm under pressure. I can certainly say from experience that the worst experiences in my career are when people weren't able to stay calm, and the way the book is laid out, if you are following the practices outlines so far, you should be able to be the voice of reason and calmness.
The last three chapters cover teams and collaboration. Chapter 12 talks about important practices such as shared code ownership, pairing, and respect for other team members. Chapter 13 covers teams and the importance of having teams that gel together. The book finishes with Chapter 14 and discussions of the importance of apprenticeship, mentorship and craftsmanship.
As I mentioned earlier, I've been involved in the "agile" movement for quite some time, and have spoken with Bob on many occasions, so many of the practices in the book weren't new. I did quite appreciate the stories he had to tell about his experiences. However, I think that some people may be turned off by the hard line around "professionalism". Sometimes you do need to say no, and I think it is good to have encouragement from a book to do that. But sometimes things are more complex, and I think that you would have a harder time looking to this particular book for help with the edge cases.
In conclusion, I think this is a book which provides worthwhile information and an interesting look at how people are looking at software development as a profession. If you read between some of the hard lines made, there are some great nuggets to be gleaned from the book for software developers of any level.
You can purchase The Clean Coder: A Code of Conduct for Professional Programmers from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Back when I was getting my CS degree, I've always noticed that the cleanest coders are also the guys who didn't shower for days at a time and always wore the same clothes.
My postings are informational and does not constitute legal advice. Act on it at your risk.
Programming--You're doing it all wrong!
SJW: Someone who has run out of real oppression, and has to fake it.
Fair enough comment. I do add my viewpoints on the section, and summarize it at the end. I find most books I read can't be summarized nice and tidy at the beginning, but instead need some background throughout. This book is especially true of that, because it's like a collection of short essays more than one contiguous writing.
"Agile" programming is when you stop looking surprised and outraged when the customer changes the project requirements on you every few days.
In fact, when I work with teams, I teach them that if your testing "phase" finds bugs, it's a problem with your process that needs to be addressed immediately, so the concept of ensuing[sic] that QA doesn't find anything is a great concept to bring out.
Given the number of mistakes in this sentence, along with the pompous notion that process can somehow prevent logical errors, makes me very glad I don't work with, much less for, you.
(If you code for NASA, perhaps you have the luxury of a process that does prevent logic errors. Somewhere around 99.9999999999% of us do not.)
The waterfall-agile axis in software development is doing to go away as soon as the left-right axis in politics does. On the extreme left (or right, I don't really want to this to have any political meaning) you have strict waterfall, a single flow down exclusive phases. Then as you move right you have more overlaps, several delivery phases and so on. Eventually you get to agile, where you re-prioritize, redesign, code and test in very short sprints. And on the right of that you have cowboy coding, where you've given up all pretense of cycles and just do it all at once. Are any of them "right"? Probably not. Some things will require more planning, some things less depending on the project. And some claim their solution is the solution to everything. And if that there's problems with it, that's because they're not doing it right or not doing it extreme enough. The most avid agile zealots remind me a little of libertarians, if the free market isn't working it's because it's not free enough. And if the agile project has problems, it's because it's not agile enough. There's no problem that can't be solved by greater ideological purity.
Live today, because you never know what tomorrow brings
The problem is the inability of consumers or managers to understand the 3 part rule. Speed, Quality, Cost, pick two.
I think the best analogy for this is furniture.
Mennonites make great furniture. It takes a long time, and is very expensive. It is a craft, and they are craftsmen.
IKEA makes some pretty shitty furniture but is good enough for many applications. It is cheap, and fast.
What most consumers and managers want, is the quality and hand craftsmanship of the Mennonites, at the speed and cost of IKEA.
Problem is, that is impossible for the most part, particularly when you start looking at very large scale applications. So when managers hire people they want the IKEA drones, and expect them to produce Mennonite quality very quickly. Bottom line is short cuts are taken, managers "risk manage", and in the end you get buggy code that is not clean at all. Particularly when you have a work force that is treated like replaceable parts, in many cases you are dealing with someone else's mess, why should you try and code cleaner?
Anyway, none of this is new, and I am sure on small applications were individuals have more control, cleaner code is possible, however in the corporate world, given the outlook by most, I can see it being problematic.
Being a manager, I am learning to hate the phrase "clean code". It seems to be a preoccupation with how code looks whilst being a distraction from what it does.
I think you underestimate just how much I just dont care.
I've worked at 3 different companies of all sizes in the past 8 years. Every one claimed to be Agile, every one one of them produced undocumented spaghetti code that collapsed under the slightlest change request.
"Agile" unfortunately has become an excuse for no plans, no docs and no discipline.
Therefore, having never been employed in a real Agile environment, what about Agile lends itself to be abused this way?
Programming--You're doing it all wrong!
I know you're going for +5 funny...
But what I read is "Here's some things that might be useful."
The review was well written and I appreciated the reviewer's comments on what they found interesting.
Sure, tech-skills are important.
But what a lot of programmers miss is that the other topics (estimates, integrity, responsibility) are important.
Maybe if you work on solo projects your entire life, then it doesn't matter so much.
But social interactions really are big deal in software, just like they are with every other human endeavor.
(The more cynical slashdotters would s/social interactions/politics/ and they wouldn't be wrong, but that doesn't make it any less relevant.)
Suppose somebody develops software professionally (e.g. for money).
What will help their career more: adding another language to their resume?
Or learning more about the people side of things? e.g. process, psychology & practices
(Diminishing returns start to kick in after learning your 4th or 5th programming language.)
I've been programming for about 17 years..... and I've found you can't clean code "later". Once it's working it's off to testing and then shipped/delivered. No manager wants you to refactor code unless there is a damn good reason to do it (i.e. there is a bug or enhancement). If you refactor at that time now your next project is actually two projects (a refactor project followed by an enhancement project).
The very idea of refactoring code killed Netscape. They rewrote their underlying rendering engine- a triumph of the developers - with no (little) noticeable enhancement for the end user. Users who were developers "got it" - but the mass market did not.
-CF
This book has no code in it. It's not about code at all. It's about coders, and the attitude they need to survive in a corporate environment. It's about being professional. About saying what you mean, and meaning what you say. It's about how to answer a manager who want's the impossible. It's about finding a way to write effective code just after you've had a big fight with your spouse. It's about all the non-coding things that programmers face every day.
No, not your fault. I was blissfully unaware that the oath did not contain the phrase. Shame on me for not checking that!
There are some things that bother me here. (And they should bug you too)
1. The engineers did indeed stand up by saying no, but authority didn't give a fuck. In the end the engineers did not have control of the project. 2. The engineers didn't merely believe, they knew. I'm sure there were test results and rigorous math involved. Yes, I understand the terms are too often used interchangeably but it's important to know the distinction. When some yahoo stands up for his belief in, I don't know, let's say, god, there is big difference. Belief does not require proof.
When you stand up for something you can't prove, that can have dire consequences as well.
Granted, this writer is a former preacher, and it shows.
I have to say that I don't quite understand your point. What does the "preacher" statement have to do with my comments about the Challenger accident? Can you be specific? What, precisely, does it show?
BTW, I _was_ a preacher three+ decades ago in my young and foolish twenties; but I got over it before turning thirty. I am now quite content to be an atheist.
You are quite right that the engineers stood up to say NO. They wrote memos and held meetings. They were very upset. In the end some of them refused to watch the launch over the issue. No, they did not "know" that there would be an accident. But they were very concerned. They did not have enough evidence to be conclusive, but the implications of the evidence that they did have was very scary. In the end, their concerns were overridden by managers who made the choice to ignore their experts.
My final point in the introduction was that if I were one of those engineers I'd be haunted by the question of whether I should have called Dan Rather.
Question for the reviewer: is the book based on actual scientific research or is it anecdotal evidence?
As the author, I feel able to respond. This book is a book about how to behave as a professional programmer. It is not a book about how to write code. As such it is not, and could not be based on any kind of scientific research. Rather it is based on my 40+ years of experience as a programmer, and on the mistakes I have made over that time. This book contains all the things I wish I had known when I was in my thirties.
This over-use of "agile" to describe programming needs to stop. Please. It's a mean-nothing word. "Agile" and has turned into a useless fluff phrase (has it ever been anything but?).
I just did a search. The text of the book uses the word "Agile" five times, all as side references. The book is decidedly _not_ part of the Agile canon. Rather it is a book about how to behave as a professional programmer.
I have another phrase for you then: "spaghetti code". I hope you like pasta.