Extreme Agility

Growth kills. Its one of the maxims of business. Growing too quickly is as bad as growing too slowly. Philosophers and pragmatists agree, its one of the few topics where they find common cause; growth is not only vital but has to be just right for the current prevailing conditions.

On the other hand, everyone seeks instant, unrestricted and boundless success. Now!

As Lao Tzu said in 400 BC, "No tree grows to heaven." Many other philosophers have also noted that building deep and extensive roots produces slow but accelerating, sustainable growth. Conversely, rapid, unbounded growth creates spectacular, colourful short lived blossoms that equally as quickly return to mulch. Business is full of examples of both types.

What has this to do with robotic trading? It is about thinking in metaphor. Does that make it clearer? Probably not... Tag along for a few more paragraphs please.

Our robots are about creating financial growth for individuals and organisations. But we the creators have a day to day problem when creating the software. First, its never been done before so we don't have a known, reliable plan to build to. Second, as we move forward we have to be agile enough to adapt to feedback and experience, initially from ourselves but also increasingly from our users.

Without a plan we cannot progress. However, a detailed plan of what a financial trading robot should look like is not available - hence we work primarily with metaphor. Our primary metaphor for the software is a robot.

Slowly we give it characteristics. We then test these characteristics against what we have projected. Usually we now go back and modify them, repeating this process until the robot passes our tests of acceptable behaviour.

There are two concurrent movements in modern software development, travelling under the names of Agile Software Development and Extreme Programming. What makes these approaches work is not so much the technical details - important as they are - but the glue that makes all the intricacies work is metaphor. Having a metaphor every team member understands and can relate to while they cut the code is the single most important aspect of these approaches.

The beauty of metaphor is it is descriptive without being prescriptive. It helps you to decide what to do without telling you how to do it. It fosters creativity while focusing on results.

In order to achieve extreme agility and pragmatic results quickly - with least effort - we tell stories, paint word pictures of our metaphor and build the metaphor as the glue in our team. We sketch diagrams that fit the story we are telling that explains the metaphore in context and name the code we write to fit the parts in the story. The code we write is the root system feeding everything else we project will follow. It is a broad and deep root system.

It is nearly two years since we created our first metaphor and the software components we now have at our disposal were not dreamt or planned at that stage. They evolved. Many never made it, proving to be dead ends. The aggregate of those that survived the Darwinian testing process give us the shape of today's robot, which is at the same time highly defined but agile enough to go on evolving.