For many years, I’ve spoken to friends, colleagues, mentors/mentees about craftsmanship and how important it is in Software Development.
As a software developer, it is very easy to agree with. Quality is not negotiable, write your tests first, blah blah blah. We understand how important design patterns, readable, maintainable code is, especially in building sustainable software.
One aspect that I find isn’t spoken about explicitly enough, is Contextual Craftsmanship. We all know there is no silver bullet, and hence I find that craftsmanship is very similiar. There is no correct way to develop, and it depends on what you are doing, and the business context you are in.
A start up context is very different to an enterprise. Code built in a hack-a-thon is very different to a system in which a bug can literally result in life or death (ie Software for planes or medical equipment).
I am lucky enough to have experienced many of those contexts – and I’ve assumed developers are aware of this; people will change their approaches.
But as I mentor developers, and work with large development teams, I recognise the line is not always clear for everyone. The need to discuss the context explicitly is very important.
Is this a Spike / Proof of Concept that will be thrown away?
Is this an MVP to gain insights and validated learnings?
Are you building a business critical service for a Fortune 500 company which requires 99.95% uptime?
Craftmanship depends on the context.
Have the team agree on the approach; the level of quality, reliability, maintainability, DR, etc.
It is fundamental for the team to be on the same page, but it is just as important to ensure your stakeholders align to this.