Craftsmanship: Values/Principles/Practices Series: Courage
Courage is one of our values as craftspeople and it wasn’t immediately obvious to me what it meant. Courage, like bravery, seems quite a thing to claim as a value. It’s definition:
- the ability to do something that frightens one; bravery
- strength in the face of pain or grief.
I guess only in extreme circumstances can we liken the bad times in development as feeling (real) pain or grief, so probably the first definition is more reasonable.
So when do we need courage to do something that frightens us as craftspeople?
Courage to speak up and give ones views, and Courage to disagree/debate with a peer or a manager.
It is instinctive to some to speak up and feel comfortable giving opinions and suggesting ideas which differ from other team members, but I’m sure I’m not alone in feeling it takes a bit of courage to do so.
It is not courage alone that people like me need, it also helps if you trust your colleagues and can have open, honest conversations and feedback (other craftsman values).
Courage to scrap code and start again.
Sometimes we are working on an issue and we struggle until we eventually have a solution which works, but definitely isn’t ‘right’. It’s very difficult in my experience to delete hard won code because of all the effort and time I put into it. However, I have learned that I shouldn’t fear starting again. I generally find that I have learned a lot from every attempt, and that each time I re-write it, I understand the problem better.
We Are Not Our Code! Scrapping it and starting again is not admitting defeat, in fact it is admitting we know the issue now and are confident that we can tackle it better.
Courage to tackle an issue and to make the system right.
Imagine: you incrementally want to add a new feature which breaks the system in fundamental ways. What do you do? Roll back, stick with the inferior solution? It obviously depends on what the issue is, but if your conviction tells you that the changes should be made, and that the system will be better for it, then you should stand by your idea and get it working.
Courage to tell a customer bad news.
It was fairly common in my previous employment to have clients asking for more and more from a phase of development than was originally agreed. On paper, we think it is simply a case of refusal, but in reality it’s far more difficult. Personally, it is my nature to want to be helpful and it’s easy to get carried away with a client’s enthusiasm about new features.
However, it does not do the client or their system any favours to agree to implement new features without properly scheduling them. If one believes in the XP values then it should already have been communicated to a client from the start of the relationship how one works. If that is the case then one has already laid the foundation, and a client should expect nothing but the truth from us when we say that a particular feature needs to be prioritised and planned.
Communication and feedback are obviously tightly related to this value, as sometimes it takes courage to tell a client that stories have slipped or an unforeseen issue has arisen.