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
Coding Katas help to get onto the road towards mastery.
- Involve your team
Brown Bags and Lunch & Learns help to include everyone into your learning journey.
- Get people talking
Cory tells the story of an organization that introduced a book club for this.
- Get people learning and teaching
Apprenticeship Patterns is a great book that teaches apprentices to take care of their own journey towards personal mastery.
- Make it clean
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.
Thanks for a great writeup!
Can you expand on the second last paragraph? (..not to make a company process out of it)
Step 2,3 and maybe 4 seems to involve the organization, so what did he refer to? That it is to be a individual grassroot-movement not conciously managed by managers? Also what is the relevance of the Dreyfus-model in this regard?
Cory referred to the Dreyfus model there. You could make an overall process out of the on-the-job-training. the first step in the model is a the novice, that needs a clear set context for the problem to work. One thing that companies may tend to is to institutionalize a process for introducing new colleagues on their job. The process will clearly not work, as it is constantly changing depending on the needs of the developers in the organization. Since when people progress on the Dreyfus model, they can take care for the context themselves, seeing opportunities and solutions, which a novice cannot see. So, the process will surely be flawed from the start, since process sets the context for novices, which a more experienced or expert no longer needs. For an expert the process may as well get into her way.
Andy Hunt in Pragmatic thinking and Learning gives a great introduction into more details on the Dreyfus model. Worthwhile to read for further introduction and insights.