1. Software Craftsmanship: The New Imperative
By: Pete McBreen
Notes by Meagan Waller for 8th Light Software Apprenticeship

2. Questioning Software
Engineering
• Paradox of software engineering: developers had to wait for hardware, by the end
hardware people are waiting for software.
• Software engineering is the application of a systematic, disciplined, quantifiable
approach to development, operation, and maintenance of software.
• You need to be selling millions of units in a competitive market where customers
buy on a basis of reviews and marketing rather than on detailed, side-by-side
comparisons of products.

3. The problems with software
engineering
• Assumption that a systematic, disciplined, and quantifiable
approach is the only possible approach.
• Software development is not a defined process
• Most parts of software development that can automated
have already been automated.

4. Understanding Software
Development
• The process of developing software involves taking both explicit and tacit
knowledge and embodying it in software.
• Software development requires teamwork
• The more a task is broken down into small steps the more time is spent passing
information from one person to another.
• Software development is variable -- not possible to cover range of software
projects with a single software development process
• Software engineering was a response to solve problems of large groups working
on multi-year projects, software development uses relatively small teams.

5. Finding a better metaphor than
software engineering
• A recurring theme among software developers is that it’s
really a craft.
• A lot of technical knowledge is needed to be effective, but
that knowledge is ineffective without the practiced skill with
the tools and an eye for the aesthetics of the items being
produced.

6. Software craftsmanship
• Key failing of software engineering is that it fails to place people at the
center of the software development process.
• Skilled developers are the only way to bridge the gap between
requirements and design.
• Part of the problem with finding skilled developers is the notion that
software development is easy, with only knowledge of the particular
technology and obscure syntax being needed.
• Having knowledge isn’t the same as having the skill -- this is where
craftsmanship comes in.

7. Putting people back into
software development
• Apprenticeships are situated learning, the apprentice takes
over the easy, mundane tasks and then absorbs through
observation and supervised practice.
• Craftsmanship encourages developers to write great
software
• We must insist that developers really know their craft
before we trust them to create systems for us or with us.

8. Craftsmanship is the opposite of
licensing
• Craftsmanship is personal, peer recognition and recommendations are the route
to better software.
• Passing an exam says nothing about a developers ability to develop a useful
application, only that they’ve learned to pass the exam.
• Licensing is an illusion, it fails because it claims to make an objective measurement
of a software developer.

9. Implications of software
craftsmanship
• In applying the apprenticeship model to becoming a
craftsman we can draw on the experiences and cultures of
other crafts.
• We need to put pride back in software development
• Craftsmanship is not a rejection of science and engineering
but a subtle blending of man, machine, and knowledge to
create useful artifacts.
• Humans regaining control over their environment rather
than machines dictating what is possible.

10. How craftsmanship affects the users
of systems
• Software craftsmanship works because software is easy to
copy.
• For many users, a smaller, less feature-rich but more robust
application that remains stable over time would be a better
solution than a shrink-wrapped application
• Using good design and careful modularization developers
have produced many tools that have lasted for years.

11. Craftsman have a different
relationship with their users
• Puts useful, sharp, tools in the hands of the user and recognizes that over time
everyone is becoming more technically astute.
• Develop a close working relationship with a small number of uses, make them
excited by creating the best possible application for them, then the product is
ready for the mass market.
• Software craftsmanship is about putting responsibility and pride back into the
software development process,“signing our work” means craftsman are held
accountable for their work.
• Software craftsmanship leads to collaborative development.

12. Customers have a different
relationship with craftsmen
• Realistic delivery dates are set
• Craftsmen should never get to the situation of knowing about lots of
mistakes, but ignoring them because it’s cheaper and faster to not
bother fixing them.
• Stop choosing developers based on the lowest bidder, awarding work
based on reputation for delivery will improve the quality of the
software.
• Bad clients will have a hard time attracting good developers

13. Customers have a different
relationship with craftsmen
• Rather than being known for their degrees, membership, or certificates the real
credentials for developers consists of the applications on which they have worked.
• Better software won’t be available unless we give developers feedback on how
their creations work in practice.
• Hire small teams of master craftsman instead of 30+ average programmers and
pay them what you would’ve paid the average programmers
• Without rewards to match their ability, talented people divert their energies into
other areas.

14. Customers have a different
relationship with craftsmen
• In order to determine how good a developer is you need to
look at their portfolio, talk to their colleagues, previous
customers, and managers.
• Good developers make all the difference between success
and failure, large teams taking a long time are at a higher risk
for failure
• Measure developers by their delivery, you want “frequent,
tangible, working results’ called incremental development.

15. Customers have a different
relationship with craftsmen
• As new features are developed and validated they can go live, software craftsmen take this stand
because it’s easier and less risky to add functionality to a solid foundation than it is to debug
your way to stability after release.
• A customer sets expectations for a project and the resulting application with a clearly stated
mission profile.
• Customers benefit from the long-term relationship with a developer, the best person to
maintain an application is the one who developed it.
• Becoming the maintainer of an application enhances your reputation.
• Software craftsmanship values long-lived applications, customers benefit from having applications
that can be modified quickly to meet changing business needs

16. Managing craftsmen
• Scientific management is not an appropriate way to manage software developers.
• Good managers understand the rhythm of a project. Good managers also know
that command and control is out, conversation is what works.
• We keep repeating the mistakes of the past because we lack developers who
remember the mistakes made the first time around.
• Craftsmanship is not about planned obsolescence, rather encourages and values
long-lived stable applications
• Managers who work with small teams of craftsmen versus a huge group of average
programmers get rapid delivery of high-quality robust applications.

17. Becoming a software craftsman• The mark of a true craftsman is one who can take a complete job from start to finish
• Always be willing to learn and are able to admit their own mistakes.
• Newcomers start as apprentices to a master craftsman.
• Journeymen are craftsmen who have finished their apprenticeship but have not yet mastered
their craft, become a master by producing masterpieces to base your reputation on
• Master craftsmen accept the responsibility of taking on apprentices and involving them in work
they do.
• Software engineers follow the book and do what you tell them, master craftsmen asks lots of
questions and then deliver what you really need (as opposed to what you actually asked for.)

18. Mastering the craft
• A true craftsman will become productive quickly in any technology that
is reasonably close to what they were already familiar with.
• By valuing the developers who have been around for a long time we
give them a real incentive to master their craft.
• Offers an alternative to “quick fix” technology solutions of software
engineering.
• Wary of proprietary technologies because they might not available
down the road when they are needed.

19. Mastering the craft
• Mastery is the ability to create and successfully enhance
robust, high quality applications, including maintenance for
users, and nurturing other developers to be able to become
a maintainer.
• Craftsman choose their apprentices and journeymen
because the relationship is expected to last for a long time.
• In taking on an apprentice a developer acknowledges that
they’ve become a master.

20. Apprentice Developers
• We need to reverse the decline in quality of developer training
• University courses provide theoretical background, but new graduates have to
learn the craft of software development
• The lack of context in programming classes hinders the development of wisdom.
• Once trainees have a good grounding in the craft of software development, they
will know what questions to ask when they become members of the project
teams
• Apprenticeship is more effective than training to learn a craft, trainees find
someone to go to with their questions and puzzles, software craftsmanship
acknowledges that the search is very important and significant step.

21. Apprentice developers
• Craftsmen take on only eager apprentices who are willing to learn the craft of software
development.
• Required to be productive members of the team and they learn how to ask for help from either
other apprentices or journeymen. Learn by reviewing the work of the master, reading, and
asking intelligent questions.
• Bring an enthusiasm and drive for learning that infects everyone else.
• Start with low-risk applications then progress to working on customer applications by
demonstrating competence
• Instilled with proper attitude and values before moving on to independent work

22. Journeymen developers
• Practicing the craft to develop the technique and artistry
needed to become a master craftsmen.
• Remain aware of and contribute to the entire process of
application development, even if they want to specialize.
• Maintaing and enhancing live applications give the best
environment for improving their craft
• Provide the bulk of the training and mentoring to
apprentices on behalf of the craftsmen.

23. Repositioning software
engineering
• Software craftsmanship is a complement software
engineering.
• Some problems truly require a large team to deal with all
their complexities and interdependencies.
• For projects smaller than 100 developer years a software
craftsmanship approach is more effective.

24. software engineering projects
• Involve both hardware and software
• Designed for large systems projects
• Specialization is natural for software engineers
• Agile Methodologies focus attention on the individuals in the
software development team and the quality of their
interactions with their customers and users.

25. Hazards of the software
engineering metaphor
• You can’t do software engineering on a low budget (pick two -- faster, better, cheaper)
• Encourages scientific management
• Downplays the value of the only mechanism we have for really understanding and improving
software development --anecdotes that developers tell one another.
• Manufacturing software is easy, the difficulty lies in creating and evolving the design for the
software in collaboration with the users of that software.
• Reuse over time is hazardous -- “software should be considered correct until it’s shown to be at fault”
might work for mechanical things, but not for software.

26. Hazards of the software
engineering metaphor
• By creating artificial specialities with narrow skills sets, software engineering makes it impossible
for one person to understand the entire application.
• “Best Practices” works in the mechanical world not in software. It reinforces that it’s not OK to
fail differently and it actively hinders process innovation
• Forces us to forget the individual, software developers are not interchangeable resources
• We need more variety in our development processes, not less.
• We need to break away from the “waterfall process”, with it it’s easy to consume half the
available time before anything can be demonstrated to the users.

27. Learning from software
engineering
• Rather than attempt to build really large, monolithic applications the craft approach seeks to
build small applications that can then build on and enhance one another
• No matter the size of the application design and programming are dominant activities.
• Craft projects do not need to incur the expense of maintaining requirements traceability, while
traceability is necessary in software engineering.
• Communication inside the team and with users is crucial
• Producing accurate estimates is very expensive, the most challenging part is that customers and
managers do not want to believe the initial estimates.

28. experience -- The Best indicator of
project success
• For best chance of project success, choose a team that has just successfully delivered an
application for you.
• Trust the craftsmen you know to recommend other craftsmen, if that fails conduct a wide
search.
• Carefully examine a craftsman’s portfolio, you are looking for evidence of success on similar-size
projects.
• Don’t interview a craftsmen, let them audition for the role.
• Let your software craftsmen pick the rest of the development team based on personal
knowledge and recommendations, the team should be “experience heavy” Also, be very afraid of
low-budget teams.

29. experience -- The Best indicator of
project success
• Use incremental development to keep the application on track, this way the user are in a better
position to steer the application in the desired direction.
• Deal with mistakes in team selection as early as possible, talk about the issues and coach the
affected individuals. If the behavior doesn’t change quickly remove those individuals, a smaller,
“healthy” team is more effective than a fully staffed “sick” team.
• Anyone can learn to do collaborative development, we’re not asking for developers to become
extroverts, they are expected to show their colleagues what they are working on, look at their
colleagues work to see what they can learn.All this takes is some time to get to know all the
members of a time, having a small team makes this easier.

30. experience -- The Best indicator of
project success
• With the exception of winning big in a start-up, software developers
have to move into another field if they are really ambitious because of
lack of incentive, salary-wise, to stick around.
• If you want great developers you have to pay them well, stop overpaying
average developers.
• The promise of software craftsmanship is the creation of small, hyper
productive development teams that can create amazing applications

31. Design for testing and
maintenance
• Think applications, not projects.Applications are never
finished, only retired.
• Maintenance teams should refuse to accept bad applications.
• Maintainable applications need automated tests, so start
making your applications testable.

32. Design for testing and
maintenance
• Experienced developers are needed to create maintainable applications which can last for a very
long time.
• Long-lived applications require long-lived development tools.
• Software craftsmen prefer nonproprietary, open source tools.
• Maintainable applications need a stable infrastructure, however that goal isn’t really feasible so
we have to settle for encapsulating the platform dependent code.Three parts of the
infrastructure need to be encapsulated: the user interface, the database, and the operating
system

33. Design for testing and
maintenance
• Great software is global, so make sure that your software can become global.
• Software craftsmen need to emphasize that it is possible to create applications that can last for
long periods.
• Design for maintenance means that we design applications that get out of the way of expert
users, while allowing novices to use them safely, they create applications that are safe to use.
• Maintainable software is easy to diagnose, possible to rapidly identify the causes of any failures.
• Outsourcing is probably the opposite of design for maintenance, it ignores the reality of
software development, if you must though, insist on a software craftsmanship approach.

34. Design for testing and
maintenance
• A safer alternative to outsourcing is to hire a craftsman and a development team
to create an application on the condition that your people serve as apprentices on
the project.
• Maintenance is the most important part of the life of any application, craftsmen
have to be rewarded for maintaining applications.
• Software always has to be testable, but sometimes it is okay to create a bleeding-
edge application.
• Craftsmen like creating maintainable applications because doing so allows them to
become very responsive to their users.

35. perpetual learning
• Create a learning environment with in-house tutorials, allowing everyone to present seminars
on interesting topics, and knowing that the learning time is time invested in process
improvement.
• Mastering the craft of software development by encouraging participation in user groups and
conferences.
• Choose training courses very carefully by creating a relationship with the instructor prior to
the course, follow up with the instructor after each course, if a course is a failure then fix the
problem
• Encourage your team to be visible in the software development community by participating at
conferences, becoming instructors, and getting their ideas published.