How to communicate inefficiency before it's implemented?

Question

This is a problem I come across pretty often. Basically we are using an application to make art content. Often times this requires writing custom tools for it.

Sometimes you run into parts of the application where doing something is not directly supported in the UI, which means it will either be a little more involved or communicating this to the software company that makes this software so they can address it in the future.

But I see some of the more experienced people suggesting to use methods that are extremely inefficient.

For example let's say you want to access the value of the last item in a 10M item array. Let's say it's not directly doable. So you could write some code that would be inconvenient in this case because you just want it directly doable in the app.

But instead of this, they suggest you to let's say create a spare property for each item in the array, that will basically store the same thing, and then by using a built-in tool which will go through each element and set the value of ALL these new properties to the last item read. So it will be like:

for i=0 to array.Length:
    new_property[0..array.Length - 1] = array[i];

So this will indeed give you the last item when the operation is done, but it will be extremely slow.

How can you communicate this to the people suggesting these methods? Because they think it's quite reasonable and since they have more experience and this is mainly an art application, it shouldn't involve more work for us/them.

Answer 1

The way I handle efficiency topics before implementation (feasibility study phase or architecture phase) is the following:

1. Explicit performance requirements, and even better, define the Key Performance Indicators which will allow you to check whether or not the software meets performance requirements. (If you are subcontracting the software, these KPI need to be very clear. They should be part of the acceptance criteria.)

   For example: the basic requirement we had in mobile phone UI was that something (anything) should move at most 100ms after an end user action. If not possible, the longest possible reaction time needed to be below 200ms. (The rational is based on human perception of 'instantaneously').

2. Whenever a specific performance target seems hard to meet, prototype the expected solution. For your art application example, if you think that the suggested solution might not work, you can just ask for a proof of concept / prototype, before the real implementation.

   Note: If it meet the performance requirements, do you really care about a suboptimal solution ?

3. (optional) If you/they cannot find a reasonable solution to meet performance requirements, it may be time to make a trade-off between 'functional' requirements, and performance requirements.

4. During the development process, monitor the KPI to detect possible performance issues at the earliest. The subcontractor may be doing it internally even if you don't ask for this explicitly.

Moreover, this KPI monitoring allows using the "optimize only if necessary" strategy. The developers don't spent their time optimizing their code unless there is a real need for performance.

Hope this helps.