Hi all,
Thanks for all your comments. Interesting debate. I'll try to address some of the things you wrote in a single response.
Christian Peacock wrote:
My question is - how do software craftsmanship and agile fit together comfortably? I kind of see agile as discouraging craftsmanship to some extent, given that all tasks are broken down into small pieces each with a business justification. Surely most business managers do not care about what's "under the hood" and simply want a system that does what they need right now with the lowest up-front costs? (Sceptical maybe, but mostly true in my experience.)
Agile and Craftsmanship are a perfect fit. Agile was never about delivering software faster. Agile has always been about delivering "quality" software faster. Agile without technical excellence is not Agile. If Agile had been adopted the way its originators envisioned it, maybe we wouldn't be talking about Software Craftsmanship today. Agile on its own should have been sufficient.
Agile is not a single thing. Agile is a combination of methodologies, practices, and values. A few Agile methodologies: Scrum, XP, DSDM, Crystal Clear, Adaptive Software Development, and Feature-Driven Development. Some of these methodologies focus more on the process side, like Scrum, and others have a bigger focus on the technical side, like XP. Some focus a little bit on both sides, like Crystal.
Unfortunately, due to commercial reasons, Agile adoptions (transformations) focused heavily on the process side and very little on the technical side. It's easier to sell process to managers and decision makers than it is to sell TDD.
Craftsmanship brings the focus back to the technical excellence, a thing has been forgotten by many "Agile" organisations.
Breaking down tasks into small pieces, each with a business justification is a great thing. However, that doesn't mean that they should be poorly implemented. This attitude is what is making companies that adopted Agile a few years ago complain about Agile. "Agile doesn't work. Things are taking too long to be done. We have too many bugs." Yes, same old problems caused by the same old approach to software: quick and dirty, until quick is not quick anymore. That is not what Agile is about.
So, the answer to your question is: Agile and Craftsmanship are a perfect combination. Agility in the process and agility in the code.
Christian Peacock wrote:
What I meant by agile discouraging craftsmanship, which may or may not be true, is that it doesn't seem to allow time for a developer to improve upon the way that they've done things if that improvement wouldn't be immediately apparent to the business. This is what I would like the author's opinion on.
There are a lot of things to say here and I don't think I'll be able to cover all in a reply to a post. I wrote a full book on it. ;)
1. If time/cost was not on the table, given the choice, the business would always choose quality
2. Even when warned that cutting corners would reduce the quality of the code, business will still expect quality and will be annoyed when bugs appear or they need to pay the price for cutting corners at a later stage.
3. In a truly Agile environment, the team is responsible to decide how things should be implemented and roughly how long it will take. The business care more about the latter. With this information, product owners can decide what they want to prioritise.
4. When deciding on the implementation of a task, a team of craftsmen would factor in the amount of time they need to do it properly.
5. Exposing all the nitty-gritty details of changes and refactorings to the business is an invitation to micro-management and totally discouraged.
6. Pragmatism is king. Developers love to "improve" things for the sake of improving, forgetting they have a software to deliver and a client paying for it. Refactorings should be localised and controlled. At the same time we don't want to build software on top of crap code, trying to re-write the entire system to add a small feature doesn't sound a very smart idea to me.
and
7. There is a myth that quality takes time. Asking inexperienced developers to all of a sudden test drive their code is not the same thing as having experienced TDD practitioners test driving code. Typing is not a bottleneck. The tools and practices we choose should not get in our way or slow us down. This is why we, craftsmen, take our own time to practice. No client should be paying extra because I decided to use TDD.
Christian Peacock wrote:
... how do you justify revisiting a piece of code given that agile mandates you only work on things that are defined within a sprint? ...
There are a few misconceptions here. Agile != Scrum. Sprint is a Scrum thing. Anything that is "mandated", by definition, is not Agile.
If the piece of code is related to the feature that we need to work on, then yes, revisiting (and refactoring if necessary) it is part of the job. If not, then it is just a waste of time. We should only refactor code if we need to touch it. Refactoring for refactoring sake is a pure waste of time and a bad use of someone else's money.
I cannot build another floor on top of my house without revisiting its foundation. If the foundation supports it, great I don't need to change anything. If it doesn't, than I need to do some work on it and that work will need to be added to the total cost of the project.
Tim Cooke wrote:
However, it is my experience that working in an 'agile' manner lends itself very well to allowing me to deliver high quality code. The primary reason for this is that it is the developers who provide the estimates for each Story. I get to say how long I think it will take me to deliver a feature, therefore I get to allow myself enough time to deliver it properly.
+1
Junilu Lacar wrote:
It really grates on me that this misconception seems to be more and more prevalent with the widespread adoption of Agile methods. To me it indicates that more and more people are doing things in the name of Agile that are, in fact, the exact opposite of what Agile is supposed to be. That agile discourages craftsmanship is absolutely and unequivocally NOT TRUE. Just look at the preamble of the Agile Manifesto: "We are uncovering better ways of developing software by doing it and helping others do it." If that isn't a definition of software craftsmanship, I don't know what is. I consider all of the original signatories of the Agile Manifesto as software craftsmen of the highest level. They are the master craftsmen of our field.
Couldn't agree more.
Junilu Lacar wrote:
I make sure we don't add crap code on top of already crappy code. And I hardly ever have to ask permission to do that and our business folks are just fine with it. As long as you are transparent and open about what you're doing and how you're doing it and as long as your approach is pragmatic, something that Sandro writes about in his book, there really is no contradiction between being Agile and spending time to go back and fix bad code and designs.
Also agree.
There are two things that are key very important in order to keep a healthy relationship with the business: Transparency and pragmatism.
Be pragmatic with your decisions, always remembering that some one is paying for the project. Don't over-engineer and don't go crazy trying to rewrite the entire application every time you find some code you haven't written. Don't only think about what it is best for the code. Think about the business priorities as well.