Software Craftsmanship: The New Imperative

Front Cover
Addison-Wesley Professional, 2002 - Computers - 187 pages

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:

  • Understanding customer requirements
  • Identifying when a project may go off track
  • Selecting software craftsmen for a particular project
  • Designing goals for application development
  • Managing software craftsmen

Software Craftsmanship is written for programmers who want to become exceptional at their craft and for the project manager who wants to hire them.



0201733862B07242001

From inside the book

Selected pages

Contents

Questioning Software Engineering
1
Understanding Software Engineering
3
The Paradox of Software Engineering
4
The Modern Definition of Software Engineering
7
Is Software Engineering a Good Choice for Your Project?
8
The Problems with Software Engineering
11
Can Software Development Be Made Systematic and Quantified?
13
The Hazards of the Good Enough Software Approach
15
Mastery Implies Taking Responsibility for Passing on the Craft
90
Apprentice Developers
93
Becoming an Apprentice Is a Significant Step
97
Apprenticeship Instills Lifelong Learning
98
The Role of Apprentices
100
An Apprenticeship Is a Significant Investment of Time and Energy
102
Journeymen Developers
105
Where Journeymen Fit in the Craft Tradition
106

What Is the Alternative to Software Engineering?
16
Understanding Software Development
17
Software as Capital
18
Does the Division of Labor Work for Software Development?
20
One Size Does Not Fit All
21
Finding a More Applicable Metaphor Than Software Engineering
23
Finding a Better Metaphor Than Software Engineering
25
The Craft of Software Development
26
Parallels with Traditional Craftsmanship
28
The Resurgence of the Craft of Software Development
29
Software Craftsmanship
31
Putting People Back into Software Development
33
Craftsmanship Is About Getting Better at Software Development
34
Craftsmanship Encourages Developers to Write Great Software
35
Craftsmanship Is the Opposite of Licensing
37
Licensing Is an Illusion
39
Craftsmanship Focuses on the Individual
41
Implications of Software Craftsmanship
45
How Craftsmanship Affects the Users of Systems
47
Software Craftsmanship Works Because Software Is Easy to Copy
48
Craftsmen Have a Different Relationship with Their Users
50
Great Software Deserves to Be Signed
52
Craftsmen Need Demanding Users
53
Software Craftsmanship Leads to Collaborative Development
54
Customers Have a Different Relationship with Craftsmen
55
Exposing the Fallacy of Good Enough Software
56
Allowing Software Craftsmen to Take Credit for Their Work
59
Start Exploiting the Difference in Productivity Between Developers
60
But How Do We Know How Good a Developer Really Is?
61
Customers Make a CostQuality Tradeoff When Choosing Craftsmen
63
Customers Have Long Term Relationships with Software Craftsmen
65
Customer Interests Are Aligned with the Interests of Software Craftsmen
67
Managing Craftsmen
69
Software Craftsmen Are Not Hired Hands
70
Software Craftsmen Have a Different Relationship with Their Managers
71
Managing Great Developers Is a Pleasure and a Privilege
72
Software Craftsmen Like Creating Applications
73
Managing Software Craftsmen Is Different
75
Software Craftsmen Push for What They Need
76
Becoming a Software Craftsman
79
Software Craftsmanship Is a Rejection of Narrow Specialization
80
Craftsmanship Requires Dedication
81
The Craft Tradition Has Endured for Centuries
83
Mastering the Craft
85
What Does a Master Software Craftsman Look Like?
86
Mastery Implies the Use of Stable Technologies
87
Developing Mastery Takes Time
89
Journeymen Are Focused on Delivering Applications
107
Journeymen Play a Key Role in Software Craftsmanship
108
Repositioning Software Engineering
109
Software Engineering Projects
111
Software Engineering Is Designed for Large Systems Projects
112
Software Engineering Projects Are Diverse and Varied
114
Hazards of the Software Engineering Metaphor
117
Software Engineering Encourages Scientific Management
119
The Production Line for Software
121
Reuse over Time Is Hazardous
122
The Myth of the Standardized Software Development Process
123
Software Engineering Forces Us to Forget the Individual
126
We Need More Variety in Our Development Processes Not Less
128
Learning from Software Engineering
131
Applications Need to Be Well Structured
133
Communication Inside the Team and with Users Is Crucial
135
Producing Accurate Estimates Is Very Expensive
136
What to Do on Monday Morning
139
ExperienceThe Best Indicator of Project Success
141
Choose Software Craftsmen Based on Their Reputations
142
Evaluate Craftsmen Based on Their Reputations and Portfolio
143
Auditioning a Software Craftsman
144
Let Your Software Craftsman Pick the Rest of the Development Team
145
Collaborative Development
147
If At All Possible
148
Paying for Experience
149
Be Prepared to Be Amazed
152
Design for Testing and Maintenance
155
Think Applications Not Projects
156
Maintenance Teams Should Refuse to Accept Bad Applications
157
Design for Maintenance
158
Software Craftsmen Prefer Nonproprietary Open Source Tools
160
Great Software Is Global
161
Software Craftsmen Need to Fight Back Against Planned Obsolescence
163
Maintainable Software Is Easy to Diagnose
164
The Hazards of Outsourcing
165
You Can Still Use Outside Craftsmen to Create Your Application
167
Not All Software Has to Be Maintainable
169
Perpetual Learning
171
Mastering the Craft of Software Development
173
Choose Training Courses Very Carefully
174
Encourage Your People to Be Visible in the Software Development Community
176
Becoming a Reflective Practitioner
178
Epilogue
179
Acknowledgments
181
Index
183
Copyright

Other editions - View all

Common terms and phrases

About the author (2002)

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. 0201733862AB07092002

Bibliographic information