Scribd
Upload
435 views

Software Craftsmanship

These notes are a condensation of the ideas found in Pete McBreen’s excellent book, Software Craftsmanship: the new imperative

Uploaded by

ramarao_pand
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
435 views

Software Craftsmanship

These notes are a condensation of the ideas found in Pete McBreen’s excellent book, Software Craftsmanship: the new imperative

Uploaded by

ramarao_pand
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 19

Software Craftsmanship

Carl Erickson, PhD


Atomic Object LLC

These notes are a condensation of the


ideas found in Pete McBreen’s
excellent book, Software
Craftsmanship: the new imperative
Software Craftsmanship
• The guild system worked for centuries
– an effective means of propagating arcane
knowledge
• Acknowledges that software is complicated
– and getting more so
• Puts people back in the picture
– instead of standardizing them away
• Recognizes that learning requires practice
June 2005 Atomic Object LLC 2
Implications of Craftsmanship
• Pride of work and visibility
– signing your work
• Taking responsibility
– not hiding behind a license agreement
• Relationship to users
– direct, not through intermediaries
• Reaching a mass market
– advantage of software over other crafts
June 2005 Atomic Object LLC 3
Delivery Dates & Quality
• Software projects often miss deadlines
– but less often miss estimates
• Unrealistic dates put craftsmen at risk
– reputation is what they live by
• Shipping with bugs
– comes from the “good enough” camp
• Select developers on quality, not cost
– Deming’s point about total cost, not project cost
June 2005 Atomic Object LLC 4
Sign Your Work
• Craftsman live by their reputation
– customers will choose the best
– developers will not work with bad customers
• Reputation requires visibility
– open source as prime model
• Accountability for mistakes
– learning requires feedback

June 2005 Atomic Object LLC 5


We’re Not All Equal
• Software engineering is about managing
large numbers of average developers
• Small teams of very good developers can
produce amazing applications
• The best developer is 10x better than an
average developer
– so pay them 10x as much and hire 1/10 of them

June 2005 Atomic Object LLC 6


The Need for Iteration
• Iterative, incremental delivery is the only
way
– paying 10x average means high expectations
– not sacrificing quality may mean schedule risk
• Small teams, faster delivery mean less risk
– than large teams with long delivery cycles
• Customers need to engage
– or risk wasting very expensive developer time
June 2005 Atomic Object LLC 7
Do-it-Right vs Debugging
• Which release is better?
– minimal features, rock-solid, functional
– feature rich, unstable, buggy
• Debugging your way to stability
– the “good enough” approach
• Booch’s observation on complex working systems
• Aligning interests
– customers want great software
– craftsmen want to build great software

June 2005 Atomic Object LLC 8


Software Craftsmanship
• General skills versus specialization
– complete job, start to finish, into maintenance
• A talented craftsman can know the system
– avoid the inefficiencies of specialization
• Pride of work means all aspects
• Craftsmanship requires mastery
– more than skills and knowledge
– attitude and commitment
– learning new things, readily admitting mistakes
– pass along knowledge
June 2005 Atomic Object LLC 9
Becoming a Craftsman
• Schools aren’t good, since they mostly ignore
– situated learning
– legitimate peripheral participation
• Apprentice to a master
– learn by doing real work
– and from other apprentices
– start simple, move up in task complexity as you learn
• Seek others who share passion, enthusiasm, and
pride

June 2005 Atomic Object LLC 10


Characteristics of Mastery
• Becoming productive quickly in a new tech
• Years of experience delivering and maintaining
– to gain insight into what makes a system last
• Not interested in unstable technologies
– cult of the new works against long-lived apps
– time to learn tools and tech must be paid off
• Willing to pass the craft along
– 1 craftsman x 2 journeymen x 2 apprentices

June 2005 Atomic Object LLC 11


The Apprentice
• More about learning than teaching
– load on the craftsman’s productivity
– self-reliant, coachable, enthusiastic
• Feedback from others
– crucial to learning
– reviewing work of the craftsman
• Ask good questions, bring new technologies
– so apprentices contribute and teach as well
June 2005 Atomic Object LLC 12
The Journeyman
• When you’ve learned enough as apprentice
– about technologies, practices, and
craftsmanship
• But still have things to learn from craftsmen
– and experience to gain
• Journeymen perform the bulk of work
– working together, or with a craftsman
– coaching and guiding apprentices

June 2005 Atomic Object LLC 13


What Can Software Engineering
Teach Craftsmanship?
• Size and complexity matter
– reducing team size reduces communication and
coordination burdens
– modular decomposition helps with complexity
• Programming in the large is different
– talented craftsmen and expressive language
shifts the boundary of what is “large”

June 2005 Atomic Object LLC 14


Learning from SE, cont.
• Structure is important
– OO was created to tackle complexity and size
– Ditto decomposition and design patterns
• Change is inevitable
– so embrace and handle it well (iterative process,
incremental delivery)
• Change before delivery is risky and expensive
– so deliver more frequently

June 2005 Atomic Object LLC 15


Learning from SE, cont.
• Communication within the team is crucial
– so don’t have teams spread across multiple sites
• Communication with customers is crucial
– so co-locate them with developers
• Craftsmanship is personal
– get people together
– let them build trust

June 2005 Atomic Object LLC 16


Learning from SE, cont.
• Documentation is always wrong
– so don’t waste time producing it
– produce documentation that will stay current
(test suites)
– keep the code readable
• Incremental development manages risk
– tackle unknowns quickly
– deliver early and often

June 2005 Atomic Object LLC 17


Learning from SE, cont.
• Accurate estimates are expensive
– Initial estimates based on high level functional
descriptions can be wrong by a factor of 4x
– With main requirements identified, reduced to factor of
2x
– With all requirements identified, reduced to factor of
1.5x
– With detail design done, reduced to 1.25x
• Believe the initial estimates
– Or alter the scope

June 2005 Atomic Object LLC 18


Conclusion
Software Craftsmanship offers an alternative
model to Software Engineering.

• Respects the importance of the individual


• Addresses the software crisis in a systemic
fashion
• Is a better match for most projects
• Has a successful historical precedent
June 2005 Atomic Object LLC 19

You might also like