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.   

Mobility Issues

Each branch or flavour of software engineering has its own quirks and nuances, whilst the fundamentals of writing good software are fairly universal, experience with a given platform or use case tends to develop over time to adapt these truths to the situation.

Mobile development is no different, many years ago this would have been characterised by a lack of resource, whether that be CPU, memory or data storage, however those concerns have all but disappeared with the advent of powerful smart phones.

But none the less mobile development still has some unique challenges, while sometimes this can make an engineers life difficult its also what can make the process more interesting.

Diversity Across the Spectrum

Web development can be complicated by the various different browsers that users may be using to access a site, standards for web technologies help smooth this variation but it still exists.

Mobile development is complicated by much more variation in multiple factors, whether it be software, hardware, screen size, screen resolution, available peripherals or age of device.

All of these factors can vary independently leading to the number of variations an app could be expected to be compatible with to be measured in the hundreds or possibly even thousands.

The counter to this is to be to identify where all this variation could impact your codes operation and ensure adequate abstractions are in place to enable you to craft some conformity for important pieces of functionality.

Its also important to be realistic about which elements of variation cannot be controlled and whether or not it is realistic to try and target all the platforms all the time.

This may lead to a progressive approach where the more functionality a platform or device is able to offer the richer the app experience will be.

Lack of Connectivity

Connectivity to APIs and services has become an essential part of most code bases, very few pieces of software are written in or run in isolation.

When developing server side applications the infrastructure to provide this connectivity is virtually guaranteed, outages may happen but shouldn't be a regular occurrence.

Code that runs on a users personal mobile device cannot rely on this robust connectivity.

Environmental constraints related to where users happen to be trying to use your code can cripple an application if no strategy is in place for when API calls cannot be made.

It is very difficult for a complete lack of connectivity to cause no issues but whenever a flow of execution involves a service call consideration should be given to what happens when that call cannot be made.

This maybe be implementing a retry strategy, limiting the required number of round trips to the server or pulling down data ahead of when it will be required.

Window of Opportunity

The nature of how people use mobile devices means they rarely use your software with an anticipation of spending a large amount of time interacting with it.

From the moment they launch your app you have a limited timespan to provide the functionality the user wants and to draw their eye to the areas that you want them to notice and interact with.

Uses also utilise their devices for many different purposes so you have to deliver your functionality whilst competing for the users attention when they are presented with many other distractions and apps trying to fulfil similar needs.

Context, Context, Context

The fact mobile applications run on a device the user has with them pretty much at all times and when on the move means a wealth of additional context is available for your app to leverage.

This may be where the user is, what they are doing, what they are trying to find, where they are trying to get to.

If used properly this enables your app to make itself extremely relevant to the users needs and wants.

It can also enable your app to figure out over time how it can become more relevant to the user mining all this addtional context that not all code is able to take advantage of.

In any area of development the unique challenges it present should be embraced as opportunities to make a difference, this is where you can differentiate yourself from your competition and make yourself more useful.

Always keep in mind the universal truths of all development but learn how to apply them to the field you are working in, while we may agree on the structure of the cloth, one size does not fit all.