While I’m at the XP2010 in Trondheim, I try to update my blog with some of the interesting sessions I attend. This is a write-up from Cory Foy‘s session on Growing and Fostering Software Craftsmanship.
Cory starts the session that our industry today ended up in a picture that lets everyones avoid IT departments. He talks about Corey Haines‘ journey when he lost his job two years ago as an example. He raises the point of the Chaos Report that 24% of the IT projects are a success. That would be the same to ask the audience walk out of the room, with just quarter of them getting there. Another statistic shows that 84% of the projects in the software world are overrun. Today customers are happy with a software project being delivered on the previously set date.
As a case study he shares the story on a team he worked with. They collected all the different backlogs from the product marketing department, from the bug tracking system, from the customers, etc., prioritized it and ran a single iteration. The delivery date was already communicated to be June 2009. After having run a single iteration, the team could tell that the software just wasn’t going to be delivered by August of 2012.
Cory continues on talking about typing being not the bottleneck in the programming world. He quotes from Paul Graham, that “not solving the problems, but deciding which problems to solve” is the major challenge in software development.
Cory explains that a major shift happened from the early Software Engineering projects, where the hardware code and the physical engineering problems needed to be solved. Today, we face less problems with engineering the hardware, but the major challenge lies in the code itself. Therefore a paradigm shift happens so that we no longer need to build the perfect system, but have the system evolve over time.
He cites Michael Feathers from the Software Craftsmanship North-America conference in 2009. Feathers said, that Software Design is User Experience Design, when the users are software maintainers and development organizations that have to deal with the code.
Cory introduces the problems as lying in Code Quality, Collaboration, Sharing knowledge, and Responsibility. On Code Quality, code needs to reveal its intent. On Collaboration, he raises the problem how programmers are viewed from the business experts. The hacker picture is a view on software developers, which we need to change. On Sharing knowledge he introduces the bus number, that is the number of people that can get hit by a bus, before the project or organization runs into trouble. In most projects and organizations this number is no larger than one. On Responsibility, I was heavily reminded on the Zeroth Law of Professionalism, I wrote up in The Craft of Software Testing:
You should take responsibility for the outcome of every decision you make.
Cory continues by asking the question how craftsmanship can help with these problems. What’s the source of the problems? It’s us. It’S the fear of negative outcomes, which is just unacceptable. He raises the point of passion for what we’re doing. Taking a reflection on the Agile Manifesto,w hich was written nearly 10 years ago, what’s the situation now? Flowers? No, it’s just weird by the actions we took. The Software Craftsmanship manifesto was basically written to spread the message that we as software development professionals are responsible.
Cory introduces his five steps to foster Software Craftsmanship in our organizations:
- Start with you
- Involve your team
- Get people talking
- Get people learning and teaching
- Make it clean
Coding Katas help to get onto the road towards mastery.
Brown Bags and Lunch & Learns help to include everyone into your learning journey.
Cory tells the story of an organization that introduced a book club for this.
Apprenticeship Patterns is a great book that teaches apprentices to take care of their own journey towards personal mastery.
through peer learning, pair learning and swap programs.
With reference to the Dreyfus model of skill acquisition, he explains not to make a company process out of it. Since processes take care of the context, they just simply apply for the novice mind.
Finally and foremost, what software developers need to remember is to continuously delivering value to their customers.