Written by Edward Wright, Lead Geospatial Engineer

“trying to do things they can’t yet do, failing, and learning what they need to do differently is exactly the way that experts practice.”

– Angela Duckworth, Grit: The Power of Passion and Perseverance

Provocative title, but what does it mean? Let’s take a journey to get to the meaning. An example speaks more than a brief summary ever could.

This post is going to look like it is about software engineering, but it isn’t, it is about human behaviour.

The shortest path

As discussed in a previous blog post, Vortexa uses an Astar shortest path model for calculating possible maritime vessel trajectories across the oceans. Astar itself requires a graph of nodes with interconnections, and each connection has a cost, usually related to distance.

So we could have a data structure for this graph looking something like this Rust code snippet:

Now the thing not shown above is some of these links between nodes have properties (such as the cost of traversing the link), because we want to conditionally block portions of the graph when calculating where certain vessels can and can’t go. You cannot for example expect to moor up a huge supertanker within a small port, it would simply run aground so such a pre-calculated route would clearly be wrong.

We have a lot of nodes. We have many, many more links between them. So, I had an idea:

“What if we move the properties from the links and make them properties of the nodes instead? This would improve memory efficiency, and given the pressure on the CPU cache, speed.”

I fired up Visual Studio Code, created a branch and started merrily hacking away. When the code was ready, I fired it up and ran some test routes. They matched perfectly with the production version.

Then I hit two snags.

Problem one – the change is based on an incorrect assumption

Imagine my graph has 3 nodes, A, B, and C. I want to prevent a (specific) vessel from following paths which intercept a certain geographical area, shown below in blue.

It’s easy to see that going from A to B is fine, but going from A to C is not.

However, none of the nodes are in the exclusion zone. This means, the property which discerns whether part of the graph can be transversed by Astar is a property of the link, not a property of the node. The changed code will nearly work, but not quite give the same results.

Problem two – it makes no difference to the speed!

After a little benchmarking, it seems this change saved perhaps 1% of the process’s memory, and in terms of speed is perhaps 0.1% faster than the production code.

The trade-off and the point

Clearly this is a bad trade-off, compromising the model integrity for essentially no gain and so this change was abandoned. The fact that such an approach is inappropriate for two reasons is new information.

One could argue this specific change was a waste of time, however I wouldn’t argue that point. The bigger picture is not a waste of time.

“Failures from which actionable information can be gleaned are useful, and normal” 

We need to experiment

We deal with complex, noisy data on a daily basis, and we are continually mining this data to extract the maximum information value from it we can. This serves our customers, and of course helps with operational efficiency.

There are two angles to this; knowing what we want and going for it, and exploring the data to see what correlations or patterns are there and what information it can reveal.

Experimentation is important. It is completely normal and natural that some experiments fail. In fact, even calling them failures is a bit of a misnomer – a failed experiment is actually giving us information, such as a certain pattern was not there, or a certain approach is not viable. This is useful. Failures from which actionable information can be gleaned are useful, and normal. Failure is part of my day job.

We will probably never know how many times Thomas Edison failed to make the light bulb before he succeeded. That journey was in a sense not a set of failures and then a success, it was a set of steps in the process of invention.

I would say not all failures are born equal, some are more worthy than others. With the experiment above I was just scratching an itch in my own time. The trick is to have what we might call directed failure, failure with a purpose. A path to invention, a path to results.

I am lucky to work with a fantastic team who live and breathe this ethos. When an experiment goes well and we get new results, we celebrate together. When it goes? the other way, everyone knows we’ve all just gained a data point and that’s just fine. A step on the way.

Vortexa is such an exciting and diverse place to work, and our experimentation is producing world-class results. We’re hiring, come join us.