- Save 10% on selected children’s books, compliments of Amazon Family Promotion exclusive for Prime members .
Software Craftsmanship: The New Imperative Paperback – 23 Aug 2001
- Choose from over 13,000 locations across the UK
- Prime members get unlimited deliveries at no additional cost
- Find your preferred location and add it to your address book
- Dispatch to this address when you check out
Special offers and product promotions
Frequently bought together
Customers who bought this item also bought
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
If you are a seller for this product, would you like to suggest updates through seller support?
From the Back Cover
By recognizing that software development is not a mechanical task, you can create better applications.
Today’s software development projects are often based on the traditional software engineering model, which was created to develop large-scale defense projects. Projects that use this antiquated industrial model tend to take longer, promise more, and deliver less.
As the demand for software has exploded, the software engineering establishment has attempted to adapt to the changing times with short training programs that teach the syntax of coding languages. But writing code is no longer the hard part of development; the hard part is figuring out what to write. This kind of know-how demands a skilled craftsman, not someone who knows only how to pass a certification course.
Software Craftsmanship presents an alternative―a craft model that focuses on the people involved in commercial software development. This book illustrates that it is imperative to turn from the technology-for-its-own-sake model to one that is grounded in delivering value to customers. The author, Pete McBreen, presents a method to nurture mastery in the programmer, develop creative collaboration in small developer teams, and enhance communications with the customer. The end result―skilled developers who can create, extend, and enhance robust applications.
This book addresses the following topics, among others:
Software Craftsmanship is written for programmers who want to become exceptional at their craft and for the project manager who wants to hire them.
About the Author
Pete McBreen is an independent consultant who actually enjoys writing and delivering software. Despite spending a lot of time writing, teaching, and mentoring, he goes out of his way to ensure that he does hands-on coding on a live project every year. Pete specializes in finding creative solutions to the problems that software developers face. After many years of working on formal and informal process improvement initiatives, he took a sideways look at the problem and realized, “Software development is meant to be fun. If it isn’t, the process is wrong.” Pete lives in Cochrane, Alberta, Canada and has no plans to move back to a big city.
What other items do customers buy after viewing this item?
Top customer reviews
It is a very thought provoking read. Reading this book won't give you practical ways of being a better developer, but will give you new ways of thinking about the profession of software development, and how this can be managed in a more people-centric way. I'd recommend it to anyone involved in the process of managing software developers, or who likes to think about these issues.
The essence of the Software Craftsmanship model is to stop trying to control a large number of average developers and instead employ exceptional developers who can self-organise. There is plenty of advice on how to organise a team around a master-craftsman and how to give the novice developers the path to becoming journeymen and eventually master craftsmen.
Anyone who has worked in companies with lots of warm bodies who cannot reliably get quality software shipped will understand why there is a need to change our attitude towards software development. This book is only controversial if you rely on the hierarchy of software engineering or want to sell certifications.
He contrasts SE, as he has defined it, with an individual craft approach to software development, using the language of guilds, apprenticeship, masters, and the like.
This premise is false. SE, correctly applied, selects the appropriate development processes and techniques for individual projects and tasks, large and small. SE is about selecting horses for courses. The simplistic 'SE bad, craft good' thesis put forward misrepresents most of what SE is about.
Disappointingly, the book contains hardly any experimental or anecdotal justifications that support the idea that the suggested craft approach is superior. It's unsubstantiated opinion.
The book comes over as the extended grumblings of an ageing 2- or 3-GL language programmer, passed over for promotion or technical preferment.
If these softer aspects of software development interest you, I'd recommend Gerald Weinberg's ageing 'The Psychology of Computer Programming', or his 'Becoming a Technical Leader', or DeMarco and Lister's 'Peopleware'.
Most Helpful Customer Reviews on Amazon.com (beta) (May include reviews from Early Reviewer Rewards Program)
If you are looking for directions on how to become one of the software programing elite, this is the map. This book is also an excellent guide for those trying to staff software projects with quality talent in that you'll know who the true craftsmen really are. Perfectly edited, filled with solid references, clear examples, and easily readable text.
(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.
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.
Look for similar items by category
- Books > Computing & Internet > Digital Lifestyle > Online Shopping > Amazon
- Books > Computing & Internet > Programming > Languages & Tools
- Books > Computing & Internet > Programming > Software Design, Testing & Engineering > Functional Programming
- Books > Computing & Internet > Programming > Software Design, Testing & Engineering > Software Architecture
- Books > Science & Nature > Engineering & Technology > Production, Manufacturing & Operational