Although I have signed the "craftsmanship manifesto" I have misgivings about it. Though I agree that we need to do quality work, I don't think that's necessarily what's holding our teams back from delivering more value to the business, and therefore cannot be the sole focus of our software process improvement initiatives--I think that the real points of pain in the industry are long feedback cycles and inadequate communication. So I went to the Craftsmanship session with a bit of a bias. The delivery of Cory's talk was excellent--he was energetic, well-spoken, enthusiastic, and used his slides very well. He started with storytelling--in fact, a story about a business executive who sat next to him on the plane, complaining about internal software staff who just wouldn't deliver the business value he needed. Instead, this executive was frustrated by all the roadblocks the software teams were mounting (including questioning/challenging projects, technical veto of proposed solutions, and technical debt). He went on to ask whose fault it was that we have so much technical debt... and of course it's us. He said that this movement was kicked off by Robert C Martin's tirade at some conference that we need "quality over crap!". It's the design of our software that we need to focus on. I liked Cory's statement that we need to know what problems to focus on/solve, because there's no shortage of problems--but there is a shortage of time and energy, so prioritization is key. My notes also have a re-write of the agile manifesto stating "delivering value over working software over comprehensive documentation", but I don't know if Cory brought that up--I know it's something Kent Beck mentioned at the recent Lean Startup conference... Unfortunately, the rest of what I see on my notes are criticims of the talk--a complaint that the "craftsmanship" is gender biased, and a complaint that the quality of our code is not why the business is frustrated with us. It was hard for me to wait until the Q&A section of the talk, because I just kept thinking of more and more reasons why a focus on Craftsmanship seems wrong to me. So my question to Cory was something like: if you could go back to that business executive and show him how you'd cleaned up all the code for the software teams he'd been complaining about, do you think he'd be happy? I think not--I think he wants responsiveness and the ability to deliver the right things. I think there needs to be a balance between agility and craft--and in fact, we can have both--but I think it's too seductive to focus on the things we have direct control over. The biggest problems, the biggest benefits, are related to cycle time--and fixing those problems involves the whole company.
Photo credit Hubert Baumeister.
3 comments:
Excellent post, and I think it reflects something that has been concerning me about craftsmanship lately. It has the potential to be so much more than another channel about xp practices and clean code. One thing I look for in discussions is whether they focus on Pete McBreen's book "Software Craftsmanship" or Uncle Bob's "Craftsmanship over Crap" quip as being an important moment in the software craftsmanship movement. If you look at when the mailing list started, and who it was started by it naturally took on a character reflecting that clean code community. Topics presented in McBreen's book (such as the focus on maintaining brownfield software products long term, the journeyman and master phases of a development career, long term relationships with software products, customers and domains, are rarely discussed and in some cases dismissed. To me Software Craftsmanship can be an exciting and valuable model for the future of the profession rather than just another mailing list reminding me to write tests first. If software craftsmanship is to be nothing more than yet another bunch of agilists talking about clean code then we don't really need it. Any discussion about software craftsmanship should be focussed on what it brings beyond all the other xp/agile/clean code movements. I am interested in what makes SC special, and how it helps both business, and the profession of software be more effective. That I should write tests, and refactor, and not write more than I should, and continually integrate etc etc, is learned, accepted and practically goes without saying now. The agile, xp, clean code movements , and SC lite, have helped answer some of the easy questions, now I think it is time to go back to McBreen's book and try and tackle some of the trickier questions, the ones less related to code, and more focussed on the business and people in software development.
(To be honest, this was a similar criticism that I had to the ADS project.)
Cory quoted Paul Graham about not solving the problems, but deciding which problems to solve. To me this implies shifting focus slightly further away from the keyboard, and a little closer to the customer. Rather than code katas, how about customer katas, or communication katas? Rather than getting your team of geeks together to talk about technology, about gathering people from different departments to talk about funding, marketing and supporting products? Rather than learning and teaching new programming languages how about getting to grips on the language used in business? Instead of swapping into another development team, how about swapping into support or marketing, or design for a while?
Thanks, Kurt. I'll have to add McBreen's book to my library...
Post a Comment