Software Craftsmanship: The New Imperative

Software Craftsmanship: The New Imperative

by Pete McBreen
Released August 2001
Publisher(s): Addison-Wesley Professional
ISBN: 0201733862

Read it now on the O’Reilly learning platform with a 10-day free trial.

O’Reilly members get unlimited access to books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial

Book description

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

    Table of contents

    1. Copyright
      1. Dedication
    2. Foreword
    3. Preface
    4. 1. Questioning Software Engineering
      1. 1. Understanding Software Engineering
        1. The Paradox of Software Engineering
          1. What Did Developers Do While Waiting for the Hardware?
          2. How Did Developers Speed Up Software Delivery Once the Hardware Became Available?
          3. Implications for the Development Process
        2. The Modern Definition of Software Engineering
          1. Good Enough Software—Software Engineering for the Masses
        3. Is Software Engineering a Good Choice for Your Project?
      2. 2. The Problems with Software Engineering
        1. Can Software Development Be Made Systematic and Quantified?
          1. But Surely We Can Automate Some Parts of Software Development, Right?
        2. The Hazards of the Good Enough Software Approach
        3. What Is the Alternative to Software Engineering?
      3. 3. Understanding Software Development
        1. Software as Capital
          1. Software Development Requires Teamwork
        2. Does the Division of Labor Work for Software Development?
        3. One Size Does Not Fit All
        4. Finding a More Applicable Metaphor Than Software Engineering
      4. 4. Finding a Better Metaphor Than Software Engineering
        1. The Craft of Software Development
        2. Parallels with Traditional Craftsmanship
        3. The Resurgence of the Craft of Software Development
    5. 2. Software Craftsmanship
      1. 5. Putting People Back into Software Development
        1. Craftsmanship Is About Getting Better at Software Development
        2. Craftsmanship Encourages Developers to Write Great Software
        3. A Call to Arms
      2. 6. Craftsmanship Is the Opposite of Licensing
        1. Craftsmanship Is Personal
          1. Peer Recognition and Recommendations Are the Route to Better Software
        2. Licensing Is an Illusion
          1. Licensing Is an Attempt to Solve the Wrong Problem
        3. Craftsmanship Focuses on the Individual
          1. The Problem of Software Development Is Abundance, Not Scarcity
    6. 3. Implications of Software Craftsmanship
      1. 7. How Craftsmanship Affects the Users of Systems
        1. Software Craftsmanship Works Because Software Is Easy to Copy
          1. The Challenge of the Mass Market
        2. Craftsmen Have a Different Relationship with Their Users
          1. But Remember, the Buyer Might Not Be the User
        3. Great Software Deserves to Be Signed
          1. Signing Our Work Changes Things
          2. Craftsmen Are Held Accountable for Their Work
        4. Craftsmen Need Demanding Users
          1. Users Will Benefit from Smaller, More Robust Applications
        5. Software Craftsmanship Leads to Collaborative Development
      2. 8. Customers Have a Different Relationship with Craftsmen
        1. Setting Realistic Delivery Dates
        2. Exposing the Fallacy of Good Enough Software
          1. There Is an Alternative
          2. Stop Choosing Developers Based on the Lowest Bidder
          3. Bad Clients Will Have a Hard Time Attracting Good Developers
        3. Allowing Software Craftsmen to Take Credit for Their Work
          1. Holding Developers Accountable for Their Work
        4. Start Exploiting the Difference in Productivity Between Developers
          1. Hire Small Teams of Good Developers
          2. What Is a Great Developer Really Worth?
        5. But How Do We Know How Good a Developer Really Is?
          1. Measure Developers by Their Delivery
        6. Customers Make a Cost/Quality Trade-off When Choosing Craftsmen
          1. Software Craftsmen Specialize in Different Types of Applications and Projects
        7. Customers Have Long Term Relationships with Software Craftsmen
          1. Being the Maintainer of an Application Is a High-Status Position
          2. Software Craftsmanship Values Long-Lived Applications
        8. Customer Interests Are Aligned with the Interests of Software Craftsmen
      3. 9. Managing Craftsmen
        1. Software Craftsmen Are Not Hired Hands
        2. Good Developers Are More Valuable Than Their Managers
          1. The Actual Process of Developing Software Cannot Be Defined in Detail
        3. Software Craftsmen Have a Different Relationship with Their Managers
        4. Managing Great Developers Is a Pleasure and a Privilege
          1. Good Managers Understand the Rhythm of a Project
        5. Software Craftsmen Like Creating Applications
          1. The Basics of Software Development Haven't Changed All That Much over the Years
          2. Experienced Old-timers Are a Vast, Untapped Resource
        6. Managing Software Craftsmen Is Different
          1. Craftsmanship Is Not About Planned Obsolescence
        7. Software Craftsmen Push for What They Need
      4. 10. Becoming a Software Craftsman
        1. Software Craftsmanship Is a Rejection of Narrow Specialization
          1. Specialization Slows Down Development and Introduces Errors
          2. Software Craftsmen Build Systems That Can Be Understood
        2. Craftsmanship Requires Dedication
        3. How Does a Person Become a Software Craftsman?
          1. Apprenticeship Is Much More Effective Than Schooling
          2. Journeymen Are the Key to the Craft Tradition
        4. The Craft Tradition Has Endured for Centuries
      5. 11. Mastering the Craft
        1. What Does a Master Software Craftsman Look Like?
        2. Use Your Old-timers
        3. Mastery Implies the Use of Stable Technologies
          1. Software Craftsmen Do Not Use Things Just Because They Are “the Latest and the Greatest”
          2. Software Engineering Has Been Trying to Kill COBOL for Decades
        4. Developing Mastery Takes Time
        5. Mastery Implies Taking Responsibility for Passing on the Craft
          1. Craftsmen Choose Their Apprentices and Journeymen
      6. 12. Apprentice Developers
        1. We Must Reverse the Decline in the Quality of Developer Training
          1. University Degrees Prepare Students for Academic Life, Not Real Projects
          2. Learning Software Development Is Not the Same as Being Taught How to Program
          3. If You Have to Send Beginners to Training, Make Sure It Is a Good Training Program
          4. Apprenticeship Is More Effective Than Training to Learn a Craft
        2. Becoming an Apprentice Is a Significant Step
          1. Craftsmen Control the Impact on Their Work Through Careful Selection of Apprentices
          2. Apprenticeship Is More About Learning Than About Teaching
          3. Apprenticeship Is Not Schooling
        3. Apprenticeship Instills Lifelong Learning
          1. Apprentices Learn by Reviewing the Work of the Master
        4. The Role of Apprentices
          1. Apprentices Start with Low-Risk Applications
          2. Apprentices Progress to Working on Customer Applications
          3. Progression for an Apprentice Occurs Through Demonstrated Competence
          4. Apprentices Are Not Cheap Labor
        5. An Apprenticeship Is a Significant Investment of Time and Energy
          1. Apprentices Become Journeymen When They Are Ready for That Responsibility
      7. 13. Journeymen Developers
        1. Where Journeymen Fit in the Craft Tradition
        2. Journeymen Developers
          1. Journeymen Rarely Work Alone
        3. Journeymen Are Focused on Delivering Applications
        4. Journeymen Play a Key Role in Software Craftsmanship
    7. 4. Repositioning Software Engineering
      1. 14. Software Engineering Projects
        1. Software Engineering Is Designed for Large Systems Projects
          1. Specialization Is Natural for Software Engineers
          2. Software Engineering Projects Still Use the Waterfall Process
          3. Programming Should Be a Mechanical Activity in Software Engineering Projects
          4. Software Development Is Not the Rate Limiting Step in Software Engineering Projects
        2. Software Engineering Projects Are Diverse and Varied
          1. Agile Methodologies Are an Alternative to Systematic Software Engineering Processes
      2. 15. Hazards of the Software Engineering Metaphor
        1. You Cannot Do Software Engineering on a Low Budget
          1. Faster, Better, Cheaper or on Time, on Budget, on Mars—Pick Two
          2. Believe the Estimates—Software Engineering Projects Take a Lot of Time
        2. Software Engineering Encourages Scientific Management
          1. Software Engineering Denigrates Anecdotal Evidence
        3. Software Factories: The Production Line for Software
          1. Cross-Project Reuse Is Very Hard to Achieve
        4. Reuse over Time Is Hazardous
        5. The Myth of the Standardized Software Development Process
          1. The Traditional Division of Labor Does Not Work for Software Development
          2. Best Practices Are a Holdover from the One Best Way of Scientific Management
          3. Best Practices Reinforce the Lesson That It Is Not OK to Fail Differently
          4. Best Practices Actively Hinder Process Innovation
        6. Software Engineering Forces Us to Forget the Individual
          1. Software Developers Are Not Interchangeable Resources
          2. Faking a Rational Development Process
        7. We Need More Variety in Our Development Processes, Not Less
          1. We Need to Break Away from the Software Engineering Waterfall Process
          2. The Waterfall Approach Is Hazardous Because It Requires a Large Team
          3. Small Teams Should Never Attempt to Use a Software Engineering Approach
      3. 16. Learning from Software Engineering
        1. Size and Complexity Matter
          1. Writing Applications Is Hard
        2. Applications Need to Be Well Structured
        3. Change Can Be Expensive Unless You Allow for It
        4. Communication Inside the Team and with Users Is Crucial
          1. Documentation Is Always out of Date and Wrong
          2. Manage Risk Using Incremental Development
        5. Producing Accurate Estimates Is Very Expensive
          1. Applying These Lessons to Software Craftsmanship
    8. 5. What to Do on Monday Morning
      1. 17. Experience—The Best Indicator of Project Success
        1. Choose Software Craftsmen Based on Their Reputations
          1. Trust the Craftsmen You Know to Recommend Other Craftsmen
          2. If Personal Recommendation Fails, Conduct a Wide Search
        2. Evaluate Craftsmen Based on Their Reputations and Portfolio
          1. Carefully Examine a Craftsman's Portfolio
        3. Auditioning a Software Craftsman
        4. Let Your Software Craftsman Pick the Rest of the Development Team
          1. The Craftsman Should Pick the Team Based on Personal Knowledge and Recommendations
          2. The Development Team Should Be “Experience Heavy”
          3. Be Very Afraid of Low-Budget Teams
        5. Collaborative Development
          1. Use Incremental Development to Keep the Application on Track
          2. Deal with Mistakes in Team Selection as Early as Possible
          3. Anyone Can Learn to Do Collaborative Development
        6. Avoid Bleeding-Edge Technology If At All Possible
        7. Paying for Experience
          1. Where Are All the Great Developers of Yesteryear?
          2. Rewarding Great Developers
          3. If You Want Great Developers, You Have to Pay Them Well
          4. But How Can We Afford to Pay for the Great Developers?
        8. Be Prepared to Be Amazed
      2. 18. Design for Testing and Maintenance
        1. Think Applications, Not Projects
          1. Applications Are Never Finished, Only Retired
        2. Maintenance Teams Should Refuse to Accept Bad Applications
          1. Maintainable Applications Need Automated Tests
          2. Start Making Your Applications Testable
        3. Design for Maintenance
          1. Experienced Developers Are Needed to Create Maintainable Applications
          2. Maintainable Applications Can Last for a Very Long Time
          3. Long-Lived Applications Require Long-Lived Development Tools
        4. Software Craftsmen Prefer Nonproprietary, Open Source Tools
          1. Java Is Hazardous to the Health of Your Projects
          2. Maintainable Applications Need a Stable Infrastructure
        5. Great Software Is Global
          1. Make Sure That Your Software Can Become Global
        6. Software Craftsmen Need to Fight Back Against Planned Obsolescence
        7. Great Software Needs to Be Given a Great User Interface
          1. Software Craftsmen Create Applications That Are Safe to Use
        8. Maintainable Software Is Easy to Diagnose
        9. The Hazards of Outsourcing
          1. Outsourcing Ignores the Reality of Software Development
          2. If You Have to Use Outsourcing, Insist on a Software Craftsmanship Approach
        10. You Can Still Use Outside Craftsmen to Create Your Application
        11. Maintenance Is the Most Important Part of the Life of Any Application
          1. Maintenance Needs to Be Made a High-Status Activity
          2. Craftsmen Have to Be Rewarded for Maintaining Applications
        12. Not All Software Has to Be Maintainable
        13. Design for Testing and Maintenance Is Not Rocket Science
      3. 19. Perpetual Learning
        1. Creating a Learning Environment
          1. Use In-House Tutorials to Create a Learning Environment
          2. Invite Everyone to Present Seminars on Interesting Topics
          3. The Learning Time Is Time Invested in Process Improvement
        2. Mastering the Craft of Software Development
          1. Encourage Participation in User Groups and Conferences
        3. Choose Training Courses Very Carefully
          1. Create a Relationship with the Instructor Prior to the Course
          2. Follow Up with the Instructor after Each Course
          3. If a Course Is a Failure, Fix the Problem
        4. Encourage Your People to Be Visible in the Software Development Community
          1. Encourage Participation at Conferences
          2. Encourage Your Developers to Become Instructors
          3. Encourage Your Developers to Get Their Ideas Published
        5. Becoming a Reflective Practitioner

    Product information

    • Title: Software Craftsmanship: The New Imperative
    • Author(s): Pete McBreen
    • Release date: August 2001
    • Publisher(s): Addison-Wesley Professional
    • ISBN: 0201733862