Optimisation considered harmful

Surely, optimising anything must be good? Who wants anything other than the best possible outcome? Well, in most practical circumstances, most of us are quite happy with something less than optimal, as long as it gets the job done.

I’m not talking about the (fairly well-known) problem of wasting resources optimising a piece of code that isn’t time- or resource-critical and only runs occasionally. This happens, but it is fairly obvious and easy to fix – with good project leadership. There are worse issues with optimisation.

For example, we often talk about “best practice”, “optimal process”, and the like; and many managers are more comfortable with these concepts than they are with code optimisation. The trouble is, process optimisation has the potential to be at least as wasteful as unnecessary code optimisation (often, more wasteful); but, although it can distract people from being agile about changing business outcomes, it sounds like something no-one should object to.

Process optimisation (depending on how one defines “optimisation”, of course, but some definitions really are dysfunctional) can make process less flexible, less able to cope with changes in the business environment; and it can cause people to focus on process as an end in itself rather than as an enabler of business outcomes. Process optimisation can also reduce the freedom of people to work in any way that they want to (as long as the business results are achieved), and thus reduce morale and involvement of people in the process. Of course, one doesn’t want people working in outdated or inefficient ways (one wants “good enough” process, with good governance of acceptable working practice) but often there are several perfectly adequate ways to achieve a desired end and little point in choosing between them (and thus, in forcing people to change what they are doing).

Many years ago, Herbert Simon (who featured in my computer science education, at least) realised that people often only need something that is “good enough” to achieve their ends (and that that is how the human mind works), and that this idea applied to organisations as much as to individuals; see the summary in the Economist here. Simon referred to this as “satisficing” and it is highly relevant to technology-related processes – settling on “good enough process” is often more “agile”, and more cost-effective, and less disruptive, than chasing “best process”.

Of course, this all implies that you can identify the available alternatives and have access to well-defined and well-understood acceptability criteria, for the identification of “good enough” processes and practices. Like anything else, “satisficing” works best in a mature organisation with some metrics behind it.