Rating: 
Summary: Worthwhile examination of the processof software development
Review: "Software Craftmanship: The New Imperative" is a very thought-provoking book. The key focus of the book is the demolishing of the software engineering myth, or (more accurately) establishing the boundaries of when we should do full-blown software engineering, and when a more relaxed (but equally dedicated and professional) approach should be taken.McBreen makes the very solid point that the vast bulk of software engineering research has been aimed at LARGE projects, in the thousands of developer-years range. However, the vast bulk of software projects just aren't in this league. Furthermore, he points out that many of the practices involved, particularly the infamous waterfall cycle, are aimed at dealing with the challenges of co-ordinating such a large group of people to attack such a large problem. He then comes up with an alternative model of software development, focussed around the idea of the skilled software professional, or craftsman. His choice of wording, whilst controversial, is deliberate, and aimed at provoking thought and discussion. He takes a longer view than simply running a single project, but discusses the way individuals should learn and progress over several projects throughout their career. A comprehensive range of references backs up many of the points he makes throughout the book. Where the book falls over is in lack of concrete information on how to live as a "software craftsman". However, this is intentional; this book provides the high-level view. Fortunately, his references provide a fallback position, especially the book "The Pragmatic Programmer". Whilst I doubt we'll see a formal system of software apprenticeships take hold, I feel that many organisations already have informal arrangements in place. The ideas in this book would assist any company that actually cared about developing and retaining staff. A must-read for any software professional who is actually interested and passionate about his or her career and vocation.
Rating: 
Summary: Mediocre implementation of a good idea.
Review: After reading Steve McConnell's After the Gold Rush I decided to look for a book with an alternative view point. Software Craftsmanship is what I found. Not that these two books are at opposite ends of the spectrum but they do have different emphases. I really like what Pete McBreen is presenting but I really didn't like the way he presented it. I have 24 years of experience as an IT professional and have worked for some very large corporations and a couple of very small corporations. I've seen a lot. In my opinion, much of what McBreen suggests would never get off the ground at any company for which I've worked. Some of what McBreen says has been around for years. I did come across some things that I am glad to finally see in writing. And of course, he wrote about some things that I hadn't encountered in my career. Unfortunately, I don't feel he gave a convincing argument supporting his core position even though I think he is correct. But then, I felt that way before I picked up the book. I think he's on track with some of his recommendations and totally wrong in some of his other recommendations. I think this is a fair first attempt to present this view. I hope he or someone else makes another attempt and does a better job of it.
Rating: 
Summary: A MUST-READ for frustrated software developers
Review: Ever wonder why all the talk of "software engineering" left you feeling cold, as if all your brain power, your creativity, your pride in your work, could be reduced to a mathmatical formula? I did. I wanted software engineering to be the answer, but the more I studied, and the more I experienced, the more I believed that software development was essentially a human activity, not an engineering activity. Pete McBreen's book, Software Craftsmanship, finally crystalized my thinking. I spent the entire book saying "Yes, I've been there, seen that, thought that, yes, yes, yes." Not only does McBreen clearly define the problem, he goes the critical next step -- which is to offer a solution. Software Craftsmanship offers a new model for thinking about software development, a model that fits in beautifully with the "agile" community, and gives a refreshing alternative to the "software engineering" community's insistence that software development will be reliable, repeatable, and produce excellent results as soon as we can eliminate humans and their messy judgement and flaws from the picture. Thank you, Pete McBreen, for giving my profession back to me.
Rating:
Summary: Realistic software development
Review: Finally! A book that finally takes the cr*p out of software development.
It's time we admit that the so-called 'methodologies' don't work: they never have. Our projects succeed IN SPITE OF methodologies; they succeed because of GOOD PEOPLE.
Our techniques for engineering only work for MANUFACTURING, not design. And software is pure design. We have always been doing software craftsmanship, we just never realized it. Let's stop the farce of "software engineering".
I'm not saying that what we do does not involve science; software development is very scientific. And it is even more scientific to acknowledge the truth of human nature and how our minds work, and that humans do not perform best as a simplistic cog in a machine. We already have an almost-perfect model in the craftsmanship tradition.
Rating:
Summary: Read it and weep.
Review: First there was Fred Brooks' "Mythical Man Month". Then "Peopleware" by Tom DeMarco and Timothy Lister. Now, Pete McBreen's book, "Software Craftsmanship" takes its place at the head of this list of what I think are the best books on the human element in software development projects. I have been a professional software developer since 1979 when I joined a large telecommunications company. There was opportunity (if you wanted it) to learn software development much along the lines of McBreen's craftsmanship model. The best learning and greatest influence came from the great developers whose work I had the privilege of supporting, studying, maintaining or enhancing. I soon began to think of my profession as a craft, some mixture of art and science, and was encouraged by the work environment and the people to continually improve my skills toward designing and delivering reliable, maintainable, and extensible software applications. During my 21+ years with the company I gravitated toward projects and people that would help me along that path. The values that Pete McBreen promotes in this book became my values. Those values kept me going even as the work environment changed. There was always some degree of the software engineering mindset to contend with, but enough opportunity to exercise craftsmanship within that context to get plenty of job satisfaction and professional growth. But, as competition increased and the company became more "market driven" rather than "technology driven", the software engineering mindset began to dominate. There was a strong emphasis on ISO Certification and the development, maintenance and enforcement of elaborate processes and procedures to govern our work. Skilled developers were still valued, but the work environment favored interchangeable "resources" that could be plugged into the process wherever needed. The high point of my career came in the mid 1990's when I had the chance to work on a small team of five developers who worked closely together for over a year to design, code and deliver a complete rearchitecture of an existing system. Each member of the team had craftsman's attitude toward their work. The project leader helped us work on the fringes of the software engineering process so we could be more productive. In that time we delivered a system that was not only ran legacy applications as before but had a new, open and extensible API and application execution environment and a modular hardware interface. It was delivered with very few problems considering the enormity of the change. The capability for future enhancement of new system was vastly improved. It was a tremendous growth experience for me; the only time I can say that I worked on what DeMarco and Lister call a "jelled team" (Peopleware 2nd ed. p. 123). I know first hand that the craftsmanship model not only makes software development and absorbing and exciting activity, but that it delivers great software. We all took tremendous pride in what we had done. I wish I could say that this experience led me on to become a master craftsman on the project and that project management saw the value of this approach and encouraged it. The potential was there but, for various reasons, the team broke apart and so did the company. The growing emphasis on short-term profitability and (later) survival nearly wiped out any supportive elements for craftsmen in the work environment. Software engineering is all about control. And managers feel more in control (especially under pressure) when stringent processes are in place. The outcome almost doesn't matter. When you can prove you followed and agreed upon process, no one is responsible for the failure of a project. When push comes to shove and corners have to be cut to meet deadlines, process goes out the window anyway but there is no personal professional discipline to maintain quality and long term viability. This is a very depressing environment for someone who wants to be a craftsman. I don't think these problems were unique to one company. They are more the symptoms of changes in the software development industry as a whole. Increased competition in the "marketplace" and the acceptance of "good enough software" has gotten us here. It has led to a lot of failure and waste, but we seem to be hooked on a short-term perspective. The aftermath has made me feel like blacksmiths must have felt during the Industrial Revolution. Software has quickly become a factory produced commodity; its production outsourced to the lowest bidders around the globe. It's very hard to find an employer that will accommodate craftsmen let alone actively promote that means of professional growth among its people. Maybe Pete McBreen's book will change things. But I don't hold out much hope. Times have changed too much. Too much damage to our infrastructure has been done. Perhaps the drawing of extinct species that appeared on the cover of "The Mythical Man-Month" would have been more appropriate for the cover of this book. I would love to be wrong.
Rating:
Summary: Read it and weep.
Review: First there was Fred Brooks' "Mythical Man Month". Then "Peopleware" by Tom DeMarco and Timothy Lister. Now, Pete McBreen's book, "Software Craftsmanship" takes its place at the head of this list of what I think are the best books on the human element in software development projects. I have been a professional software developer since 1979 when I joined a large telecommunications company. There was opportunity (if you wanted it) to learn software development much along the lines of McBreen's craftsmanship model. The best learning and greatest influence came from the great developers whose work I had the privilege of supporting, studying, maintaining or enhancing. I soon began to think of my profession as a craft, some mixture of art and science, and was encouraged by the work environment and the people to continually improve my skills toward designing and delivering reliable, maintainable, and extensible software applications. During my 21+ years with the company I gravitated toward projects and people that would help me along that path. The values that Pete McBreen promotes in this book became my values. Those values kept me going even as the work environment changed. There was always some degree of the software engineering mindset to contend with, but enough opportunity to exercise craftsmanship within that context to get plenty of job satisfaction and professional growth. But, as competition increased and the company became more "market driven" rather than "technology driven", the software engineering mindset began to dominate. There was a strong emphasis on ISO Certification and the development, maintenance and enforcement of elaborate processes and procedures to govern our work. Skilled developers were still valued, but the work environment favored interchangeable "resources" that could be plugged into the process wherever needed. The high point of my career came in the mid 1990's when I had the chance to work on a small team of five developers who worked closely together for over a year to design, code and deliver a complete rearchitecture of an existing system. Each member of the team had craftsman's attitude toward their work. The project leader helped us work on the fringes of the software engineering process so we could be more productive. In that time we delivered a system that was not only ran legacy applications as before but had a new, open and extensible API and application execution environment and a modular hardware interface. It was delivered with very few problems considering the enormity of the change. The capability for future enhancement of new system was vastly improved. It was a tremendous growth experience for me; the only time I can say that I worked on what DeMarco and Lister call a "jelled team" (Peopleware 2nd ed. p. 123). I know first hand that the craftsmanship model not only makes software development and absorbing and exciting activity, but that it delivers great software. We all took tremendous pride in what we had done. I wish I could say that this experience led me on to become a master craftsman on the project and that project management saw the value of this approach and encouraged it. The potential was there but, for various reasons, the team broke apart and so did the company. The growing emphasis on short-term profitability and (later) survival nearly wiped out any supportive elements for craftsmen in the work environment. Software engineering is all about control. And managers feel more in control (especially under pressure) when stringent processes are in place. The outcome almost doesn't matter. When you can prove you followed and agreed upon process, no one is responsible for the failure of a project. When push comes to shove and corners have to be cut to meet deadlines, process goes out the window anyway but there is no personal professional discipline to maintain quality and long term viability. This is a very depressing environment for someone who wants to be a craftsman. I don't think these problems were unique to one company. They are more the symptoms of changes in the software development industry as a whole. Increased competition in the "marketplace" and the acceptance of "good enough software" has gotten us here. It has led to a lot of failure and waste, but we seem to be hooked on a short-term perspective. The aftermath has made me feel like blacksmiths must have felt during the Industrial Revolution. Software has quickly become a factory produced commodity; its production outsourced to the lowest bidders around the globe. It's very hard to find an employer that will accommodate craftsmen let alone actively promote that means of professional growth among its people. Maybe Pete McBreen's book will change things. But I don't hold out much hope. Times have changed too much. Too much damage to our infrastructure has been done. Perhaps the drawing of extinct species that appeared on the cover of "The Mythical Man-Month" would have been more appropriate for the cover of this book. I would love to be wrong.
Rating:
Summary: Read it and weep.
Review: First there was Fred Brooks' "Mythical Man Month". Then "Peopleware" by Tom DeMarco and Timothy Lister. Now, Pete McBreen's book, "Software Craftsmanship" takes its place at the head of this list of what I think are the best books on the human element in software development projects. I have been a professional software developer since 1979 when I joined a large telecommunications company. There was opportunity (if you wanted it) to learn software development much along the lines of McBreen's craftsmanship model. The best learning and greatest influence came from the great developers whose work I had the privilege of supporting, studying, maintaining or enhancing. I soon began to think of my profession as a craft, some mixture of art and science, and was encouraged by the work environment and the people to continually improve my skills toward designing and delivering reliable, maintainable, and extensible software applications. During my 21+ years with the company I gravitated toward projects and people that would help me along that path. The values that Pete McBreen promotes in this book became my values. Those values kept me going even as the work environment changed. There was always some degree of the software engineering mindset to contend with, but enough opportunity to exercise craftsmanship within that context to get plenty of job satisfaction and professional growth. But, as competition increased and the company became more "market driven" rather than "technology driven", the software engineering mindset began to dominate. There was a strong emphasis on ISO Certification and the development, maintenance and enforcement of elaborate processes and procedures to govern our work. Skilled developers were still valued, but the work environment favored interchangeable "resources" that could be plugged into the process wherever needed. The high point of my career came in the mid 1990's when I had the chance to work on a small team of five developers who worked closely together for over a year to design, code and deliver a complete rearchitecture of an existing system. Each member of the team had craftsman's attitude toward their work. The project leader helped us work on the fringes of the software engineering process so we could be more productive. In that time we delivered a system that was not only ran legacy applications as before but had a new, open and extensible API and application execution environment and a modular hardware interface. It was delivered with very few problems considering the enormity of the change. The capability for future enhancement of new system was vastly improved. It was a tremendous growth experience for me; the only time I can say that I worked on what DeMarco and Lister call a "jelled team" (Peopleware 2nd ed. p. 123). I know first hand that the craftsmanship model not only makes software development and absorbing and exciting activity, but that it delivers great software. We all took tremendous pride in what we had done. I wish I could say that this experience led me on to become a master craftsman on the project and that project management saw the value of this approach and encouraged it. The potential was there but, for various reasons, the team broke apart and so did the company. The growing emphasis on short-term profitability and (later) survival nearly wiped out any supportive elements for craftsmen in the work environment. Software engineering is all about control. And managers feel more in control (especially under pressure) when stringent processes are in place. The outcome almost doesn't matter. When you can prove you followed and agreed upon process, no one is responsible for the failure of a project. When push comes to shove and corners have to be cut to meet deadlines, process goes out the window anyway but there is no personal professional discipline to maintain quality and long term viability. This is a very depressing environment for someone who wants to be a craftsman. I don't think these problems were unique to one company. They are more the symptoms of changes in the software development industry as a whole. Increased competition in the "marketplace" and the acceptance of "good enough software" has gotten us here. It has led to a lot of failure and waste, but we seem to be hooked on a short-term perspective. The aftermath has made me feel like blacksmiths must have felt during the Industrial Revolution. Software has quickly become a factory produced commodity; its production outsourced to the lowest bidders around the globe. It's very hard to find an employer that will accommodate craftsmen let alone actively promote that means of professional growth among its people. Maybe Pete McBreen's book will change things. But I don't hold out much hope. Times have changed too much. Too much damage to our infrastructure has been done. Perhaps the drawing of extinct species that appeared on the cover of "The Mythical Man-Month" would have been more appropriate for the cover of this book. I would love to be wrong.
Rating:
Summary: Approaching Programming as a Craft
Review: For a long time, computer programming has seemed to me to be more akin to writing a symphony or a novel than constructing a bridge, despite the fact that the industry has tried to make it like bridge-building by treating programming as "software engineering" and trying to use engineering methodologies to control development. Pete McBreen's book goes a long way toward explaining some of the software development phenomena we see, and why so much software engineering practice doesn't seem to work. I've written test tools for lower-level software, and I've noticed that the usual engineering methodologies do not explain what I've seen -- some people's code is simply better than others with fewer bugs (this variation in programmers has been known for a very long time), and I'm not sure how fundamental improvement can be legislated in a programming department or by the government. The conventional wisdom does not come to address one fact: one of the most important factors in the quality of software is who is writing it. McBreen acknowledges this and suggests a road by which more programmers can excel -- he believes such "stars" can be made. And it's interesting how he ties in the present trends in Extreme Programming and the Open Source development community, as well as the old Chief Programmer Team model, to bolster his thesis. McBreen presents an apprenticeship model for the development of programmers that actually has been done at times and places, although much less formally. My first programming job was something similar to this and stands in strong contrast to the world today where a new hire from college has a "software engineer" title and thrown into the deep end of the pool. I imagine many new graduates from MIT or Berkeley would be insulted at the idea of taking a job with a title "Programmer Trainee". Some of us have done just that. This book is a great read, and, as with so many good books, it's too short. He presents the craftmanship model but the book cries out for more explanation on implementation and what has happened when it is implemented. Many of us cannot implement company-wide changes ourselves, however, we can see programming in a new light and possibly begin change, in our own work, how it's approached and written.
Rating: 
Summary: Horrible logic
Review: I can't finish this book: It is one big mess of poor logic. I do believe that software is a craft, and I agree with the ACM's position on SWEBOK and Licensing. In general, the ACM has much better position papers than any argument you will find here. Take for example a paragraph title on page 88: "Software Engineering Has Been Trying to Kill COBOL for Decades". The author states that the Software Engineering (SE) view believes COBOL is a dead language with no future. Further, because of this view, organizations are having to move away from COBOL. Big problems here. First of all, the author doesn't tell us WHICH organizations are opposed to COBOL. I guess we are supposed to assume that there exists an official organization out there that has issued a recommendation against using COBOL. I have read a lot of SE literature, but I have never read an SE text that states that COBOL is a dead language with no future. In fact, SE texts are usually language neutral with the exception of talk about 'generations' of languages. Being for or against SE/Licensing has little bearing on your view of the value of COBOL. Secondly, just because there are people who believe that COBOL is a dead language with no future, how does that force an organization to move to a different technology? It doesn't, unless those people are in charge of a development shop, and I know a lot of people that believe COBOL is a dead language that also are against any sort of formalized methodology or SE. Want to know the main critiques of SE? Visit the ACM.
Rating:
Summary: Software Craftsmanship: a worthy goal
Review: I just spent this rainy afternoon reading "Software Craftsmanship ... The New Imperative" by Pete McBreen. The book's main theme is that the craft of software development has suffered from too much emphasis on the "horde approach" of software engineering, particularly on small teams. The Tayloristic perception of developers as common-denominator, replaceable resources is dismissed in favor of developers going through the apprentice - journeyman - master craftsman process. Such artifacts as certifications, licenses and diplomas are contrasted with the value of OJT in the right managerial environment. The stultifying affect of excessively detailed analysis and design at the beginning of a relatively small project is compared with a more iterative cycle of coded deliverables. The whole idea of specialization into analysts, designers, coders and testers is called into question for small projects. In fact, even the conceptualizing of software development as a project is discouraged. Better to realize that crafting an application is a never-ending process which may result in something which outlasts its own developers and development tools. Not that the developers should necessarily move on. McBreen encourages the notion that maintenance programming, far from being stigmatized as a menial task relegated to the novice programmer, should be a prestigious task given only to the best skilled, the best paid and the most experienced with the original development. It's not that everything in the book has never been said before. It draws on a rich bibliography including Fred Brooks and Edwards Deming. Its inspiration from "The Pragmatic Programmer" and eXtreme Programming are evident, but not overwhelming. I don't think I can give it a just review without quoting the whole book. If I had to choose one book as my software development manifesto, this would be it.
| 
