Customer Reviews

Software Craftsmanship: The New Imperative

5 star:		(15)
4 star:		(4)
3 star:		(4)
2 star:		(0)
1 star:		(1)

 

 

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.

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.

This is the book for those of us who've read all the standard works on classical software engineering methods and can't lose the suspicion that they're WRONG.

Software Craftsmanship: The New Imperative revealed the one important fact about how software engineering was derived from giant government projects in the 60's and 70's that I didn't know: those projects included building the hardware on which the applications would eventually run. The reason for the emphasis on long, detailed requirements and design documentation is that this was the best use of the dead time software engineers had while the machine and its compilers were being constructed. As soon as the box was ready an army of coders was given the detailed design documents and converted them page-by-page into source code.

Programmers who have ever wondered why they were being paid high salaries and then treated as mindless drones now have an historical explanation.

Pete McBreen isn't the first person to question standard procedures for developing commercial software. The Open Source movement has proven that high quality, useful software can come from developers using no specification documentation at all. The eXtreme and Agile methodologies have shown it is acceptable for specifications to change during the course of the project: Customers will be more pleased with the final product if they can revise their requirements as they see the product developing.

So who could possibly be holding on to a methodology that is demonstrably inappropriate for modern small software groups developing commercial products? Mr. McBreen fingers managers whose pay and prestige depend upon head count. Turning every project into a relay race with analysts, designers, programmers and testers guarantees many billable hours while intellectual property is passed on from group to group. Preferentially hiring young, inexperienced programmers and capping the salary rate ensures a bloated staff with high care and feeding needs. It's a provocative assertion that will certainly engender debate.

McBreen says he wants to join in the public conversation that already includes the voices of Richard Stallman, Linux Torvalds and Kent Beck. His intelligent analysis of the origins of classical software engineering and why it is no longer a good paradigm for commercial software development will help keep that conversation informed and productive, as well as lively.

* Books mentioned by Mr. McBreen include:
The Pragmatic Programmer by Andrew Hunt and David Thomas ISBN: 020161622X
The Inmates are Running the Asylum by Alan Cooper ISBN: 0672316498

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.

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.

"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.

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.

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.

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?

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.