A question for Sandro Mancuso

[Christian Peacock]

Hello Sandro,

Your book looks really fascinating, and anything that encourages people to take pride in their work is a good thing.

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

Thanks,
Chris.

[Tim Cooke]

Christian Peacock wrote:Surely most business managers do not care about what's "under the hood"

I don't believe that is ever true. While they may not be interested in, or even understand, the intricacies of your solution, there is always the implicit expectation that your code is of good quality.

Let's explore what it means to ignore craftmanship. You don't bother writing tests for your code, you write functional (maybe) but otherwise unreadable and difficult to maintain code, your code is a mess. Think about what you're saying to your business managers: "Here's your application. I think it works, maybe". Fast forward 6 months and now your business manager wants to change that feature you wrote. But it's not you doing the work this time, it's someone else and they have no idea what's going on with your code, it takes them twice as long as it should to make the change and it's full of problems. Oh, and don't forget the steady stream of obscure bugs that came out of your original work.

Is that the message you want to give to your peers? Is that the guy you want to be? Your colleagues let out a sigh of despair when they have to work near your code.

Addressing your point about agile being a discouragement to craftmanship. Well that's just nonsense. You can write good code or crappy code under any development process or methodology you like.

[Christian Peacock]

I've worked with a lot of code written by others that has been of a very poor standard but that did the job, as far as business managers were concerned, perfectly well. The "others" concerned were often well respected by said business managers for getting things done quickly and usually successfully. It's only when another developer such as myself comes along to make changes / fix problems found much later that the lack of code quality becomes apparent. Like I said, in my experience most business managers don't care about the quality of the code - not necessarily intentionally but by the fact that they're perfectly happy with crappy code that they're not aware of and are reluctant to spend money on improving it when informed.

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.

[Tim Cooke]

I agree that in most cases it's near impossible to get business buy in to spend a non trivial block of time cleaning up a codebase while delivering no new features.

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.

[Junilu Lacar]

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.

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.

If you have never been on an Agile project or have only read about it or heard off-hand horror stories about it, take everything you hear with a grain of salt. Even the stories about how great it is should be treated with a good amount of skepticism. Ask people who rave about it "What's the catch?" My answer is simple: as with anything, you have to understand the principles and you have to be disciplined in learning and applying the techniques. Half-assed Agile is worse than no Agile, IMO.

You can't just go to your local airport and learn how to fly a small airplane then expect to be hired by NASA to fly on the next mission to Mars the very next week, or month, or even year, right? There's a long, hard road in between those two points. Likewise, the road to agility is long, arduous, and fraught with peril, and many who have ventured down that road ill-prepared and poorly educated have fallen by the wayside. If anything, being Agile requires a level of dedication, professionalism, and craftsmanship that is at least an order of magnitude higher than what many developers in our field are willing or capable of committing and devoting to.

[Christian Peacock]

These points are well and good if as a developer you're successful in a) providing an adequate estimate for doing a piece of work to a high standard and b) accomplishing that the first time around. If you think to yourself "I could have done that better, and made things easier down the line" how do you justify revisiting a piece of code given that agile mandates you only work on things that are defined within a sprint?

I'm not saying that agile prevents good development but nothing I've heard so far contradicts my belief that it prevents a developer from going back and improving things for improvement's sake.

[Tim Cooke]

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

Then define it in a sprint. If you really think the work needs to be done, then define it, estimate it, schedule it, do it.

The key, and this is not unique to Agile, is to get better at estimating stuff. I'm not brilliant at estimating stuff, and I often get it wrong. But if there's a task to be done in some code that I know is nasty, then I would overestimate it to allow for the required clean up operation.

To say you have to some clean up to do before you can implement the new feature is not a lie, it's the reality of the work. If you don't give yourself time to clean up, then you'll find yourself regularly missing targets because you waste so much time wading through the crappy code.

As I said before, you don't have to take a hiatus from delivering features and spend 3 months 'cleaning up'. That's just not realistic. But understand where the cruft in your codebase lives, and be ready to tackle it as and when you have to work there again. Uncle Bob Martin talks about the 'Boy Scout Rule' where he promotes the idea that every time you touch your codebase, you leave it in a better state than you found it. This doesn't have to be some revelatory refactoring or redesign effort, it can be something small like renaming something to better describe its purpose or intent. Over time these improvements accumulate and you stop the rot and begin a journey back to a nice clean codebase.

[Christian Peacock]

Yes, good point, estimation is the key.

I like the Boy Scout Rule - that's something I've almost always done without knowing it had a name.

[Junilu Lacar]

The Boy Scout Rule is an excellent way to make improvements "on the fly and on the sly".

I've already said this in another reply but I'll reiterate: I think the key is prevention and continuous improvement. And that's the whole point of the Software Craftsmanship. If we can dedicate ourselves to achieving higher standards of quality in our work, always looking to improve our skills and techniques, then most of the problems we face now will naturally go away or at least will be easier to deal with.

Einstein is quoted as saying "We cannot solve our problems with the same thinking we used when we created them." Likewise, we can't get out of the messes we're in by doing the same kind of things we did to get ourselves into them.

[Junilu Lacar]

Christian Peacock wrote:I'm not saying that agile prevents good development but nothing I've heard so far contradicts my belief that it prevents a developer from going back and improving things for improvement's sake.

These are the kinds of statements I hear from folks who 1) don't fully understand the principles and values of agility 2) have been misled by Agile horror stories from people who didn't get what Agile is about 3) are still fearful or uncomfortable with the idea of changing the way they work and/or 4) have been burned so badly by promises of better processes and methods that they are cynical to the point of being closed minded.

Now, I'm not saying you're any of these. I'm just saying that in my experience, this is the kind of thing people like that tend to say, and I've met quite a few in my day.

The only thing there is to get them to try it and see for themselves. It helps if they have someone who knows what they are doing help them along, otherwise, their misconceptions will just be reinforced by failure -- their pre-formed misconceptions become self-fulfilling prophesies.

That's not to say that Agile methods are for everyone. It takes a certain kind of mindset to do it well and some people, for whatever reason, just can't seem to make the shift into the pre-requisite mindset. I feel bad for those folks because I don't think they'll ever experience the kind of satisfaction and joy that I have in being an Agile developer. That's not to say my life as an Agile developer isn't without its challenges either. Sure, there are plenty of challenges and there can be pain and heartache at times, but it's usually when you have to deal with people who are less agile. When I work with my team doing mob programming, the experience is usually very positive. The applications that we develop and deploy into production just work. We hardly ever have the kind of production issues other teams seem to have constantly and the last time I remember having to deal with a Priority 1 issue is a number of years ago, and it was related to infrastructure problems, not problems with our code.

Many of the applications that I support have legacy code that just s*cks b*lls. But every time we have to touch something in there, we plan it into our iteration to clean up any area of the code that we have to work in. And any time we have to add new features, we do TDD and thoroughly test it. 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.

[Sandro Mancuso]

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.

[Christian Peacock]

Thanks Sandro, and I look forward to reading your book.