The book begins by pointing out the current “software engineering” approach, which borrows ideas from other engineering disciplines, and explains that is was developed for large-scale defense type projects that may not only involve developing software, and although it may still be ideal for such work, most software is made on a smaller scale and can be more effective using more appropriate approaches.
I was a little confused at first, as McBreen’s use of the phrase “software engineering” seemed to differ from my own at the time I read the book. He seemed to use the phrase as a synonym for traditional, or waterfall-style, project management, whereas to me software engineering, as I studied it at uni, was related more to the practical aspects of producing software. Things like software design, testing, metrics, requirements analysis, architecture, the “grain” of interfaces, coupling and cohesion, and distributed computing. As I look back now, software engineering as I learned it was the forerunner of a lot of the clean code/agile/pragmatic practices of today, such as TDD, DDD, SOLID principles, customer collaboration etc. But I had a look at the SWEBOK and it turns out that McBreen’s view of software engineering was a lot closer to common usage than my understanding of the term. You can notice that in the current, 2004, version of the SWEBOK the chapters are organized according to phases, with “software construction” (the term itself reinforces the classic, yet inappropriate building metaphor), simply one among many. At least it acknowledges that this “construction” may occur within not only waterfall style phases, but agile style iterations. It continues to treat design and construction as separate activities, which technically they are, but not in the way the SWEBOK lays out. I am a firm believer in Jack Reeves’ “Code as Design“, (reinforced by Ivar Jacobson’s quote “Architecture without executable code is just an hallu cination”); programming IS designing, the source code IS the design of the software, construction is what the compiler does to turn that design into an executable.
Anyway, I still believe the SWEBOK, and indeed the topic of software engineering is valuable, as too many developers still think developing software is a purely technical discipline, a matter of programming, or typing in source code, and neglect the aspects upstream and downstream of that activity, probably because they are used to some analyst or manager doing all the hard work and throwing it as a document over the cubicle wall.
But I digress, the book Software Craftsmanship also addresses thinking about the entire value stream, and in a way that is probably more appropriate for most software development efforts today, and in a way that is more in tune with the Agile values that seem so popular today, especially the one about individuals and interactions over processes and tools.
The book presents the idea of personal relationships, and vouching for one another, being a more appropriate indicator (for say a hiring manager, or potential client) of someones skills than certification. That is a great idea, but seems more valid for independent contractors that work on short term projects rather than long term permanent employees, and could also end up indicating nothing more than who knows who, or who has worked with whom rather than a true indicator of skill. I mean if I work with someone and I want them to vouch for me, and they do, how would it be if I were to withhold vouching for him because I didn’t think he was good enough!
I am especially fond of the idea in the book that focuses on the strong relationships that software craftsmen have with their users. For me that is one of the great “secrets” to developing successful quality software that fulfills both the customer’s needs, and is maintainable. I don’t know why it is a secret, it should be obvious, but still even companies that claim to be agile still have a wall of analysts or project managers that talk to the customers and then throw documents over the wall to the developers. I think one of the causes of this is Scrum who claim that the developers need to be shielded from the customers by the Product Owner and ScrumMaster. Nonsense! For me the difference between developing software quickly, with care and respect for the customer’s needs is completely dependent on the relationship I can build with them. The Scrum idea that developers need to concentrate on tapping out code all day reflects an outdated view of software development inherited from traditional projects where “software designers” do all the thinking and write up a complete spec for programmers to convert into source code and type in. With modern tools, and the realization that the act of programming is mostly just plugging in libraries anyway, the time spent in front of the keyboard tapping away is the easy bit, and should not constitute most of the developer’s time.
What I also like is the idea that these relationships with customers should be long term, and should be carried through as long as the software is still being used and maintained. In the software craftsmanship world, maintenance is a high-status activity, rather than something newbies do because no one else wants to do it. This was especially motivating for me as I am involved in the development and maintenance of a large mature software product, and the various constraints and other challenges that that imposes was demotivating as it conflicted with my ideals of how I would have done things with the advantage of starting from scratch using ideas that were not so common when the product first began to be written.
Thanks to the book, I am proud to be a software maintainer, and enjoy the challenges that it brings.
The chapter on managing craftsmen is fairly short, and reflects much of the thinking on software management that has become mainstream over the last few years, such as self-organization, emergent leadership, servant leadership and the role of management as more of a facilitating and coaching one rather than command and control.
The book borrows from a traditional craft based model when it comes to describing the career or occupation of software craftsman itself: The Apprentice, Journeyman, Master model. The advantages of this model are only through close collaboration on actual real work, can apprentices learn the knowledge and skill required to become proficient at software development which is something I agree with. The biggest jumps I feel I made as a software developer were while working with others, learning directly from them in close collaboration. Naturally implied is the role of masters and journeymen not only in developing software but in training the apprentices. This aspect gives me hope for seeing software craftsmanship as a useful model for our profession here in Germany, as there is already an apprenticeship program in place for training new developers and allowing them to gain real world experience.
I probably see myself as a journeyman. Journeymen are supposed to move around between jobs every few years so they can pick up various skills from various masters, which is what I have done. It does however conflict somewhat with the concept of long term customer relationships.
One thing craftsmen should do, according to the book, is to build up a portfolio of work, and use that as our C.V.s in place of certifications and licenses. I am in favor of that, generally, but what makes it difficult for me, especially when considering my work as a journeyman over the past decade, is that the majority of the work was not mine alone. Almost everything I have done as been done together with others. In my current job, in maintenance this is even more difficult, as the work involves bug fixes and small modifications to existing functionality so I would hardly feel comfortable claiming credit for any functional part of the software, even in part.
The remainder of the book is mostly good advice that is found in most similar books, design for testability and maintainability, learn to collaborate, be wary of bleeding edge tools, prefer open source tools and libraries, don’t neglect user friendly user interfaces. Never stop learning and trying to improve, get involved with the community and reflect on your progress are the final three points the book makes, and ones that I fully agree with.
This review has taken longer than I though, so I will, hopefully, do another review later in the week.
By biggest takeaway from this book are at the values level, because that is how I think. The three biggest values that I have adopted after reading this book are Humility, Judgment, and Responsibility. Humility, because we should never assume we know enough, or that someone else’s ideas are less valuable than your own. Humility to accept that we are not always the decision makers, and to accept the decisions made by others and do our best to work with those decisions like true professionals, even if we continue to disagree with them. Humiltiy to be happy to do the grunt work, the less glamourous tasks, the bug fixes, and repetitive tasks.
Actually I thought about humility and craftsmanship the other day when reading a recent blog post from Obie Fernandez. He mentions that “I actively avoid trying to work with clients that have legacy issues, corporate politics, non-cooperative stakeholders, saboteurs, etc.” Now that way is a great way to ensure success, but it is almost too easy. I see it as an antithesis of software craftsmanship on two grounds. First I feel a good craftsman does his best in any circumstances. That is what, in my opinion, makes a software craftsman a bit more special than the classic agile developer who has read all the books and knows all the patterns, and can quickly produce a nice clean greenfield, well designed, web application, with modern tools, high code coverage and a highly engaged customer with similar values. Throw people like this in the deep end, with poorly designed legacy code, hordes of angry users, a hostile and change-fearing corporate or developer culture, or perhaps situations where they are expected to be the domain specialist or don’t lend themselves to classic patterns, and they wont get very far, they will insist on and depend on things that just aren’t available. A craftsman will remember when all development was like that, and draw on his vast experience, and store of tacit knowledge, connect with old colleagues, dust off his COBOL or C++ books, or his old computer science textbooks, and just get things done. The second point is related to how people learn in relation to their comfort zones. If one insists on working well within one’s comfort zone, one might get used to it. One might get very good at delivering value consistently in such an environment. But I doubt one will learn much. A craftsman will deliberately seek out opportunities that differ from what he is used to. Perhaps seek out some constraints or other challenges he hasn’t faced recently. He will thrive in situations that force him to adapt and learn. This is less related to the value of humility, but personally I find situations where I have to deal with “legacy issues, corporate politics, non-cooperative stakeholders, and saboteurs” and still be expected to deliver, exhilarating, particularly for the rate at which my principles and prejudices get challenged, and are forced to be adapted, and strengthened. It is a bit like evolution. The more predators there are, the more scarcer the food sources, the more hostile the environment, the quicker a species evolves to adapt traits that strengthen it, and increase its likelihood to survive. Species that evolve in more sheltered environments, like the birds in New Zealand, with no predators, lose their ability to fly, or to see clearly, and happily go along picking at the ground for food. Until the ecosystem changes, and new species come along, and either compete for the same food source, become predators. Success is great but you learn more from failure, and that learning makes success more likely as conditions change, as they always do. Evolution demands adapt or die, and staying within one’s comfort zone favors eventual death.
I wonder what Hashrocket does when its customers become successful and grow, and the code becomes legacy, and a political corporate culture develops. Do they get dropped in favor or other quick wins, low hanging fruit? I think the craftsman would not only favor preserving the relationship long term but thrive on the opportunity to hone his skills against the face of new challenges.
Judgment is important, as craftsmen must continually make tough decisions. What tool to use, whether to delete code and start from scratch, or struggle on with ugly legacy code, who to work with, what courses to take, what apprentices to take on, how to teach them, when to move on from a customer or job or stay with them. I think the difference between a programmer and a craftsman is that the latter rises up and exercises his judgment rather than carrying out orders from management, which leads on to:
Responsibility. One of the most important values I have adopted from the craftsmanship movement is that of responsibility, which is a natural consequence of exercising judgment. We need to stand up and take the fall when things go wrong, not blame the process (after all, we are either responsible for the process, or responsible for doing our best within the constraints of a process). If anything is not quite right, it is our responsibility to at least point it out to the decision makers, if not correct it ourselves. We are also responsible for our own careers. If you find yourself not learning anything, or notice some way in which you can deliver more value than in your current role, or feel that you are being overlooked for some task that you would be ideal for, don’t blame your employer, or your co-workers, or the manager. However craftsmen don’t get anything handed to them on a silver platter, including responsibility, without taking the initiative and proving that they deserve it.