Author: Robert C. Martin
Publisher: Prentice Hall (Pearson Education) www.informit.com/ph
Published: May 2011
Print ISBN 13: 978-0-13-708107-3 and Print ISBN 10: 0-13-708107-3
Formats:
Print: softcover
eBook (ePub, PDF)
Safari Books Online
Pages: 256
Prices:
Print: $31.99
eBook: $11.20

True software craftsmanship

Although the subject of this review is a book titled “The Clean Coder”, subtitled “A Code of Conduct for Professional Programmers”, it has points of interest for all IT professionals as well as for its specific target audience. Examples of the sorts of topics covered in the book that apply to all who work in the IT profession include acting professionally; becoming a “team player”; managing your time; dealing with pressure; and learning how to successfully collaborate with others.

Of course, there is plenty of practical advice too for experienced professional programmers as well as those just starting out. The book’s author, Robert C. Martin, has extensive experience himself with IT in general and software development in particular, having been involved with programming since 1970. Martin’s international company, “Object Mentor, Inc.”, specializes in process improvement consulting, object-oriented software design consulting, training, and skill development services.

In this review, let us first put the spotlight on various topics discussed in his book that focus specifically on developing software. Those topics include the following:

• Coding: Programmers are sometimes afflicted by “writer’s block”, the curse suffered also by many an author or novelist. Martin sums it up perfectly: “the code just doesn’t come.” It is a situation that all programmers have experienced at some time or other. As he says, “often you will find other work to do. You’ll read email. You’ll read tweets. You’ll look through books, or schedules, or documents. You’ll call meetings. You’ll start up conversations with others. You’ll do anything so that you don’t have to face that workstation and watch as the code refuses to appear.” However, there is a solution. Having suffered from this uncomfortable feeling himself, Martin recommends finding a pair partner. “It’s uncanny how well this works,” he says. “As soon as you sit down next to someone else, the issues that were blocking you melt away. There is a physiological change that takes place when you work with someone. I don’t know what it is, but I can definitely feel it. There’s some kind of chemical change in my brain or body that breaks me through the blockage and gets me going again.”
• Test Driven Development (TDD): When it was first introduced over a decade ago now, and in fact, ever since, there has been a lot of controversy surrounding Test Driven Development. Martin nevertheless is a firm believer that TDD works. Of course, you must decide for yourself, but when attempting to do so, it is worth pondering the following questions posed by Martin: “How can you consider yourself to be a professional if you do not know that all your code works? How can you know all your code works if you don’t test it every time you make a change? How can you test it every time you make a change if you don’t have automated unit tests with very high coverage? How can you get automated unit tests with very high coverage without practicing TDD?”
• Acceptance testing: Like Test Driven Development, acceptance testing is plagued with controversy too. Martin reports that “the term acceptance test is overloaded and overused. Some folks assume that these are the tests that users execute before they accept a release. Other folks think these are QA tests.” But he defines acceptance tests “as tests written by a collaboration of the stakeholders and the programmers in order to define when a requirement is done.”
• Testing strategies: Even the slackest of developers usually carries out at least some rudimentary testing on the software that he or she has written. Back in 1989, Martin was working at Rational on the first release of a software system known as Rose. He recalls that “every month or so our QA manager would call a ‘Bug Hunt’ day. Everyone on the team, from programmers to managers to secretaries to database administrators, would sit down with Rose and try to make it fail. Prizes were awarded for various types of bugs. The person who found a crashing bug could win a dinner for two. The person who found the most bugs might win a weekend in Monterrey.” So the obvious question to ask yourself is whether the quality of software testing in your own organization comes even close to matching this level of aversion to bugs? Martin stresses that “despite the fact that your company may have a separate QA group to test the software, it should be the goal of the development group that QA find nothing wrong. Of course, it’s not likely that this goal will be constantly achieved. After all, when you have a group of intelligent people bound and determined to find all the wrinkles and deficits in a product, they are likely going to find some. Still, every time QA finds something the development team should react in horror. They should ask themselves how it happened and take steps to prevent it in the future.”

Let us now turn our attention to just a couple of examples of content from the book that are relevant to all IT practitioners and not just developers.

The first of these concerns time management, with a special emphasis on meetings. It is simply impossible to work in any area of IT without having to attend meetings. However, not all meetings are equal. In fact, a largish number of meetings can be regarded as a waste of time, because they are either poorly run, or the agenda is hijacked, or the wrong people are attending the meeting, and so forth. Martin reminds his readers that “you do not have to attend every meeting to which you are invited. Indeed, it is unprofessional to go to too many meetings. You need to use your time wisely. So be very careful about which meetings you attend and which you politely refuse.” At other times, Martin advises that a particular “meeting will be about something that interests you, but is not immediately necessary. You will have to choose whether you can afford the time. Be careful – there may be more than enough of these meetings to consume your days.”

Secondly, another area of concern to all IT professionals is the subject of pressure. As Martin says, mounting pressure can occur because a “project just takes longer than anyone thought it would. Sometimes the initial design is just wrong and must be reworked. Sometimes you lose a valued team member or customer. Sometimes you make a commitment that you just can’t keep.” So what coping mechanisms does Martin recommend you adopt when faced with pressure? As well as trying not to panic, and keeping communication channels open with everyone involved in the project, he also suggests getting help as soon as possible. “Pair!” he says, “When the heat is on, find an associate who is willing to pair program with you. You will get done faster, with fewer defects. Your pair partner will help you hold on to your disciplines and keep you from panicking. Your partner will spot things that you miss, will have helpful ideas, and will pick up the slack when you lose focus. By the same token, when you see someone else who’s under pressure, offer to pair with them. Help them out of the hole they are in.”

“The Clean Coder”, the sequel to Martin’s previous book, “Clean Code”, is one of the titles in the Robert C. Martin series of books (http://informit.com/martinseries). Two chapters from “The Clean Coder” – the third and fourth – are available online for reading. In the third chapter, titled “Saying Yes”, Martin makes the point that “professionals are not required to say yes to everything that is asked of them. However, they should work hard to find creative ways to make “yes” possible. When professionals say yes, they use the language of commitment so that there is no doubt about what they’ve promised.” In the fourth chapter about coding, Martin provides advice about what to do when you fall behind schedule (after all, estimates are at best educated guesses). He suggests that “the trick to managing lateness is early detection and transparency. The worst case scenario occurs when you continue to tell everyone, up to the very end, that you will be on time – and then let them all down. Don’t do this. Instead, regularly measure your progress against your goal, and come up with three fact-based end dates: best case, nominal case, and worst case. Be as honest as you can about all three dates. Do not incorporate hope into your estimates! Present all three numbers to your team and stakeholders. Update these numbers daily.”

In closing, it is rare to find a book about coding that can be of value to a diverse range of IT professionals other than developers. “The Clean Coder: A Code of Conduct for Professional Programmers” is one such book. Its insights into the craft of developing software are invaluable to all who are charged with delivering quality software to users in their companies and organizations.

“The Clean Coder” concludes with an appendix titled “Tooling” which contains the details of Martin’s current personal toolkit. As he correctly says, “today software developers have a wide array of tools to choose from. Most aren’t worth getting involved with, but there are a few that every software developer must be conversant with.” The tools in the appendix have been grouped into the following categories:

• source code control
• IDE/Editor
• issue tracking
• continuous build
• unit testing tools
• component testing tools
• integration testing tools
• UML/MDA