Quantcast
Channel: Dan's Outsourced Memory » Craftsmanship
Viewing all articles
Browse latest Browse all 2

Your Software is Wrong…but that’s okay

0
0

Here’s the thing – software is wrong. We create software to manage change: bring about efficiencies, enable easier regulatory compliance, make the difficult easy and the impossible doable. It’s all change. As software developers we are all about change – it is the essence of our industry and it pervades everything we do. Any static view of a software system in that world must be wrong.

We can choose how we frame this ceaseless change; we can either see it as a huge risk to be mitigated through contracts and gated responsibility or we can choose to see it as a source of endless opportunity to collaborate and seek mutual achievement. The former view is not, of itself, bad (issues around motivation, engagement, stress and productivity notwithstanding) but it does lead to a great deal of effort before we produce and deliver our software. Effort costs money and what is the one thing we know about the software all this expensive effort has produced? Yep – it’s wrong.

Over the past couple of decades we in the software industry have learned a great deal from the world of manufacturing – especially from the pioneers of efficiencies in Japan and The States. But the production of software is not analogous to a manufacturing process and it is a mistake to see it as such. There are two core differences: firstly, with software, we are targeting a moving target (the aforementioned change); secondly we have a much lower cost of change with software. The first demands flexibility and the second enables that flexibility. When we enshroud our software production with heavy process we make change expensive, lessen our flexibility and damage our capacity to respond to change.

Here’s a quick story from an experience at work the other day where a colleague used a very effective method to demonstrate the importance of detailed analysis. Firstly he produced a small black ball and asked me to describe it as though doing so for a technical requirement. I’m a fail fast kinda guy so went in with “black sphere”. Now my colleague produced a second black ball and asked if it met my given requirement. I in turn answered “yes,” after all it was a black sphere. Without wishing to give too much away and spoil a worthwhile demonstration, my colleague now proved that the two black balls were in fact very different. The point, according to my colleague, is that without getting the analysis correct in the first place we produce something that is wrong and it is expensive to correct those mistakes.

So, what’s the point here? Well my starting position is that my answer was always going to be wrong: inevitably incomplete. But, by being wrong as quickly as sensible, it is cheap to revise my position and arrive at a more correct position. Crucially by iterating in this way I have established a pattern that need never end; a pattern that will keep going beyond the customer’s original bounded concept of what they wanted into unforeseen realms of systems improvement.

This is the essence of agile development and software craftsmanship: we’re going to be wrong anyway so let’s get there as efficiently as possible with code that we can change as easily as possible. Let’s take the customer with us on a journey that will go beyond what they currently think they want and lead them to an evolving relationship of continuously handled change.


Filed under: Thought Bucket Tagged: Craftsmanship

Viewing all articles
Browse latest Browse all 2

Latest Images

Trending Articles





Latest Images