Nothing Needs to Change for Everything to Change

Hello,

approximately every 10 years there has been a fall in processor prices that has created a new industry.

Gordon Bell made this observation in 2007, and it was accompanied by a price reduction of an order of magnitude in each cycle.

In the 1950s, mainframes appeared costing 1 million dollars; in the 1970s, the minicomputer cost one hundred thousand; then came the workstation at 20,000, the PC at 2,000, mobile phones, and so on.

For many years processors have steadily reduced computing costs, but the interesting part of the observation is that when this change makes something approximately ten times cheaper (or, in any case, "large enough"), a new market is created. And sometimes the previous market is also destroyed as we knew it.

Processors are an example where the speed of progress has been very fast, but they are far from the only example.

Transport, energy and AI

For example, the cost of transporting a tonne by sea in 1956 was around 5.6 dollars. In 2019 it was 0.16 (36 times cheaper). When the cost fell by 30%, the movement of goods probably increased, but when it became around 10 times cheaper it enabled offshoring.

Another great example is solar panels. In 1976 photovoltaic power cost around 106 dollars/W, whereas today it costs 0.11 (around 1,000 times less). This has enabled the transition from an anecdotal application (in satellites) to use in remote places where it was difficult to bring in cabling, and finally to today’s domestic applications (even though everyone is connected to the electricity grid!).

Artificial intelligence, together with the right application of the technology, enables a reduction in software development costs of this order of magnitude. The difference from previous technologies is that in those cases the change took at least a decade for each order of magnitude. Here the transition has taken less than a year, perhaps two, depending on how you calculate it.

Despite the speed at which this is happening, we already had indications that it would happen and at NaN-tic we had made decisions in preparation for the moment. I explained some of them in the talk we gave at our office a few months ago.

But being able to make some decisions before this happened does not mean that it is obvious to understand the depth of the change, how to rethink the market and its needs, or how to respond to them. Everything must be questioned, and it is exciting.

Just this week I have realised that a principle we have applied for years when implementing management software is no longer valid today.

The costs of friction

As you probably know, implementing new management software in a company requires a great deal of effort, both from the company and from the implementer. Neither can achieve it without the other, which is why we say the relationship must be a partnership and therefore based on mutual trust.

Imagine how complex implementing management software is: even merely upgrading to a new version of the same software (especially when there have been custom adaptations) has traditionally been an ordeal.

Avoiding this ordeal has perhaps been NaN-tic’s most important mission over the last 10 years and, although it could be said that we have passed it with a high mark, we continue working towards top marks.

A software change almost always means a change in the way of working. The company must invest in the new software and, since it works differently (often better because it incorporates years of experience compared with the previous software), the change also implies new ways of working for the company.

This makes perfect economic sense and is simply common sense in practice, but it adds complexity to the change. It normally translates into delays in the implementation process because everyone involved must ensure that the new ways can actually be applied in the company. And since not everyone likes change, human resistance to change adds further friction to the process.

But if we look at it coldly, we are really forcing the company to adapt to certain ERP processes because doing the opposite from the outset is too expensive. There is no great problem in adapting the software if it is necessary to work differently, but only occasionally do we recommend modifying the software if we know it will be used for just a few months. If we know the company will eventually adapt (because it sees that it is a better way of working), why should we make an expensive modification to the software?

And so, more or less consciously, we turn this saving into greater friction and complexity for users.

But here we return once again to Gordon Bell’s observation.

Closing the loop

One of the things enabled by reducing development costs by an order of magnitude is reducing friction for users: it allows the new software to be modified so that it works much more like users currently work (even if it is not a very good way of working).

Change less the way of working at the time of the transition so that you can change more and more quickly once it is up and running. As incorporating changes once the system is already running is vastly simpler than doing so beforehand.

Moreover, extending an implementation over months also delays the return on investment and prevents the company’s processes from evolving continuously. The go-live is like a huge dam holding back the changes the company needs.

So, now that costs make it possible, what makes sense is to implement software that is less different from the previous system, but go-live much more quickly.

Who knows, perhaps after fifteen years we have to change our tagline to "You want to change, and you don’t change".

Cheers!