CoryFoy - Slashdot User

Comment Re:Is the book based on research? (Score 1) 196

by CoryFoy on Monday June 13, 2011 @05:28PM (#36429322) Attached to: Book Review: The Clean Coder

Good question. I'd say it's primarily an anecdotal book, with some links to research on some areas (like automated testing). I do agree that more research is good, and it's work looking into the research Laurie Williams (among others) is doing around the agile software field.

Comment Re:Hippocratic Oath (Score 1) 196

by CoryFoy on Monday June 13, 2011 @04:18PM (#36428546) Attached to: Book Review: The Clean Coder

Likely my fault. Although, from your links (http://en.wikipedia.org/wiki/Primum_non_nocere):

"The Hippocratic Oath includes the promise "to abstain from doing harm" (Greek: ) but does not include the precise phrase."

So it's not all *that* far off. But thanks for the clarification!

Comment Re:Quality (Score 2) 196

by CoryFoy on Monday June 13, 2011 @03:09PM (#36427660) Attached to: Book Review: The Clean Coder

I think you misconstrued my point. Let's say you find a logic error during code review. That means your process is working well. Let's say another bug slips out to production. That means there is something in your process that didn't catch that. Perhaps it's more automated testing. Perhaps it's more code reviews. Perhaps it's more communication. Perhaps it's closer oversight of junior developers. The point being that when you find a bug in your QA or Production cycles, go back and look at your development process to see what let that through. Sure, you may not find them all. Sure, the cost/benefit analysis may not be worth it. But it stands that we tend to blame individuals whenever a bug hits production instead of stepping back and looking at our overall process to see what led that bug to slip through. Of course mistakes happen. It's what you do about it as a team and as an organization that matters next.

Comment Re:Review or Summary (Score 3, Informative) 196

by CoryFoy on Monday June 13, 2011 @02:50PM (#36427464) Attached to: Book Review: The Clean Coder

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.

Submission + - Book Review: The Clean Coder 1

Submitted by

CoryFoy

on Friday June 10, 2011 @10:16PM

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?

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."

Slashdot Top Deals