Sandro Mancuso

Hi Junilu,

I know Tom quite well. We met many times over the years in many conferences and spent a lot of time talking to each other.

He is considered the grand-father of Agile. His work in the 70s was way ahead of its time, when he was talking about evolutionary project management (EVO).

It's a shame that I only came across his work quite later on in my career.

Sandro

Hi Bijesh,

Please see my reply on the other post mentioned by Tim.

Tim Cooke wrote:Similar question to this one.

Thanks
Sandro

Hi Pan

doudou pan wrote:
Am I able to understand the software craftsman book ? Is this book a good starting point ? or is this a intermediary book for team lead ?

I believe that as a reader, Junilu Lacar put it very well in his replies.

When I wrote the book, I must confess that I didn't have a "target" audience in mind. I just wanted to write about Software Craftsmanship, my experiences, and ideas. Because of that, parts of the book can be very difficult for a person without much experience to understand and parts of the book may be quite basic for a very experienced person.

All in all, I believe that the first half of the book will be very interesting for you since it describes what Software Craftsmanship is, and most importantly, the attitude of a craftsman. I believe the first half of the book has loads of advices that I wish I had been given at the beginning of my career. My book is a "behavioural book" and not a technical book.

The second half talks about bring Software Craftsmanship to organisations. If you identify yourself with Software Craftsmanship in the first half, the second half may give you some ammunition to bring it to you workplace. Maybe you haven't encountered some of the problems that I try to address yet, but hopefully things will make more sense in the future, as you gain more experience. You can then re-read the second half of the book in a few years and say "A-ha, that's what he meant" ;)

Thanks for reading the book and for all your great comments in the other topics.

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.

Hi Randy,

Very good question.

There were quite a few reasons to why I decided to write this book.

The main one was that Software Craftsmanship is a subject that is very close to my heart. I've started coding when I was 11 years old and since then I fell in love with software development. In 1999, more than a decade after I wrote my first line of code, I came across this crazy thing called XP. At first, that made no sense to me. A few years later, already living in London, I heard about Agile, where they were also talking about XP. That caught my attention and I decided to read more about XP and Agile. Around the same time, I also came across the Software Craftsmanship book by Pete McBreen and The Pragmatic Programmer by David Thomas and Andrew Hunt. These two books changed the way I saw the world.

As the Agile summit happened in 2001, the same year that Pete McBreen released his book, Software Craftsmanship didn't really become a thing. Agile overshadowed almost everything in that period. It was not only until 2008 that Uncle Bob and a few others in Chicago created the Software Craftsmanship movement, almost as fix to the bad turn that Agile had taken (too much focus on process and not much on technical practices).

In 2010 I started the London Software Craftsmanship Community (currently the largest and most active SC community in the world with 2500 developers) and helped many other Software Craftsmanship communities to be created in Europe. And since 2010, I've been heavily involved with the international Software Craftsmanship community.

Many things happened since Pete McBreen wrote his book, Agile being the biggest. The motivations for the Software Craftsmanship summit in 2008 were different from the ones that made Pete McBreen write his book. And after more than a decade of Agile, Software Craftsmanship needed a modern take—a book that could reflect what Software Craftsmanship means today, 14 years after the original book was written.

I also felt that I had acquired enough experience as a developer (almost 2 decades writing code professionally) and enough knowledge about Software Craftsmanship to share my ideas and hopefully write a book that could represent what Software Craftsmanship means today. My aspiration is that this book will help many developers to look at their careers in a different way and hopefully help us to move our industry forward.

Melodie Rice wrote:
What are the top three components of being a Software Craftsman?

I'm not sure I can list "three components". For me, being a craftsman is a lifestyle. It's not only about code. It's about always striving to do things in a better way. It's the eternal journey to mastery.

Being a craftsman is not about how good you currently are on something or the amount of technical knowledge you have in a certain area. It's about your attitude towards your career. It's about caring about what you do. It's about helping other people to get better. Learning and Sharing. Being a positive influence wherever you go.

Will Myers wrote:
I was just wondering how much of the book is devoted to influencing?

The first half of the book is about what Software Craftsmanship and what it means to be a software craftsman. The second half of the book is about how we can bring Software Craftsmanship to organisations and I believe that it addresses many of your concerns.

Junilu Lacar wrote:
You mustn't let yourself be discouraged by what others will do or not do despite your own efforts. You can't force people into things for which they're not ready or capable of doing, for whatever reason. Lead by example and produce results. If nothing else, it will always be a good thing for yourself and your career. And if you're lucky, you'll be able to inspire or influence one or two other people along the way. That's how a groundswell starts.

Massive +1 here. There are things that you have almost no chance to change, mainly if you are not in a position of influence. Normally they are organisational changes. Other things are quite hard to change but you can make a difference and with a lot of hard work, you may be successful. Normally they are related to the behaviour of the people within your team. And there are things you can easily change, like your own behaviour.

Not doing certain things because others don't do is not really a great excuse. The best way to convince someone to change their behaviour is to show to them that there is a better way, and that starts with you being a role model and leading the way. Don't force. Don't shout. Don't say that what people do is wrong. This will only make them hate you and reject whatever you say to them, even when you are 100% right. Instead, be friendly and nice to everyone, but at the same time, show how awesome it is to work the way you do.

Paul Wallace wrote:

I came to know your work through some of the screencasts you posted on youtube, these are great.

Thank you.

Paul Wallace wrote:

Do you have any tips on how to promote software craftsmanship in an enterprise setting?
...
However it is as much a problem to convince developers, who are set in their ways, as it is to convince management of the benefits of a software craftsmanship approach.

Promoting Software Craftsmanship in an enterprise environment is almost impossible if they haven't embraced Agile yet. I don't mean that the company needs to be truly Agile. I mean having the willingness to adopt Agile values and practices.

Normally Agile transformations come first. They increase the business appetite for a better process, a short feedback loop, and a quick return on their investment. Agile processes also help to increase the visibility of things that are going well and the things that are not going so well.

Once this "appetite" for improvement is there and they gave the first steps towards a more Agile way of working, embracing Craftsmanship values is less painful.

The second half of the book is dedicated to exactly that. I was hired by a major investment bank to help them improve the quality of their software, a few years after they started their Agile transformation. I spent almost 3 years there working in a global department where we had a good degree of success in embracing Craftsmanship values and XP practices. All the things I wrote on the second half of the book are things I tried at a large scale and some of them may be quite useful to you.

Bringing Craftsmanship to an organisation has many challenges and affects many different things: from how you write a unit test to how you re-engineer your entire global recruitment process; From creating a culture of learning to dealing with ivory-tower architects and managers. From trying to deploy software multiple times a day to adapting your practices to work in projects that are part of a 5 year initiative in a heavily regulated environment, where devs don't even have access to production.

I hope you find many tips in the second half of the book.

@Ahsan Bagwan: Thank you.

Different people find different ways to focus. I have a very short attention span and a lot of context switch in my day-to-day work. Pomodoro is a a technique that works really well for me. It's also very useful when pairing. We can set goals for each Pomodoro and force us to have regular breaks while we can check emails and just chat a bit about other things.

Pomodoro reduced interruptions as well. People would approach our desks, see the timer on the screen and say "Sorry, I'll come back later" or "Can you come to my desk during your break?"

There are a few people that had a big influence in my career. The first was Eduardo Namur, a mentor I had in the early days in my career. I wrote about him at the beginning of the book. After him, I had a few other colleagues in other companies that were also quite "obsessed" with the quality of their work. Purely in terms of Craftsmanship, Uncle Bob and McBreen were the biggest inspirations. I was also quite inspired by the work of Martin Fowler, Kent Beck, Ron Jeffreys, the Gang of Four (Erich Gamma, Richard Helm, Ralph Johnson, John Vlissidesand), Eric Evans, and Craig Larman. Most recently, Steve Freeman and Nat Pryce also caused an impact on how I write code.

Hi there.

I'm having some problems playing some wav files with the MMAPI (WTK22).

Testing my application with some wav files, I realised that I can play some types of

wav files but I can't play others.

This is just a snapshot of my code.

InputStream is = getClass().getResourceAsStream("/res/audio/RICOCHET.WAV");
Player p;
try {
p = Manager.createPlayer(is, "audio/x-wav");
p.start();
} catch (IOException e1) {
e1.printStackTrace();
} catch (MediaException e1) {
e1.printStackTrace();
}

In this case, the ricochet.wav has the "PCM 11.025 kHz, 8 bit, Mono" audio format

and it works fine.
The audio format "PCM 22.050 kHz, 16 bit, Mono" works fine as well.

When I try to play a wav file that has one of the following audio formats I get a

MediaException with the message "Malformed wave media".
Formats:
- CCITT uLaw 8.000 kHz, 8 bit, Mono
- Microsoft ADPCM 22.050 kHz, 4 bit, Stereo

Does anyone know this problem? Which types of wav file audio formats are supported

by the MMAPI? If the "CCITT uLaw 8.000 kHz, 8 bit, Mono" format is not supported at all, for which format should I convert?

In advance, thank you very much for the help.

Sandro.