Why do Craftspeople care about non-functional aspects of Code?

How do we measure code? There are the obvious and natural reactions to this:- is it free from bugs/defects, is it live/shipped? Is the business earning money from it? Did it come in under or over budget? All very natural and indeed worthy questions.

However, in my experience most businesses just stop here, never caring about deeper aspects of the software. It’s not long before this dynamic and this approach bites the company back, and bites it hard. As your business endeavour progresses and the BML (build, measure, learn) cycle begins to kick in and as the plethora of “Me Too’s” also launch their version of your endeavour and provide competition to you in your vertical you start to need developing your “product differentiation” faster, the software needs to change and adapt to the changing environment you need to grow your team quick and this is where the pure focus on “does it do what the customer wants?” to the exclusion of any other need becomes a problem. The business demands that change X happens asap, it needs to be live by March, and the existing engineers and software developers might say “Yes, but… its currently January, nobody understands what that code does and that will take 4 months!” or when changes occur your product owner says “Everything breaks every time we make a change, the user experience changes every time I demo something” because the developers don't understand what a change means in the code or worse your CTO says “No we can’t do that, we can’t deploy for 2 months because nobody understands how it was built”.. The product stagnates, the product feature is not delivered on time your customers get frustrated and your endeavour becomes irrelevant in light of more agile and thoughtful competitors. This is where Software craftsmanship values deliver a crucial difference to the software development process. Software craftsmanship can give your business an edge. It gives you the ability to respond to change. I spoke with one engineer at a business who explained to me that in his new role building and deploying their software took 2 days or more because nobody could understand how it was done, getting the developer environment working on a new machine with a clean checkout took 2 weeks because nobody understood how it was done.

Understandability/Readability

If one developer, or a new developer cannot understand what was written previously by another, why it was done that way, if it is not clean code, well documented and clearly defined, well tested, that code will need to be refactored at least and usually is totally rewritten. The problem being that if the same cultural drivers are followed the same happens again, the code is written and developed, the QA accepts it and it goes live with the same problems, it’s not readable, it’s not understandable and the next time you want to change it the same will happen again over and over, it will need to be re written from scratch and a huge amount of time/money is then wasted. That is why a strong separation of concerns, the use of clear interfaces, well documented methods that say “Why?” they are doing what they do, clear indications of where this function sits in the overall architecture creates code that is Understandable and Readable to a new programmer entering the domain. Software craftspeople understand the value of clean, clear understandable code that communicates what it is doing. When you discover lots of code that is incomprehensible or unreadable you realise that you have acquired a large amount of technical debt. This debt is often very expense-even existential for a business, from my own personal experience I know that a company that developed an MVP and had it delivered in 3 months (cheaply and outsourced-before I arrived on the scene, no unit tests, no documentation, no comments in the code - no "Why?" anywhere), they then had to spend a large amount of money and a painful 6 month transition until the code was cleaned up and made understandable, With Software Craftsmanship as guiding principles from the start the MVP/POC could have been delivered in a similar timescale but also saved the company a huge amount of pain as the process of change would have been far easier.

So when you are in charge of a new project don't lose sight of the mantra.... “All Code Must be Readable/Understandable” - can a new mind understand the purpose of that functionality? If it can't you might be heading for some expensive re-writes or even failure of your venture. Save your business money and do it right the first time. Adopt craftsmanship principles now.

Better Code = Better Business

Regards Julian