Boosting performance

To make systems perform well, you have to focus on system design more than on high-performance coding.

One of my biggest failings professionally is that I do not think about performance when I design systems.

My attitude to performance goes back to when I was a trainee. I worked in a department where we wrote a lot of assembler. I was not keen on assembler because it was such hard work, and much preferred to work in COBOL.

The argument in favour of assembler was that assembler ran faster than COBOL. That may or may not be true, but the effort of writing in assembler meant that you easily missed the bigger picture. High-level languages free you to think more broadly about the design, which makes more difference than saving a few CPU cycles here and there.

Rather than thinking specifically about performance, adopt a design style that makes it easy to improve performance.

You need effective modularisation within a system, with simple and clear boundaries of responsibility between the different parts. This means that if one part performs badly it can be reworked and made more efficient without disrupting the rest of the system.

Use the database effectively, which means letting it do the job it was designed to do. I have seen performance problems caused by programmers trying to "better" the database by storing data in memory. This is hard to do well, and more often than not ends up slowing the system down. It is better to let the database handle all the data. With the help of a database administrator, with indexes and the correct caching, the database will easily out-perform hand-written optimisation.

The same is true of other system software. For example, in our Metrici Advisor software, I have not thought about the efficiency of sending web page to browsers, other than the general rule of keeping pages small. But because I have not designed anything exotic, we can use the standard features of the web server to optimise the pages, for example by compressing them.

At a coding level, even with large amounts of memory and fast processors, it is still important to avoid exponential processing times, which you can get from manipulating large data structures and strings in memory. Rather then doing anything clever, get to know the standard features of the programming language. Modern programming languages like Java provide standard classes for efficiently managing in-memory data; learn to use them.

Over the years I have learned that the best approach to performance is to focus on modular, flexible designs, and using the database, system software and programming languages in a standard way.

This does not guarantee that your system will perform well. In fact, it will almost certainly mean that you system will perform badly to start with.

However, it will give you a system that can be made to perform. You can tune the database and other system software. You can find and fix processing bottlenecks without disrupting the rest of the system. A modular, flexible and standard design will give you ample opportunity to improve performance, and is likely to give better results than a rigid design that focuses only on performance.

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

Why user documentation is critical

Without complete user documentation there are almost certain to be holes in your system.

One of the sentiments of modern programming is that code that is not accompanied by automated regression tests does not exist. I would extend this and say that functionality not accompanied by effective user documentation does not exist.

We have a lot of technical documentation about our Metrici Advisor service. However, we do not have complete documentation for people who use the service, particularly for those who use it to develop new solutions.

To plug this gap, I have been writing tutorials for colleagues and partners who are involved in solution development.

This took me longer than I expected. I kept finding things that were hard to explain.

I got stuck on the very first tutorial, trying to explain the basic concept behind Metrici Advisor. Internally, it has a store of objects we call nodes which are accessed through unique URLs. But that is difficult to explain. To make it understandable, I had to turn it around and describe Metrici Advisor as being made up of web pages, each of which is represented internally by a node.

I got stuck again explaining metadata. Each node is defined by a node type which is itself a node. But that is too abstract to explain simply. I found I could explain it better by presenting it as a series of layers: a solution layer, a solution type layer, a developer layer, and a system layer.

Then I got stuck trying to explain user groups. Metrici Advisor can support any number of user groups, which are used for setting permissions, and which can be arranged in different ways to achieve different effects. But that is too abstract. I decided to simplify it so that each account has a main user group with all the account users in it, and that additional user groups can be created to grant permissions to subsets of users in the account.

It got worse when I tried to explain how some of the structures work. Internally, we use an optimised triple store, which is a very abstract concept. We had to invent a formal diagramming notation to explain some of the structures in a consistent and concise form.

With great relief, I have completed the first dozen or so lessons in the tutorials, enough to get colleagues and partners up and running. But as well as creating training material, the process of having to explain it has really tightened up the solution in a number of areas.

• We have found simpler ways of thinking about the structure of solutions.


• We have worked out how to split solutions into distinct layers with different responsibilities.


• We have standardised how we manage users in accounts.


• We have developed a formal notation which we can use in solution design.

These are not just devices to teach people the system. Thinking this through has given us new ways of defining solutions and new ways of managing the service, and filled previously unseen holes in our thinking. It was only the need to write the documentation that prompted us to complete these parts of the solution.

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

Database independence - payback time

With a little foresight and discipline it is possible to create database-independent applications.

We provide our Metrici Advisor software as a service on the web, rather than as software that our customers install. This is easier and more cost effective for both us and our customers.

You might think that this frees us from many of the constraints of a traditional software vendor. We do not have to support the preferred hardware, operating systems and databases of different customers. We can just pick some technologies and stick with them.

Tempting though this may be, it would be short sighted. We need to protected ourselves against imposed technical changes and supplier failure. We have always insisted that the software is independent of the hardware, operating system and database on which it runs.

This decision comes at a cost. We develop and test the software on both Windows and Linux, we test it against both the HSQLDB database and MySQL. This adds time to development and testing, and means that we can not take advantage of special features such as database stored procedures.

Is this worthwhile?

We currently run servers in the UK. Our customers are mostly EU-based, and the UK is as good a place as any for the servers. We can support customers globally from our UK-based servers.

However, a larger opportunity has recently cropped up in the US. Operational and legal considerations mean that we may need to run US-based servers. The business we are talking to could host the service and it makes sense for us to have a second instance, just for this opportunity.

Which brings us back to databases. Our production servers run on MySQL, but our potential partner has a very strong preference for PostgreSQL, and getting our software working on PostgreSQL is an important part of the arrangement.

Now it is payback time.

Because we have worked hard to make our software database independent, migration to PostgreSQL has been simple, and we managed to get a PostgreSQL version up and running in a few hours.

The migration could have been difficult. We have had to change table names (our "user" table is a reserved word in PostgreSQL), and make minor changes to some of our SQL. However, years of discipline have paid off. We were able to make these changes without changing any program code, and we are in a good position to take forward this opportunity because of it.

On a technical level, we have not had to do that much to achieve database independence. We use standard SQL, and no stored procedures. We use only fixed SQL statements, rather than building SQL in code. We hold the SQL in an external file, which lets us change the SQL without changing program code.

These things are not technically hard. But many organisations make this harder than it should be. They think that because they have "invested" in a "strategic" database they should use database-specific features. They do not enforce database standards for development and maintenance. And of course database vendors are keen to promote features which make their database special, and which make changing databases harder for you.

Not everyone needs database independence. But it can be achieved. It just takes a little foresight and discipline.

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

Bootstrapping 3: Building a business

Truly flexible software should be able to sell itself.

Creating MA2 in itself is all well and good, but there is a danger that we could polish and play with our new software for ever. We have to turn our new software into a business.

We know what we are trying to achieve with MA2. It could be used to build nearly any type of web-based solution, but marketing it as a general-purpose web tool puts it in direct competition with well-established products. We are going to focus on assessment and advisory solutions, where MA2's flexibility is particularly valuable. We see the following uses.

• Self-service advisory products. We are in a unique position to deliver products for individuals and organisations to carry out assessments online and to get good quality automated advice.


• Complex surveys. MA2 can support complicated surveys, collecting and analysing different types of data in different structures from different people.


• Consultancy tools. MA2 can automate the fact finding and analysis which takes place in the early stages of consultancy exercises, allowing consultancies to focus on valuable downstream work.


• Enterprise use. MA2 can be a platform for complex enterprise solutions, capturing, maintaining, analysing, transforming and presenting complex bodies of information.

This is a very wide marketplace. How do we get there from where we are? How do we bootstrap our business?

Product promotion and marketing traditionally involves large budgets and networking with C-level executives. However, MA2 lets us do something different. We can use MA2 to build capabilities to help market MA2, such as demonstration products and free trials. We can develop the MA2 business in a series of phases, each one laying the foundation for the next.

• Phase 1 involves creating initial products and proofs of concept. We are working with existing partners to re-purpose their content in MA2, focussing on easy-to-use self-service products. We are creating self-service features, such as a survey capability. We are using the software internally, moving our administration and the Metrici website onto MA2. The focus in phase 1 is building a solid foundation.


• Phase 2 involves scaling up use of the product. The self-service products provide clear and immediate benefits, and can be promoted widely, recruiting users and also new partners. We can offer meaningful free use of the product, and low-cost licensing for more extensive use. Because we are offering a low-cost web-based service, it makes sense to use web marketing methods to promote it.


• Phase 3 involves positioning MA2 in the more demanding consultancy and enterprise markets. The users and products from phase 2 will demonstrate the appeal and stability of the product, which makes it easier to position MA2 as a platform for more advanced use.

In the same way that we can build the MA2 products within MA2 itself, we can build the MA2 business using MA2.

We have the outline of a plan. But "no plan survives contact with the enemy", and of course we can not let our plan get in the way of customers' requirements. Although we are just coming to the end of phase 1 we are already talking to people about phase 3 solutions. Exciting times indeed.

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