Rating: 
Summary: Development managers READ THIS BOOK
Review: I loved and hated this book. I loved the great job that Pete McBreen did of describing many of the intangible issues that arise during great software development efforts and the difference between a craftsman and a hired gun. He touches on issues such as evolutionary delivery and actually (gasp) meeting with the customers, that make the difference between a delivered application and a real, working, solution to a users needs. I hated the book because I'm afraid that I'll never work for a manager that has actually read it, and appreciates all that's being said. I'm really tired of seeing the same basic mistakes (covered in the book) being made over and over again.
-- No need to test, we'll do that in the field.
-- Here's the delivery date and the needed functional list, you engineers code like crazy (literally) and get it done. Development managers, this is not a difficult read. Do yourself, and your team, a favor. Buy and read this book. Then re-read it every 3-6 months or so, so you can tell if you've actually adopted any of the ideas. Hey Pete, are you hiring at present?
Rating:
Summary: MUST READ for all levels of management in a software company
Review: McBreen hits the nail on the head! This book is a MUST READ for all CxOs, VPs, Directors, Mangers, and Software Engineers. It will change the way you think about the software development industry and profession. In Software Craftsmanship, McBreen exposes the weaknesses of our current system of software engineering, and proposes an alternative model based the older apprentice/journeyman/master model. McBreen makes the point that building a software project is not akin to product manufacturing. We don't have factories that stamp out software. Rather we have groups of people trying to massage software into place. McBreen likens successful software development to blacksmiths, or silversmiths. To McBreen, software is a craft that takes years to learn, and more years to master. The only way to properly learn the craft is to be taught at the side of a master. McBreen's thesis emphasises something that is missing from software development today: attention to quality, and attention to expertise. The dotcom frenzy saw thousands of startup firms throwing young untrained bodies at complex software projects. The idea was that a programmer is a programmer is a programmer. The more you have, the faster you get done. McBreen counters this concept by showing that large software systems are better built by small teams comprised of masters, journeymen, and apprentices, than by large teams of plug replaceable programming units.
Rating:
Summary: This is an important work that must be read
Review: Never before have I read anything that so eloquently articulates the "craft" of software development. For me, this book is valuable in a number of ways. I believe Pete McBreen is the first person to expand the vocabulary of our vocation such that we can convey in "laymen's terms" what it is that we do. But perhaps more importantly, I believe Pete has been bold in his assessment of the worth of good craftsmen. Without apologies, he has penned what many of us already know, that for the majority of commercial software development, software engineering does not work, and that the fundamental key to successful software is to elevate and uphold the value of individuals rather than process. I finished the book the other day, and I felt I had gained something more valuable than from any previous book of the same genre. Whether this book will represent a paradigm shift in how we view our profession or simply a better metaphor for understanding it in society, I believe Pete McBreen has advanced the discussion, or perhaps even elevated it to a new level. For that, we all owe him a debt of gratitude.
Rating:
Summary: The industry needs this honesty
Review: Software is written by people - competent software is written by competent people. How did the programming business ever forget this? I once worked for a company where one manager used "craftsmanship" as his vilest epithet. He truly wished that developers would be as interchangeable as wingnuts. He wasn't the one who assigned a power supply designer to e-mail maintenance, but he was close. It's no suprise that the company was bought not long after - by one of its own spin-offs! Maybe it sounds old-fashioned, but this book is really about the moral statement that engineers make by signing their work. Doing a job well is not just a paycheck (though doing the job badly should be reason to lose that paycheck). It's a personal statement, and embodies the creator's values. Is it strong? Is it durable, in a world of changing requirements? Does it really keep working once the creator turns it over to a successor? Properly viewed, software development is part of the human interaction, between provider and purchaser or between co-workers. With corporate loyalty dead, as a working social force, the software industry needs new standards of behavior and social worth. I really think McBreen is on the right track. The idea of apprenticeship is still strong today, especially in life- and safety-critical professions. Doctors serve their internships, and commercial passenger pilots spend a lot of time in the right seat. A few years back, a blaster's license in California required five years of apprenticeship. When software is in your pacemaker, antilock brakes, and even in a building's "active compensation" for earthquake, programming is in well into that same life-critical category. As he says, the best programmers really do serve unofficial apprenticeships (I know I did). The only problem is in making it visible and respectable. I can't stand the cult of personality, but that's not what mastery of craft is about. It's about a sustainable, living culture of service, and of personal and professional excellence. Yes, tools like CMMI can help. Without a basic, personal belief in the value of one's work, reinforced by the work environment, they're just scraps of paper to push around. McBreen is really writing about the cultural value of competence, and about creating more of it. Whether or not you agree with his means, I can not imagine any argument against that basic point.
Rating:
Summary: The industry needs this honesty
Review: Software is written by people - competent software is written by competent people. How did the programming business ever forget this? I once worked for a company where one manager used "craftsmanship" as his vilest epithet. He truly wished that developers would be as interchangeable as wingnuts. He wasn't the one who assigned a power supply designer to e-mail maintenance, but he was close. It's no suprise that the company was bought not long after - by one of its own spin-offs! Maybe it sounds old-fashioned, but this book is really about the moral statement that engineers make by signing their work. Doing a job well is not just a paycheck (though doing the job badly should be reason to lose that paycheck). It's a personal statement, and embodies the creator's values. Is it strong? Is it durable, in a world of changing requirements? Does it really keep working once the creator turns it over to a successor? Properly viewed, software development is part of the human interaction, between provider and purchaser or between co-workers. With corporate loyalty dead, as a working social force, the software industry needs new standards of behavior and social worth. I really think McBreen is on the right track. The idea of apprenticeship is still strong today, especially in life- and safety-critical professions. Doctors serve their internships, and commercial passenger pilots spend a lot of time in the right seat. A few years back, a blaster's license in California required five years of apprenticeship. When software is in your pacemaker, antilock brakes, and even in a building's "active compensation" for earthquake, programming is in well into that same life-critical category. As he says, the best programmers really do serve unofficial apprenticeships (I know I did). The only problem is in making it visible and respectable. I can't stand the cult of personality, but that's not what mastery of craft is about. It's about a sustainable, living culture of service, and of personal and professional excellence. Yes, tools like CMMI can help. Without a basic, personal belief in the value of one's work, reinforced by the work environment, they're just scraps of paper to push around. McBreen is really writing about the cultural value of competence, and about creating more of it. Whether or not you agree with his means, I can not imagine any argument against that basic point.
Rating:
Summary: Reusable code is a myth
Review: The book is very easy to read, fits any IT-aware reader however, it spots very interesting topics for any experienced software developer. First, it emphasizes that programming is not the job for the youngsters only: a truly great developer is worth at leas as much as any manager (including the CEO). Why the people who worked as programmers for 15 years and reached the craftsmanship-experience should find that their salary has reached the maximum level established by the company, and move to another, more paid career, for example, to manage of a horde of dumb inexperienced developers? Why don't developers focus their attention on becoming really good at using the existing tools? A craftsman programmer is really deserving to be paid much. Stop overpaying underqualifying newbies just because they have Java and other ten programming languages in their resume. A person may only be skilled in one, maximum two languages she is constantly practicing. Another fresh idea is that "Software Engineering" metaphor is no longer valid. Software development is not an engineering activity, it is a craftsmanship. A team should consist of craftsmen, journeymen and apprentices. In a blacksmith, for example, a 60-year old craftsman might still show highest skills and awesome productivity. A master craftsman may learn a new technology from an apprentice, but it doesn't mean that she is no longer a master. Apprenticeship is much more effective than schooling. The author also shows that the "reusable code" is a myth. Truly reusable components are possible, but these are not internally developed components. Reusable components need an entire organization dedicated to their creation and support. The issue here is use, not reuse. I would recommend "Agile Software Development" by Alistair Cockburn in addition to this book.
Rating: 
Summary: Describes what an agile world might look like
Review: The book starts by making several good observations: (1) Software Engineering, with it's focus on big-up-front design, is not working well in the business world. (2) Emergent Design and Iterative Development actually work for business systems. (3) An apprentice/journeyman/master system relying on communication and OJT will be more effective than a BS in CS and a one-week course in SQL. (4) The focus on buzzwords and bleeding edge technologies is actually harmful to our craft. (5) The idea that learning is somehow bad because it implies the learner doesn't know everything is bogus and wrong. In fact, the idea that there is a single 'right way to do it' is equally bogus. We should instead grow developers with a wide knowledge of different techniques and allow them to find the right technique for each project. (6) The mobility and job-hopping of developers is counter-productive to effectiveness. People are not cogs. Therefore ... (7) Developers who are widely successfull and stay at a company long enough be of real value should be highly compensated; the author suggests up to $250,000/year and that super-stars should be paid higher than the managers (and possibly executives) who they report to. Without this, ambitious developers are forced into becoming consultants, trainers, or managers.
---> That said, there were a few things that make this book less-than-five-stars: (1) The work isn't really 'new.' The book is a neat combination of the work of Deming, DeMarco, Dave Thomas (The pragmatic programmer, not the Wendy's CEO), and the XP/Agile Crowd. A lot of the book is Deming applied to software, but readable and enjoyable. (2) While some of the book is clearly ideas the author does consistently and knows work, some of it seems to be neat theoretical stuff that hasn't been tried. The thing that hit me was the ideas that developers should make $250,000 per year or they will be 'forced' into consulting ... the author is a consultant. How to even make it possible to create an environment where the developer makes more than his boss is worthy of a chapter or two, but it is not covered in depth, and I get the feeling that is because the author has never actually seen it in real life. In short, if you have tried traditional charts and diagrams and design documents and big-test-plan 'Software Engineering' and you think 'there has got to be a better way' - try this book. If you are a big agile/XP/Scrum person looking for a book to give away to friends, this might be the one. If you are allready convinced and want more deep, practical guidance, you are probably better off going to the sources: Deming, DeMarco, Jeffries, Beck, Cunningham, Brooks, etc.
Rating: 
Summary: Good, but not the best in a market with many to choose from
Review: The empasis in particular on career growth through lifelong improvement as a developer instead of through transitions to management is crucial. I've seen way too many folks allow themselves to stagnate intellecually and then try to get promoted by moving into management, since they see that as the only avenue left to them. However, the reason for the relatively low rating is that _The Pragmatic Programmer_ is a good deal better; Pragmatic is both more approachable in simple chunks for those who can't sit down and read it cover to cover and covers a few aspects of development and lifestyle that Craftsmanship avoids.
Rating:
Summary: Dated examples, needs be focus on the problem
Review: The thesis of the book, that Software Engineering has run its course and it is time to return to the master/apprentice approach, starts by citing the early days of software engineering. His working example of large scale software engineering is the SAFEGUARD system completed in 1975. This example is not very timely nor is it representative of a modern large scale development effort. Although SAFEGUARD presented many challenges to the software engineers of the time, it's lessons have long been absorbed into the practice of software engineering. In addition the SAFEGUARD system was one of the early discovery design projects. Not only did new hardware have to be built, but new and innovative software processes invented as well. Software Craftsmanship presents a view that software developers should return to their craftsman roots in order to deal with the increasing complexity of today's development demands. McBreen makes the case that building software systems requires a set of skills and experiences beyond just book learning, training courses, methodologies, and CASE tools. A craftsman paradigm is presented in which an apprentice software developer learns from journeyman in much the same way other craftsman based professions do. This concept is both interesting and timely in light of the recent failures of systems ranging from the FAA and IRS to dot-coms. McBreen presents this concept as a counter to software engineering methods (SWE), which he proceeds to blame for many of the woes of the industry. Starting with the Preface, McBreen confuses the engineering aspects of software with software manufacturing. He quotes a 1969 NATO report from Naur and Randell, which is not only out of date, but inappropriate in todays software engineering discipline. This use of dated reference materials continues in many chapters and creates the impression that McBreen may not have done his homework. His case against software engineering has useful points but many of the issues he brings up are well worn red herrings. His Big Project example is nearly 20 years old and in a domain unfamiliar to many - a ballistic missile defense system (the first such system). Surely we have learned something about software engineering in the intervening time since 1975. McBreen approaches the issue of software engineer licensing as a potential threat to software craftsman. But he does not provide a balanced view for this topic, since the licensing of process system engineers writing software for mission critical systems has been in place for decades. A look at the European TÃœV and SINTEF regulations would have provided some background on addressing this issue in the US. One issue with the book is that it does not establish a context in which to discuss the topic of craftsmanship-based software development. Customer relationships, development processes, project management processes, examples of success and failure are not placed in a context. One place to look for a taxonomy of software projects and their attributes would have been the Capers Jones series. These texts provide a broad as well as deep view of the complexities of software development and the risks of naively apply one size fits all to a problem. This one size fits all approach is addressed by McBreen in a later chapter. He states that ones size does not fit all, but then proceeds to provide advice and direction to the reader on how to apply craftsmanship methods in the absence of a specific problem domain. The process of developing craftsman-based software for a business application with an on-site customer is significantly different than developing software within a highly regulated or globally distributed corporation using COTS products. Although there is much to offer in the book, I have some specific issues with the material, its sources - or lack of sources - as well as the overall tone for what is presented as a New Imperative. found the book a stimulating read, although frustrating at times when I encountered comments like the Java one above. The major gaps in understanding might be attributed to McBreen's lack of experience in those areas. Gaps that could have been easily filled with research. These gaps I also attribute to poor copy editing, but that is another issue all together. I would recommend the book, but with qualifications and caveats. The read should try to put the ideas into a context and ask are these concepts appropriate for my domain? Do the ideas make sense for the specifics of my problem? Does the specific statement actually make sense from my own experience and the experience of others? Have I seem a similar concept in a peer reviewed journal or are these simply the opinions of the author with an axe to grind? McBreen gives credit to the SEI, Jones, Coplien, Highsmith, Cockburn and others, but he appears to have left much of their contribution out of this book and on the shelf.
Rating:
Summary: Great ideas that will not go far
Review: There is a great deal in this book that one must pay attention to but also a great deal that ignores the reality of the modern world. I agree with most of the author's points but believe that it simply cannot be done as described. The basic premise is that software development is a craft, and should be treated as such. I would never dispute that contention. From the premise, the author then argues that the basic model used to train new developers should be the master/apprentice one. Again, I agree that this is the preferred model in an ideal world, which is regrettably not what we have today.
In putting forward this proposal, McBreen ignores the last few centuries of human history, essentially the entire industrial revolution. For most of history, the master/apprentice model was how knowledge was passed down through the generations. However, once the industrial revolution began, the demand for goods became so great that the old model simply could not satisfy it. Therefore, the solution became the large collection of workers at a site and the segmentation of worker tasks into an assembly line. In fact, it was these changes that made the mass production of consumer goods possible.
There are similarities in the use of software. The demands that are now being placed on software are so great that it in fact mirrors the early years of the industrial revolution. As some of the books on the industrial revolution describe so vividly, many of the early products were shoddy, but since they were the only ones available, people used them. In many instances, people had relatively decent clothes, shoes and other consumer goods for the first time.
The same thing is true in software, where so much of it is shoddy, but people use it because it does provide services that they need, and they learn to live with it, albeit accompanied by some occasional foul language. Software has now become a mass product and our only known way to produce mass products is to mimic some of the aspects of the assembly line. The days of the lone coder writing a powerful application are most likely gone forever. Many of the recent advances in software have been designed to isolate the work so that many people can work in parallel. I simply do not see how the clock can be turned back so that the demands for software can be met by going back to the master/apprentice model of training.
I also agree with the point that most major, successful projects had a small core of stars that made it happen. Unfortunately, the very definition of star means that there are very few available. Not every team can have enough stars to drive the project to completion. Most teams just must make do with a larger collection of adequate to above average developers, each of which concentrates on a small set of tasks. Not the ideal situation, but certainly an indisputable reality.
I did something to this book that I rarely do, namely devoured it when I read it. The author is clear, concise and reasoned in his proposals. It is too bad that they are going to be impossible to implement. I fear that the only solution to buggy software is one similar to what took place in the industrial revolution. Government will have to step in with a set of regulations dictating how software, and those who develop it, should behave. I would prefer McBreen's proposals, I just cannot see any way they will work in the 'modern' world of software construction.
| 
