Testing and forgiveness

Taking a different approach to development can reduce the need for testing.

I am a great believer in test-driven development. The value proposition is clear: it is simpler, quicker and cheaper to create tests before you write code than to debug and fix code after you have written it.

I now develop a lot of solutions using our Metrici Advisor software. Developing in Metrici Advisor is radically different from a traditional software development environment. Because of this, we have to rethink how to approach development tasks, in particular testing.

There are two aspects of Metrici Advisor which challenge my views on testing:

• There is not much to test in Metrici Advisor. The solution is defined in metadata, and once the definition is correct the solution functions correctly. The only thing to test in a conventional sense are the little snippets of JavaScript that provide calculations, and there are very few of these.


• The development speed of Metrici Advisor gives us new opportunities. We can create solutions in a few hours, and to make the most of this we build early versions of solutions as part of the sales process. These evolve into the final solutions, without ever having gone through a formal development process.

To address these differences, we are having to rethink the concepts of "content" and "code". If you are working with content, such as a user manual, you would start with an early draft, and gradually refine it. But even the early draft is usable, and has some value. This is very different from code, where if it is not complete and correct it may be unusable, and where small changes can have big knock-on effects.

We are finding that development in Metrici Advisor is more like creating content. Early drafts are usable, and we can refine the solution gradually as a result of feedback.

Continually making changes to a solution could make it unstable. In conventional systems, components are linked together by reading code from files with specific names. Because components are only linked by file names, changing a component will impact all other components that reference it. In Metrici Advisor, components are versioned and are explicitly linked to specific versions of other components. New versions can be created without impacting existing versions.

This provides a very stable, forgiving environment. We can create an early draft, and try it out. Then we can create revisions to it, and try those out, without disrupting the earlier versions. Even after a solution has gone live, we can change it without impacting existing users, and upgrade existing users to the new versions when they are stable.

We are still trying to understand what disciplines we need for developing in Metrici Advisor. We probably do need a more formal proving and validation process as solutions move forward from the early draft stage. However, the mixture of metadata-based development and version management significantly reduces the cost and impact of change, which completely changes the value proposition of testing. Perhaps now we can test less, and test later.

© Copyright 2012 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

Universal business computer 6: Gaining value

Thinking through the universal business computer is hard, and building it is harder still. But working out what to do with it is the greatest challenge of all.

Over the past few weeks I have been sharing some ideas about a more standardised and versatile IT architecture, a consistent approach to developing and delivering IT systems that is an order-of-magnitude more efficient than other approaches.

This "universal business computer" vision is not about standardising a technology stack or adopting an application development framework. I am not trying to find an incrementally better way of doing what we do now. What I want is something fundamentally different. The ideal is a single IT system which can be used without modification for any business requirement, and which is much faster to set up than conventional development and deployment.

The main pieces of my vision are:

• An external architecture in which each system is a self-contained peer.


• An internal architecture in which all significant functionality is available as XML-based services.


• Data storage based on a directed graph, or data graph.


• Meaning added through metadata in the same data graph structure.


• A single processing engine for all application execution and development.


• A user interface based around individual data graph nodes.

This design allows new solutions to be defined in metadata in the system itself, and executed directly from that definition. This provides the order-of-magnitude improvement in the time take to set up solutions.

This design is not a just a theory. All these parts are possible, and from the work I have done so far, it does deliver unprecedented levels of versatility and development efficiency.

Having got to this point, I am not now sure what to do. How can we gain value from this design?

I could go on a campaign, promoting it as a "super-pattern" for IT. However, this would be in direct competition with other well-established approaches - including nearly every web application technology. Given that our implementation is not as mature, I would not make much headway. I do not want to spend years arguing why data graphs are a better paradigm than object models.

Instead, I think the most sensible approach is to use our own work to prove (or disprove) the ideas.

We have invested a lot of time and money rebuilding our Metrici Advisor product around this design. This has made Metrici Advisor much more versatile and efficient, which is particularly important in its core market as an assessment and advisory platform, for example for advanced surveys and consultancy tools. It could be used for much more, nearly any web-based application. Rather than tackling this wider market straight away, we plan to develop and prove the technology in its core market first, and then gradually expand the scope of solutions for which we promote it. This way we can prove the technology as we go.

We are not going to do this alone. Over the next few weeks we will open up Metrici Advisor for anyone to try out this new approach, and to create and share new solutions. I hope you will join in.

© Copyright 2012 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

Universal business computer 5: Interaction

Versatile user interfaces are based around resources, rather than tasks, processes or data types.

In this series of newsletters I have been presenting some personal views on a more standardised and versatile IT design, which I call the universal business computer. The last part of the picture is to understand how users interact with the system.

I have no great insights into how to make systems more usable. But from a more general viewpoint you can classify user interfaces into four categories according to the relationship between the user and the system.

The first category is task-centric, in which the system provides the user all the features they need to complete a single task. For example, a graphics program has a task-centric user interface.

Providing the user what they need to complete the task is good. But many systems also need to control the wider process. The second category is process-centric. The user is presented with a task or series of steps they need to carry out as part of a process. There will be features to start and complete work, and submit to the next stage. For example, the payment processing on an eCommerce site is process-centric. You confirm your purchase, provide shipping details, enter payment details, and then confirm payment.

For more data-intensive activities, the third category is to structure the user interface around the different data types, which we could call data-centric. We are familiar with this from tools like Microsoft Access, and simple database applications. The user is presented with a list of all their data, and options to read details, create new records, update records and delete records.

As a refinement of the fourth category, resource-centric user interaction is structured around individual pieces of data or resources, rather than types of data. You navigate to the resource you want to interact with and then perform an action on it. A website is a good example of a resource-centric application; you navigate to the page you want to read.

The options are not mutually exclusive. A process-centric interaction can present the user with a rich task-focussed interface. A resource-centric interaction can provide a data-centric view by providing a resource which contains a list of all the data they can read. What we want as the basis for the universal business computer is the most versatile approach, which can support the others where required.

Of the four approaches, the resource-centric is the most versatile. It can support task-based interaction by attaching the features to complete the task to the resources that needs it. It can support a process-based interaction by exposing the process or tasks as resources. As well as being able to support the other interaction types, a resource-centric approach makes it easy to extend the system as new resources are added.

In my vision of the universal business computer, the underlying user interaction model is resource-centric, and the user's perception of the system is of a read-write website. Each piece of data is considered a resource and represented by a unique page, with rich support for individual tasks where required, and additional resources to support processes.

Next week I will summarise the universal business computer and consider how close we can come to implementing it.

© Copyright 2012 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

Universal business computer 4: Meaning

Fully capturing the meaning of information can make development 5x to 10x faster.

In the previous newsletter I went through some ideas on a more versatile way to represent information. This week I want to cover meaning.

What we mean by "meaning" is making data understandable and useful to people. This covers two aspects:

• When the system outputs data, attaching additional information to interpret the data. For example "129.43" is meaningless, but "You owe £129.43 on your credit card" is meaningful.
• Internally to the system, guiding and constraining the processing. This includes the maintenance of the structure of the data and calculation of data values.

In most systems both aspects of meaning are implemented in code. Code in the user interface provides additional prompts to the user. Other code maintains the structure of the information and performs calculations.

Some systems attach additional information to stored data so that its meaning can be retrieved along with the data. This can be useful in a reporting environment, for example, to allow users to understand the meaning of the information.

In my vision of the universal business computer, this is taken one step further. Information is associated with data to describe its meaning to humans and to guide and constrain its processing.

A data graph structure makes this easier. For example, the information about a person:

Can be described using another data graph.

This provides meaning to help the user. It also provides enough meaning for a general-purpose engine to manage the user interaction. It is the "application".

Because the application is itself a data graph, the things used to define the application can be described by yet another data graph.

This has two advantages.

• The same general-purpose engine can be used to support the final end user and to develop applications.

• By adding more layers of definition, different types of application can have specific development tools, which makes development very simple and efficient.

We use this approach in our Metrici Advisor assessment product. It uses data graphs to represent the information that should be gathered, and also to hold the information when it is gathered. Different types of data gathering need different styles: a simple survey is different from a detailed audit. We use more data graphs to allow information requirements to be set up in different ways for different types of solution. A single engine manages all user interaction and data maintenance, leaving only specific calculations to be implemented in code.

We have been surprised by the versatility and efficiency of combining data graphs and a general-purpose engine. As well as assessments, we have been experimenting with writing other applications, such as web content management, expense accounting, bug tracking and contact management. To measure efficiency gains, we redeveloped an Access application that had taken about three weeks to develop. We reimplemented it in Metrici Advisor in about two days, suggesting something like a five-fold to ten-fold reduction in development time.

The last part of my vision of the universal business computer is how user interaction is managed, which I will cover next week.

© Copyright 2012 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.