Enabling the mobile workflorce

The short history between the mobile device and the enterprise has been turbulent. Consumer innovation in this space has happened at a pace that has left most enterprises uncomfortable at best and paralyzed at worst. Luckily, most have organizations have started accepting this intrusive technology into their thinking. Some have even started successfully exposing their LOB systems to these new interfaces. Others have implemented marketing driven apps for their customers. What’s missing is that few enterprises have embraced the inherent features of this technology to enhance and change the way they do business internally by enabling their mobile workforce.

Most businesses have a portion of their workforce that is mobile or out in the field. We’re talking about the field engineers, the salespeople, the fleet.. the people whose work isn’t behind a desktop. These staff typically have mobile devices or can now be cheaply equipped with these devices. With the right apps/ software, these devices can not only enhance productivity but often enable entirely new models of working that weren’t possible in the past. These new models of work can be radical new market disrupters.

Mobile technology enables use cases that simply weren’t possible. More specifically, solutions using this technology can:

  • track the time and location covered by the field agent, enabling new metrics
  • capture photographs and video to supplement traditional form capture
  • enable offline work scenarios in areas of low connectivity. Syncing again when back on-line
  • navigate the agent to specific locations e.g. Broken infrastructure
  • live capture of data when augmented with other sensors

Ultimately, all tasks and the associated resolution can have supporting evidence of the GPS and camera.

Although these solutions can be ground-breaking, organization’s strategy should addresses the risks that come with bleeding edge solutions. A mobile orientated solution needs be rolled out with a device management product. This is needed to ensure functionality such as remote wiping.

The mobile solution also needs to be sufficiently integrated. A phone with an app is hardly useful without appropriate integration into the LOB system. This integration can be costly with Legacy systems where integration often isn’t simple and clean.Currently, the market also has a diverse selection of devices. This can result in costly development as the apps will require some redevelopment and customizing for each platform. Although HTML 5 is a way out of this, it comes at a loss of functionality e.g. Apps that need to function without connectivity aren’t best done with HTML5.

The reality is that these market-disrupter mobile solutions are becoming commonplace. Many businesses have unexpectedly been put in jeopardy by some small, unknown start-up. It is critical that an organization’s mobile strategy needs to go beyond simply managing BYOD. However, with these potential pitfalls, a knee-jerk app strategy will be a waste of resources.  A prudent first move would then be a simple, proof of concept (POC) focused on a few high-value use cases. Take the first step.. but make it lean and do it soon.


The science of debugging

The perception is that software development is developers creating features by writing code. The reality is different. As developers, we actually spend most of our time finding and fixing bugs… Feature development is just what we do in those little breaks between debugging.
For something that occupies most of our time, you’d think most be very good at it.. But often not the case. The sad thing is that we often don’t use humanities best tool for acquiring knowledge: The scientific method. When people say science, thoughts often go to beakers, lab coats and weird hair. Where actually, science is just a series of steps used to acquire knowledge. Each step is critical in the process.
The steps are as follows (shortened for relevance):
  1. Ask a question –  Obviously, we can’t find an answer if we don’t have a question
  2. Do background research – someone may have already answered our question or had a similar question.
  3. Construct a hypothesis – A hypothesis is a potential answer. The hypothesis must be unpacked into a series of predictions.
  4. Test the predictions with an experiment – Critically, we test to prove them WRONG. The sooner it’s proved wrong, the sooner we stop wasting time on a flawed hypothesis.
  5. Analyse your data and draw a conclusion – Spend time on the results. Nothing wastes more time than misunderstood results.
  6. Communicate your results – Communicating our results allows others to validate the methodology and test the results
  7. ..aaaaannnd repeat
Back to debugging…
When we have a bug, we have a question: “what is causing this sh*t to break!”. The scientific method is the most effective way to this knowledge if applied as a simple heuristic. First step is background research.. Google the error code, method and other relevant information. This is done right up front. We shouldn’t waste time on a problem that someone has already solved.
Based on our findings (or lack of), we construct a hypothesis – a falsifiable hypothesis which has testable predictions. If our hypothesis is un-falsifiable, it is too abstract and should be decomposed into other hypothesis. Importantly, all assumptions are just camouflaged hypothesis. If our hypothesis is both unfalsifiable and can’t be decomposed, it’s an answer that isn’t worth wasting further energy on as there’s no knowledge to be gained. For example: as nice as it feels to vent about it being Windows fault, that’s not a particularly useful hypothesis.
Next, we do an experiment i.e. prod the application in a way that tests the hypothesis and resulting predictions. Analyse our results of the test.. Don’t argue with the results but let the results lead us. If it didn’t behave as expected, we’ve just learned something valuable about our assumptions.
Lastly communicate our results. Most aha moments come from a simple chat to a fellow developer who challenges our biases.
It’s science bitches!