Rating: 
Summary: Software Craftsmanship : The New Imperative
Review: This book presents a totally new angle on software engineering career. The model is of a craftsman, like a woodworker (as pictured on the cover), starting as an apprentice, then on to journeyman and finally master. It recasts projects in this new light and shows advantages over the current software engineering "programming by horde" model. It also presents the traits of a craftsman, perpetual learning, teaching, belief in quality, embracing, but also being critical of new technologies.If you really don't believe in the current "anyone could do your job" management view of software engineering you will find this book, and it's mindset, a refreshing change. Software is an art. Professional engineers have a lifelong passion and respect for that art. There are several books that present this point of view, foremost is The Pragmatic Programmer, which is also an excellent book. If you have to decide between the two (and you really shouldn't) I would pick The Pragmatic Programmer. Spend the money, buy both, they complement each other and you won't regret either purchase.
Rating:
Summary: One Size Doesn't Fit All For Software Development
Review: This is a one sentence summary of the book. But what does it mean? McBreen gives a well structured argument that Software Engineering and Software Craftsmanship are two different things. The former is for large scale, mission critical projects, where as the latter is for business applications. Having worked on both kinds of systems, I can say that the author is dead on. The typical government/defense project uses large (over 100 engineers) development teams with cutting edge software and hardware. These situations call for the engineering approach because the software is not the dominating cost. However, business applications are usually built by small teams using stable technology (or they should be as the auther points out). The craft approach emphasizes delivery high quality, easily modified applications by teams lead by master craftsmen. The craftsman puts his reputation on the line each time his team delivers an application, for he is responsible for the journeyman and apprentices that work under him. This accountability to the customer builds trust between the two. Too many applications are built and handed off to someone else to maintain. Not so in the craftsmanship model. The team that developes the application stays with it through its lifetime or until they have sufficiently trained the next maintainer. The auther draws a strong parallel to Open Source development to support this concept. While the concepts the author presents ring true, it is going to be difficult to switch on a dime from software engineering to software craftsmanship. Luckily, the final chapters of the book give some gradual steps that can be taken toward the craft approach: hiring people that you know to have a good reputation, design for testing and maintenance, and continual learning. These would also benefit software engineering, but they are necessary for the craft approach.
Rating:
Summary: One Size Doesn't Fit All For Software Development
Review: This is a one sentence summary of the book. But what does it mean? McBreen gives a well structured argument that Software Engineering and Software Craftsmanship are two different things. The former is for large scale, mission critical projects, where as the latter is for business applications. Having worked on both kinds of systems, I can say that the author is dead on. The typical government/defense project uses large (over 100 engineers) development teams with cutting edge software and hardware. These situations call for the engineering approach because the software is not the dominating cost. However, business applications are usually built by small teams using stable technology (or they should be as the auther points out). The craft approach emphasizes delivery high quality, easily modified applications by teams lead by master craftsmen. The craftsman puts his reputation on the line each time his team delivers an application, for he is responsible for the journeyman and apprentices that work under him. This accountability to the customer builds trust between the two. Too many applications are built and handed off to someone else to maintain. Not so in the craftsmanship model. The team that developes the application stays with it through its lifetime or until they have sufficiently trained the next maintainer. The auther draws a strong parallel to Open Source development to support this concept. While the concepts the author presents ring true, it is going to be difficult to switch on a dime from software engineering to software craftsmanship. Luckily, the final chapters of the book give some gradual steps that can be taken toward the craft approach: hiring people that you know to have a good reputation, design for testing and maintenance, and continual learning. These would also benefit software engineering, but they are necessary for the craft approach.
Rating:
Summary: The Programmer as Artisan, not Engineer
Review: 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
| 
