An Introduction to Code and Quality Metrics

For some time I've been developing an idea that I think is pretty powerful, and it is the heart of my upcoming talk at DDD Adelaide, The Digital Factory - Anyone Can Understand Software Development. The key concept is that difficulty understanding software is less attributable to any particular aspect of how computers work, and is more attributable to a diffusion of responsibility and ownership that is completely invisible in a literal as well as a more abstract sense.

Today, many people have some level of familiarity of 'code', even if that familiarity begins and ends with the knowledge that people who produce working software might write some.

My short-form answer (that favours an immediacy of understanding over accuracy) is that code is a set of instructions that will be handed off to another computer process. Code is expected by that process to conform to a set of rules - if it does adhere to the expected rules, the process will output software.

This answer conveys something I think everyone should know about software - code is distinct from the software itself. It is a plan for running software. Something everyone knows about making plans in everyday life applies here: how plans are actually executed is the result of some combination of circumstance and what the executor does in response to its instructions.

"The code is more what you would call guidelines than actual rules"
Captain Barbossa, Pirates of the Caribbean

There are other things that I think everyone should know about code that are less obvious.

In product development there is a popular concept of 'pick 2' of Cheap, Fast or Good. A challenge facing software projects in particular is that there are many different quality metrics for code and several of them are in conflict. Since I stated above that code is distinct from running software, it is perhaps worth pointing out that these quality metrics downstream to the software, albeit over different timescales.

In my last post, I wrote about responding to memory constraints. It's not hard to imagine some readers wondering why the solution described there was not simply applied at inception of the feature. In that scenario we improved memory performance but at a cost - additional development time and increased complexity. It is and always will be possible for an independent auditor to choose a particular metric and ask why a feature or perhaps an entire project doesn't score more highly on it. It could be a genuine trade-off problem but there are other answers too - product decisions, prioritisation of time to market or internal deadlines, the level of experience of developers, technological choices, cost, ideological attachment to particular development practices, compliance requirements... I could go on.

The prioritisation of quality metrics are really something that should be tailored for a particular project, and even then they should be tailored to a more specific context. There is often a genuine tension between building systems to be fit-for-purpose and standardisation.

There is much more that can be said about code without delving into how computers operate, on topics such as divisions of labour, and commoditisation (or lack thereof). These are worthy of their own moments. Until we meet again!