Don't Prematurely Optimize Mobile Health

This post was created in an mHealth working group online discussion in March 2013:

Professor Donald Knuth, a legend in the field of computer science, wrote a famous passage about premature optimization. This will resonate particularly with all of the technologists out there:

“There is no doubt that the grail of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified. It is often a mistake to make a priori judgments about what parts of a program are really critical, since the universal experience of programmers who have been using measurement tools has been that their intuitive guesses fail.”

While this is often cited in reference to performance / speed, I would argue this quote can also apply to scale and sustainability. The number of mHealth technologies is increasing, as is the maturity of certain platforms. However, mHealth technology is mostly just an amplifier of human intentions. Deciding which “parts of a program are really critical” to scale and sustainability must be well understood before we can identify where to invest our time and energy.

In our work with CHWs (community health workers), we often struggle to determine how the performance improvement we are trying to achieve with systems like CommCare will actually be realized. This goes well beyond whether the technology is working, extending to human resources, ownership, and accountability. The motivation or management capacity may be lacking, and this is likely to be exacerbated at scale.

Obviously, mHealth technology can’t solve that issue, but if we are trying to better enable supervision and management then the cost of fixing the HR or training issue may dwarf the entire cost of the mHealth technology. So, if the return on investment (ROI) of deploying the mHealth technology hinges on functioning supervision and management for the CHW system, then any optimization within the economics of the mHealth technology shouldn’t be addressed before the supervision and management issues are.

That said, designing for scale and sustainability early on are absolutely critical. If you don’t proactively design pathways for optimization in certain areas, then you may find them impossible or prohibitively difficult/expensive to improve later on. Some design pathways that should be left open:

1.  Assume technology is going to change and evolve with it. The pace of technology innovation and capabilities to build from is going faster than we can imagine. Don’t build only around today’s technology, and don’t be afraid to jump to new technologies when needed.

2.  Make sure there is a positive feedback loop for the technology and improving the system. There is an old management consulting phrase “culture beats strategy”, and culture can absolutely destroy technology (see: e-mail). Even if the technology is scalable, introducing it in to a system that isn’t designed to utilize will be a poor use of resources. When a good technology is introducing into the right system dynamics, it improves the system, which generates more demands on the technology and both get better, together.