I don’t feel comfortable calling myself a Software craftsman, I am more like a journeyman striving towards one day becoming a software craftsman. And this is a journey and experience that makes me get up everyday to go do work I enjoy.
There are a number of posts lauding the virtues of software craftsmanship, as well as a number that highlight the negative sides of the Software Craftsmanship movement. And when I read these arguments, both sides have merits.
One argument against Software Craftsmanship is that it puts “beautiful software” above software that simply does the job. And I think that if this is true, then indeed there is something wrong. When I read the Software Craftsmanship manifesto1 this is not how I understand it at all.
For me, however, it is about being pragmatic, if I am working on a piece of code that is going to be worked on a lot by a number of developers, then I will spend time to make it look good and tell a story. But if it is a piece of functionality that has not been touched for the last five years, then I am not going to spend days refactoring the code into something that is pristine.
In this regard I believe in the Boy Scout Rule2 of leaving the area cleaner than when I found it. I would rather do a simple spring clean with some refactoring to help me in understanding the code. And if I am not sure as to how often the code is going to change then I will do what I think is enough to make it easy for the next person to read and understand the code. So I am always thinking of the next person who is going to read the code.
As a code base is becoming cleaner, smaller and more understandable the ability to deliver valuable business features is enhanced. When a developer does no have to wade through masses of spaghetti like code to complete a feature, everyone benefits. So sometimes slowing down to speed up is definitely worth it.
Software craftsmanship also allows me to give back to my colleagues. I think it is so important to play a mentoring role to junior developers who are apprenticing to become software developers. This allows me as a more senior developer to assist them on their journey to becoming better software developers. If the mindset around Software Craftsmanship is going to grow positively, it is important that the more experienced developers play a role in guiding and assisting juniors in shaping their values for software development.
Mentoring also allows for my continued improvement. Not only do I also benefit from being a mentor by having my thinking challenged by fresh minds, but I am constantly challenging myself on how I can do things better. One part of this is by finding tools and techniques that will allow me to craft software that adds business value at a regular cadence.
As someone striving to become a Software Craftsman I believe it is important to understand the business intimately. This understanding allows us as developers to craft software that is simple and tells a story which, our business counterparts would be able read as well. The benefits of this is that when we are talking about concepts or features we are talking with a common language.
It is also important that the business or customers are taken on this journey. If they could not care about the future maintainability or just want apps pushed out the door as quickly as possible, then I would not stay around long because these are my principles that are being broken. But if my customer cares and wants something that will stand the test of time and which everyone is proud of, then this becomes a very fruitful partnership.
So for me, Software Craftsmanship is a set of values that I measure myself and what I am delivering against. I want to surround myself with people who take these values to heart as well. This is not only for my benefit, but hopefully I can assist them in becoming better as well. And it is part of being a professional software developer.
References
- Software Craftsmanship Manifesto – available at http://manifesto.softwarecraftsmanship.org
- Boy Scout Rule – available at http://programmer.97things.oreilly.com/wiki/index.php/The_Boy_Scout_Rule
Craig on software development 