Software craftsmanshippresentation

Software Craftsmanship: The New ImperativeBy: Pete McBreen

Notes by Meagan Waller for 8th Light Software Apprenticeship

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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


• 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.


• 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.


• 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

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.

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.)

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.


• 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.


• 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

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.


• 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


• 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.


• 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.

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.

Documents

Software craftsmanshippresentation