Ruthless Engineering

It can be easy for teams to end up being hampered by two sources of distraction.

One can be an over-emphasis on solving problems that don't yet exist, this might be termed over-engineering or simply unwarranted future proofing.

The other can be becoming to wrapped up in the coolness of what is being built or the softer elements of how customers will interact with the software being produced.

While its a delicate balancing act, as effort in all of these areas can be valuable, a healthy amount of ruthlessness should be demonstrated in trying to achieve our goals.

Ticket to the Game

The goal of any development team should be to ship software, not only is it demoralising for the fruit of a teams efforts to not be delivered to users but an organisation gains little or no value when software is written but not given to users.

Shipping software is buying a ticket to the game, trying to perfect your offering to users while admirable will often lead to others delivering what maybe a sub-optimal experience but that gets them into the minds of users.

This shouldn't be taken as a remit to ship software without it being properly engineered or without due diligence around its proper operation.

It is a call to remove all obstacles to the delivery of software into production, sometimes these are technical and sometimes process driven, but a ruthless pursuit to reduce the amount of time between coding being completed and code being shipped should be the goal of an effective operation.    

Working the Numbers

Once our software has shipped then we should immediately turn our attention to determining if we have built the right thing.

As much as we want to please our users garnering their feedback can be an imprecise science and we may have additional goals for the code we shipped that we also need to evaluate.

Any data we collect towards this goal has to be actionable, we must be able to define metrics we can accurately measure and where a plan of action can be defined for whatever direction those numbers may move in.

We may feel that some of the value we provide towards to users is intangible or immeasurable, while that may be true effective product development must be data driven and progress must be demonstrable.      

Change of Direction

When we evaluate our carefully cultivated data we shouldn't just be trying to prove our original hypothesis correct, we should be prepared and almost expectant that it shows we got it wrong.

One of benefits of an agile is approach is the ability to pivot when we are proven to have taken a misstep.

To have an agile mindset is to accept uncertainty and in accepting uncertainty were acknowledging the possibility we may get things wrong.

Achieving this ability to pivot is a combination of flexible engineering, constructing a well segmented and organised code base that can be changed without re-writing, and a business mindset to not create plans built on an assumption of always making the right call.

Ultimately engineering must have a purpose the production of software is not an end in and of its self. It is a tool we use to achieve outcomes, both for our users and to reach our own goals. 

This purpose can be re-enforced by application of a scientific method, creating an hypothesis, devising an experiment and looking at what the data tells us.

Sometimes we will be right and sometimes we will be wrong, but while we remain in the game we can look to improve our numbers and roll the dice again.