The devolution of the Leapfrog drawing tool – a lesson in designing disruptive technology: Part 2
In Part 1 of this post, I explained that the original Leapfrog drawing tool, which had dual drawing modes of Bézier and CAD-style polyline tools, was not only an elegant and compact drawing tool, but the Bézier method of drawing was compatible with the radial basis function (RBF) interpolation method used in Leapfrog. This unique free-form 3D drawing tool, invented in 2004, is very powerful. There’s nothing like it in the resource industry, nor outside this industry (Figure 1).
Figure 1. These interlinked rings show the capability of the Leapfrog’s free-form drawing tool in 2004. Although this type of drawing wouldn’t be used in geology, these types of complex geometries can be drawn without effort using Leapfrog’s Bézier drawing tool.
Given this, it made no sense to alter or drop the Bézier method of drawing polylines in future versions of Leapfrog as the angular CAD-style drawing methods were never going to work with RBF. However, during the six years of development of the next-generation Leapfrog (later called Leapfrog Geo), the developers made no attempt to simply port the polyline drawing tool from Leapfrog Mining into the release version of Leapfrog Geo (v.1.2, February 2013).
Eight months after this Leapfrog Geo release and after complaints from experienced Leapfrog users, an inferior and an entirely separate Bézier drawing tool was released in version 1.4 of Leapfrog Geo. This backflip by ARANZ Geo was completely avoidable. Why was the CAD-style drawing method set as the default drawing tool for Leapfrog Geo? This post discusses the reason.
Leapfrog Hydro development
I can’t recall exactly when, but around 2006 or 2007 ARANZ started designing a groundwater application (later named Leapfrog Hydro). Groundwater and petroleum applications were excluded from the Zaparo joint venture (JV) agreement between SRK and ARANZ so I didn’t take much notice of this development. I knew that the focus for these applications would have to be largely focused on stratigraphic and fault modelling very similar to 3D-WEG (now called GeoModeller). I also knew from modelling hundreds of mineral deposits that only a limited number of metalliferous deposits would benefit from a stratigraphic modelling package.
It was clear from the start that an ARANZ engineer (who had no geological experience) was developing this software and was relying on external advice (outside SRK) on groundwater modelling issues. The graphical user interface (GUI) for Leapfrog Hydro was completely redesigned; as a result, the Project pane no longer resembled that of Leapfrog Mining, which was justifiable, as it was for a completely different application. This engineer also designed Leapfrog Geo’s GUI, and neither Hughan nor I had any involvement in that design.
Leapfrog Hydro morphs into Leapfrog Geo
After Hughan and I stopped driving the development of Leapfrog Mining software (around 2007), users started to notice a decline in innovations introduced into that software. In addition, tools that I requested for improving Leapfrog Mining weren’t developed; instead, they were developed only for Leapfrog Geo, which frustrated Leapfrog Mining users. The dismantling, deceleration, and stagnation of Leapfrog Mining development started years before Leapfrog Geo was released to the market in 2013. ARANZ Geo has now stopped developing Leapfrog Mining and it will die a slow death once it cannot operate on future versions of Microsoft Windows (currently it works on Windows 8).
When ARANZ started to develop Leapfrog Hydro on their own, SRK wasn’t told that it would eventually morph into the next generation of Leapfrog—Leapfrog Geo. This transition was completed after SRK parted as a JV partner and ARANZ were left to develop all Leapfrog software products. Leapfrog Geo is now the only Leapfrog software effectively sold to the resource market by ARANZ Geo. However, the base code and the GUI was an alteration of Leapfrog Hydro, which emphasised stratigraphic and fault modelling.
The overhaul of Leapfrog Mining was required
The original Leapfrog software (later called Leapfrog Mining) was built from scratch. There was no base to this software, so it was fully expected that the software was going to become difficult to manage as it evolved. The Project pane on the left of Leapfrog’s viewer window was a confusion of objects that users had to navigate, and with the introduction of faults and splitting of domain volumes, it was very difficult to understand the project if you hadn’t built it yourself.
There was no denying that Leapfrog Mining had to be rebuilt.
So overhauling and rewriting Leapfrog software had to happen at some stage, but I thought the overall open ‘toolbox’ concept needed to be retained because geological relationships and scenarios can’t be represented simply in an interface. There would be too many geological scenarios that could be possible, not to mention unknown geological relationships that are not yet discovered (the ‘unknown unknowns’ that drive the most curious geologists). If there was to be a conversion to a geological workflow-driven interface, as is now seen in Leapfrog Geo, it had to be a system that could handle the multitudes of scenarios that are geologically possible in real datasets. I am not philosophically against such a system, but what I didn’t favour was a GUI based on a simplistic understanding of geology as that forces geologists to skew their interpretations to simplistic solutions that do not reflect reality.
How geological bias can occur from a software interface is a topic for another post, but it became clear that one of the aims of Leapfrog Geo was to simplify the modelling workflow to a level most geologists would understand or would feel comfortable with. As a consequence of this simplification, one of the casualties was the Leapfrog drawing tool—the Bézier tool was deemed too complicated to use and to teach.
Shift in emphasis from geological vision to sales vision
With SRK Consulting out of the scene and without Hughan’s or my input, the ternary diagram from Part 1 changed to that shown in Figure 2.
Figure 2. Unlike the ternary relationship that resulted in Leapfrog Mining (Fig 1 in Part 1), Leapfrog Geo’s inputs were all internal to ARANZ; SRK was not involved in the design of Leapfrog Geo. GUI and tools designs came from the same internal source, and one of the main drivers for software development changed from long-term geological vision to sales.
The ‘Geological Vision’, which represented my input into the development of Leapfrog Mining (Figure 1 in Part 1), is now replaced with ‘Sales Vision’ (Figure 2). For any business, sales is the bottom line and a shortcut to increasing sales is to provide what users are asking for, irrespective of whether it’s in the interest of developing long-term effective disruptive software.
No experienced geologists were driving software development, nor any geologists familiar with FastRBF and with extensive experience using Leapfrog on real datasets (as I was). External feedback was sought from geologists outside ARANZ; these geologists were not responsible for the direction of software development (Figure 2). Their main incentive was to see tools included in the software that would benefit them most in their daily work, which can only resulting in the ad hoc addition of features.
During the early days of designing Leapfrog’s drawing tool in late 2013, I had corresponded with Dr Richard Lane about three possible ways of drawing polylines—CAD-style, B-spline, and Bézier. Richard wanted to go with a simple drawing methods that would allow users to adopt Leapfrog quickly (B-spline was a compromise between Cad-style and Bézier). I had no problem with including the CAD-style drawing mode, but insisted on including the Bézier instead of the B-spline mode as it’s the most compatible and accurate method with RBF interpolation.
My concern was the technical ability of the tool. It had to be the best possible method because, over the long term, that’s all that mattered. There’s no point in getting users used to an inferior method if you’re going to have to educate them later on the ‘proper’ way—you might as well educate them correctly from the start.
However, I was not involved with Leapfrog Geo’s development, so sales—not geology—was given the priority. CAD-style polylines are easy to use and would introduce people to Leapfrog Geo so the Bézier tool was dropped, much to the dismay of geologists who knew the power of Leapfrog Mining. To many of us, this was a step backwards in development. It was insulting to hear ARANZ Geo encouraging geologists to switch to Leapfrog Geo when it clearly wasn’t superior to Leapfrog Mining—this was marketing spin at its worst.
Designing for market disruption
So, what is the preferred way to approach the design of a disruptive technology?
- Education approach: Only do it the correct way and then properly educate the users. This was the path taken in the design of Leapfrog Mining; or
- Familiarity approach: Design new technology to look and operate like old sustaining technology that people are familiar with (in mining, tools that are used by GMPs). This was ARANZ Geo’s approach in designing Leapfrog Geo’s new drawing tool.
My perspective is that the first approach will lead to disruption, whereas the second approach will only slow down and delay the disruption. That is, the software will have to change to a more progressive approach or another company will overtake you. My point is illustrated in the design of one of the first cars (Figure 3).
Figure 3. One of the first designs for the car was effectively identical to the horse and carriage. (image from Justacarguy)
Although people at the time would have identified with the car design in Figure 3, the design didn’t last long. Why? Because this design didn’t take advantage of the full capabilities of what a car could be. Proliferation of this design would no doubt have delayed the advancement of the car industry.
The original all-in-one drawing tool of Leapfrog Mining was not just designed on a whim. As discussed in Part 1, it was the collaboration of three equally important inputs. Hughan and I worked closely and around the clock on Leapfrog for many years and we discussed in detail the implications of every tool we designed for Leapfrog so as to not limit the capabilities of what implicit modelling could do for the future of mining and exploration industry.
Hughan and I instinctively understood the uniqueness of Leapfrog, so we were satisfied with the Bézier drawing tool designed in 2004. We were not prepared to degrade the capability of Leapfrog software to increase short-term sales as that wouldn’t be in the interest of the long-term viability of the software. The key was education, so that geologists knew how to use the software properly.
We felt that we were on the right course of development in 2004.
I feel the same in 2015.