The Software Craftsman Book Review
As I write this, it is just a few days away from the 2nd birthday of this website.
ZombieCodeKill was created to promote better professional software practices.
A year is, of course, a full orbit of our planet around the Sun, arriving back at the point we started from and beginning again. So it is as good a time as any to reflect on how the previous year went and try to make the next year even better.
Something I have regretted is I never felt that I had written a good article on Software Craftsmanship. However reading this book taught me that Software Craftsmanship is about much more than just writing good code.
Here is a summary of the book chapter by chapter. I also give my opinions on some of the issues covered in the book.
Part 1: Ideology and Attitude
Foreword by Robert C. Martin
Chapter 1: Software Development in the 21st Century
Sandro begins with a personal story on his earlier career, stressing the importance of letting your passion, rather than money or other factors, determine your career path.
He talks about what seniority means in software development, making the point that the number of years you have worked is a very poor indicator of your skills.
This is a point that I wholeheartedly agree with and also made myself in the article Honestly Assessing Your Skills.
The chapter ends by talking about how much the industry has and is changing and the need for agility.
Chapter 2: Agile
This chapter begins with the story of how the Agile Manifesto was born, and covers the 12 principles behind this manifesto.
It discusses the positive transformation that Agile brought our industry, but then covers what Sandro calls the “Agile Hangover”:
Many Agile projects are now, steadily and iteratively, producing crap code.
Sandro says this has been a partial transformation — a transformation of the process but not of the technical practices.
He explains why talk about how efficient Toyota became due to process changes, is something that does not bare much relevance to most software development projects except for the most important fact, which is Toyota also focus on high quality.
Software Craftsmanship is not meant to replace Agile, but to complement it.
It says Agile helps companies to do the right thing, and Software Craftsmanship helps companies to do the thing right.
(As an aside, the theory of Rightshifting calls doing the “right thing” Effectiveness, and doing the “thing right” Efficiency.)
Chapter 3: Software Craftsmanship
This chapter describes what Software Craftsmanship is. Sandro gives several definitions, with the shortest one simply being:
“Software Craftsmanship is about professionalism in software development.”
This chapter covers the history of the Software Craftsmanship movement in detail.
I have previously written a short history that you can read, but this book goes into greater depth.
It then covers the Software Craftsmanship Manifesto and gives a detailed explanation of each point.
The chapter ends by addressing many of the various criticisms against the Manifesto.
Chapter 4: The Software Craftsmanship Attitude
This chapter stresses the importance of continual learning and self development.
It recalls a personal story to illustrate the need to own your career, which means never relying on your employer to give you all of the training needed to keep improving.
Sandro gives some professional examples: plumbers, lawyers and doctors, all of these professions do their own training.
Factory workers, on the other hand, are an example of people who rely on their employer to show or tell them exactly what needs to be done.
There is a good explanation of the different categories of books that are available for software developers:
- Technology-specific
- Conceptual
- Behavioral and Revolutionary.
It then discusses Blogs (thanks for reading mine) and Technical Websites.
Next up is social media such as Twitter. You can follow me on Twitter here, and I normally follow back.
It also talks about ways to practice, such as simple coding exercises known as Katas. To learn more about these, go to codekata.com
Pet projects are another way to learn and practice, and for the author they are the best way. Open source projects, pair programming, social events, and the need for deliberate discovery are also discussed.
Also covered in this chapter is the important topic of work-life balance, including an introduction to the Pomodoro technique.
Chapter 5: Heroes, Goodwill and Professionalism
This begins with a personal story of working very unhealthy hours in a vain effort to be the hero on a large project. This leads in to the need to learn how to say “No”.
The next personal story is a tale of working for a bad manager who always pushed for more and would never negotiate either on scope or schedule.
This ended very badly but the most important section here is the lessons learned.
Although it is always easy to blame others, it is much more constructive to take a hard look at ourselves and understand what we could have done differently.
Sandro explains that always saying no isn’t a professional attitude either, and how we can provide alternative options that can lead to a better outcome for everyone.
Chapter 6: Working Software
This chapter begins by explaining that working software is no enough, and talks about the invisible threat of technical debt, and some of the ways in which developers justify it.
Sandro covers a common Agile anti-pattern: the Unit Test task card, explaining why this is a bad practice.
I have personally seen unit test task cards but never saw anyone pick up this card before the development task card.
Next up is legacy code, and the need for a professional attitude to it. Almost every company has some legacy code and we need to deal with that.
Legacy code maintenance requires different skills to working on a greenfield project, but refactoring is one skill that is important in any project.
Chapter 7: Technical Practices
When I first read this chapter I was disappointed, but as I read the rest of the book I understood the importance of this chapter as an introduction to topics addressed later on.
This chapter is mostly about Extreme Programming (XP). The book paints the story of the C3 project as a huge success, but omits the fact that the project was cancelled after seven years work (not that the cancellation had anything to do with XP but it’s not what I call a successful project).
Each of the XP technical practices are discussed: Test Driven Development (TDD), Continuous Integration, Pair Programming and Refactoring (which is part of TDD).
Also discussed is Accountability and Pragmatism.
My disappointment was mainly due to comparison with Domain Driven Design, which was written in 2003 as a set of practices on top of XP and a book that was so forward thinking then and even remains so now.
Chapter 8: The Long Road
Sandro tells another personal story: growing up in Brazil with a dream of living in London.
He says some very nice things about London and it was great to read this.
It is easy to think of the high prices and other downsides of living here, but this reminded me that I am in many way lucky to have been born here.
Sandro is an example of a software developer who has become successful due to a lot of hard work and determination. He gives example of things that we can do to create opportunities for ourselves.
He covers Autonomy, Mastery and Purpose: three things that are very important for our happiness.
In fact for motivated developers, they are more important than money. Derick Bailey has a good article on this on Outlier Developer
It also covers careers inside companies and how it may not be the best thing either for ourselves or the company that we work for.
Part 2: A Full Transformation
Chapter 9: Recruitment
Hiring the right developers is crucial for any software company, but the best developers can be hard to find. Sandro says:
“Although every company would say that they want the best people, they have no idea what that really means.”
This chapter shows an example of a typical job description and points out all the areas where it goes wrong.
We have seen these types of job descriptions so many times we’ve grown used to them and their associated problems.
Sandro explain why job descriptions are anti-patterns.
Lou Adler has a number of articles on this on the TLNT website:
Get rid of job descriptions and you’ll hire better people
Here’s Why We Need To Get Rid Of Job Descriptions
Ban job descriptions
The book then describes what you can do if a job description is needed, by comparing a typical job description from a financial institution against a much better one written by 7digital.
There is also comprehensive information on defining effective filtering criteria, and includes a couple of pages discussing proactive recruitment.
I definitely found this chapter to be inspiring, and if you are currently recruiting for a new developer, this chapter alone will be worth the cost of the book for you.
Chapter 10: Interviewing Software Craftsmen
Describes the process from both the perspective of the interviewer, and the interviewee.
Modern definitions of the word interview seem to have lost sight of the fact that it is comprised of the words “inter” and “view”.
The purpose is for both parties to gain a better view of what the working arrangement might be so that both parties can decide whether it is an idea that would work well for them.
Sandro stresses the importance of candidates asking questions in an interview.
Asking no questions should be a big red flag for hiring companies. We learn some things a candidate should pay attention to when in an interview.
It describes a good interview, what is discussed in one, and what the focus is. The technique of mind-mapping a conversation is described, as is pair programming. Candidates should bring in their own laptop as part of the interview process.
I have written about interviewing candidates myself and agree with all of Sandro’s very good points.
At most companies, there are so many mistakes made that the best candidates either don’t want to apply in the first place, or don’t want to proceed through the whole process, or accept the offer if it does gets that far.
Chapter 11: Interview Anti-Patterns
This is a roundup of interviewing practices that tend to lead to the wrong candidates being hired.
Chapter 12: The Cost of Low Morale
This begins by revisiting the Agile Hangover problem, and goes on to discuss 9-to-5 developers.
Sandro recounts a story of a troubled project he worked on while working for a consultancy company.
Next up is how to inject passion into the development team. There are some simple things that Sandro has found to have a very positive effect.
Chapter 13: Culture of Learning
This chapter begins with another tale of company mismanagement while Sandro worked for a consultancy firm.
“Looking back, knowing what I know today, I feel that what we’ve done was immoral. Our consultancy company shouldn’t have accepted that type of work. I should have said no to that.”
Sandro says that junior developers are lead to believe becoming a manager or an architect is their natural career progression. However developers enjoy their jobs much more when they are aspiring software craftsmen.
This chapter lists numerous things that can be done to create a culture of learning.
It then asks the question “What if others don’t want to join in?” and explains what you can do to positively change that.
Chapter 14: Driving Technical Changes
This chapter has been inspired by the book Driving Technical Change by Terrence Ryan. There are a number of categories of skeptics that Terrence Ryan has identified:
- The Uninformed
- The Herd
- The Cynic
- The Burned
- The Time Crunched
- The Boss
- The Irrational
Sandro has describes all of these categories, and then describes some additional categories that he has found:
- The Indifferent
- The Wronged
- The Inept
- The Ivory-Tower Architect
- The Insecure
- The Fanboy
Advice is given on establishing trust, gaining expertise, leading by example, choosing your battles, and making gradual changes.
The subject of fear and incompetence is discussed. Then it asks the questions, how do I convince my manager, and how do I convince my team to do TDD?
In the section “Facing the skeptics”, the power struggling argument between Sandro and the “Ivory-Tower” architect makes an interesting read.
In my article psychology for programmers, I explain how this understanding can lead to better relationships. From reading this book, I can tell that Sandro is most likely a “Fiery Red”, that is an Extrovert Thinker. The “Ivory-Tower” architect is most likely also a Thinking type.
In this argument, both people feel threatened. The architect feels threatened because Sandro is taking ownership of the work that he feels is part of his responsibilities and feels he has been undermined.
Sandro feels threatened because the architects are in some respects (for better or worse) viewed as superior to developers, and Sandro has previously worked as an architect and found reasons to prefer working as a developer instead.
There was something in the way he pronounced coder that made me feel inferior.
In my opinion developers should never be considered inferior to architects.
Sandro feels that developers become accountable for what ivory tower architect are responsible for.
I have for a long time disliked the RACI matrix that managers and business analysts in waterfall or ITIL environments, because for things to work well responsibility and accountability need to go together.
Should a responsible person not be accountable? Should an irresponsible person be accountable?
No. The idea behind it is seems to be that the task someone is responsible for is so straightforward that it’s just a matter of routine execution.
So I can see how this could work well in a factory environment: the supervisor is accountable for the responsible factory workers.
Good software engineering is much more complex than this.
Chapter 15: Pragmatic Craftsmanship
This begins with the point that quality is always expected.
For a company that usually aims for average code, more often than not, average means very poor.
The discussion moves on to the myth of quality being expensive and time-consuming.
Poor quality is usually much more expensive, especially over the long run.
Up next is having a pragmatic attitude to Test Driven Development and refactoring. We don’t need to refactor everything all the time.
It looks again at the relationship between Software Craftsmanship and XP, making the point that XP technical practices may not be the best practices forever (although they seem to have stood the test of time pretty well over the past 17 years).
It describes how you can help the business by proposing a different solution that can be done is less time without sacrificing quality.
Then it covers the Four Rules of Simple Design, both Kent Beck’s original rules and J.B. Rainsberger’s reworking of it.
Next up is a discussion of Design Patterns and their overuse and abuse.
What if the requirements change in the next five years?
What if Godzilla destroys the entire city while fighting King Kong?
Sandro explains, at a high level, the benefits and the costs of using design patterns and the need to weigh up these factors.
The chapter ends with the need for pragmatism, stating that you can’t have craftsmanship without it.
Chapter 16: A Career as a Software Craftsman
This is an excellent chapter to round out an excellent book.
It covers career progression, roads and milestones, building our careers one job at a time, job diversity, and the mission that software craftsmen are on.
Appendix: Craftsmanship Myths and Further Explanations
This is an important appendix, you will want to read it.
Thanks to Sandro Mancuso for writing this book. If you haven’t yet read it, I recommend picking up a copy so that you can read it in full.
