The pitfalls of productivity

What are the trade-offs of rapid development tools?

Religion and folklore have plenty of cautionary tales of taking the appealing, short-term option, and not thinking about the future. I worry about this when I make bold claims about the speed of creating solutions in Metrici. I need to be more open about the trade-offs.

There is nothing magical about reducing development time. The methods Metrici uses are much the same as those used in other tools (though I like to think we have crammed more into a single platform). But each time saving method has a trade-off.

Delivering solutions as software-as-a-service (SaaS) means there is no infrastructure to buy and configure, no software to install, and common features like user management and security are already in place. SaaS is simpler and cheaper for most solutions. The trade-off is that you have to entrust your data to someone else.

Automation of database and user interface (UI) makes developing a solution as simple as describing the definition and structure of the data. This saves a lot of time, especially for solutions like assessments and management information systems which have transient or frequently changing data definitions. However, generic data structures are not as efficient as specific data structures for large volume transaction processing. The UI can be tailored, but if you have to tailor everything, it would not be as quick as using a more UI-centric tool.

Metrici provides a basic UI and data structure framework for solutions, and you add code for things like calculations and UI tailoring. This is much faster than writing a base program that controls all the database access and user interface. The trade-off is that you have to fit your solution into the pattern of the platform, which in Metrici's case is a web-based application.

Being able to redefine the components you use for development is common in lower-level languages, like LISP and Java, and Metrici similarly exposes high-level development components for modification. For example, if your solution requires a particular sort of graphs, you can create new types that simplify creating them. Making complicated things simple greatly reduces development effort, but you do need to spend time understanding existing components and how to write new ones.

Like a lot of content management systems, Metrici allows data and definitions to be versioned. This means that you can change things without impacting what is already there, which makes it much easier to build solutions incrementally, and much quicker to modify solutions later. But version-managed data structures are more complicated than they would otherwise be, and the trail of old versions means that you never fully remove earlier (and possibly erroneous) data.

To get the benefits of rapid tools without long-term regrets, you have to understand the mechanisms they use and the trade-offs. Metrici is no exception. The mechanisms Metrici uses - SaaS, automation, framework, components, change management - make it a productive platform for many data gathering, content management, record keeping and reporting solutions. As much as I believe they are worthwhile, there are of course trade-offs. If you want a rapid development tool you need to think carefully about the trade-offs, and be wary of promises of short-term productivity, even if they come from me!

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

Know your USP

Defining your product's unique selling proposition (USP) is not the same as listing its features.

At Metrici, we want to reposition our product. Currently we position Metrici as a professional assessment platform. It gathers and manages complex data from surveys and assessments, and analyses and reports on the data in multiple ways. We emphasise its flexibility, allowing you to quickly configure a solution that meets your precise needs, rather than make do with a solution that only does part of the job, while avoiding the cost of bespoke development.

We want to reposition Metrici as a more general platform. As well as surveys and assessments, you can use it to create databases, web content, reporting systems, document management, and pretty much any application you can imagine.

Repositioning our product puts us in competition with everyone. As well as competing with Excel and bespoke development, we will come up against large platforms: SaaS platforms such as SalesForce.com, content management platforms like Joomla and Drupal, and broad business platforms like Lotus Notes and Sharepoint.

To have any hope of competing, we need to promote our unique selling proposition (USP). We need to know "what's different about Metrici" if we are to have any hope of convincing customers.

Being faster and cheaper and more versatile is not enough. There are lots of things that make Metrici fast: it is web-delivered, database and user interface definition are automated, and you can rearrange how the tool works to best suit the solution you are creating. These are great features for us because they allow us to present solutions in many situations. However, customers are only buying for a single situation. The fact that we can quickly configure Metrici to be, say, a document management system, does not necessarily mean that it is a better document management system than others or that it is quicker to configure the final solution in Metrici.

Instead, our USP is that we can deal with the unknown. We need to present this carefully. Presenting it as "Metrici - for the man who doesn't know what he wants" won't get us very far. Here are some better examples of what I mean:

• Where the business requirement is not known, and you need to evolve the solution gradually through time.
• Where the investment case is not established, and you need to start small and grow the solution as and when the case is better defined.
• Where sources of funding are not known, and you need to start the solution very cheaply.
• Where business support is not established, and you need to build the solution to get support for the solution.
• Where you don't know how you are going to find the time to create the solution.
• Where the needs of your customers keep changing.
• Where you do not know what tools can meet all your requirements.

Put another way, the USP of Metrici is that it is the opposite of traditional systems development. Traditional systems development requires an established business case, stable, signed-off requirements, buy-in from users, ample funding, long timescales, and a well-understood architecture. If you have all those things, maybe Metrici isn't for you. Our USP is that we can help when you don't.

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

Video game training

Could video games provide a good model for how we structure technical training?

One of our problems at the moment – and it is a good problem to have – is scaling up our ability to meet client demand for solutions based on our Advisor platform. We need to increase our pool of skilled people to keep up with demand.

Advisor is built on some fairly unique concepts, so we can not take on ready-trained people and will have to train people ourselves.

Unlike many tools, there is not a distinct set of technical skills that solution builders need. Advisor functionality is defined within Advisor's own data structures, and solution development involves using Advisor's features to create, extend and redefine these data structures to meet specific needs. Developing solutions for clients is just an advanced use of the tool.

To try to reflect this in a learning or training plan, instead of defining separate technical training, I have arranged the use of Advisor into a series of levels, each of which builds on the one before. By luck rather than design, skills in Advisor fall neatly into ten levels.

• Level 1 – Basic usage
• Level 2 – Data maintenance
• Level 3 – Account administration
• Level 4 – Data type maintenance
• Level 5 – Data management
• Level 6 – Configuration
• Level 7 – Programming
• Level 8 – Metadata
• Level 9 – Branding and style
• Level 10 – Solution structure

After the ten levels, improvement is more to do with design skills than knowledge of the tool. There are three levels of mastership.

• Master 1 – Solution builder – able to build a complete solution.
• Master 2 – Tool builder – able to build a solution that is designed to be extended, tailored or configured by others.
• Master 3 – Innovator – able to map the characteristics of Advisor to business problems creatively.

This structure makes it easier to understand what training people need. For example, people developing new content need to have achieved level 4. People developing different types of components need to have achieved levels 7, 8 or 9. People leading development need to have achieved Master 1, 2 or 3 depending on whether the solution needs to be extendable and whether it is a new type of solution.

This way of structuring skills and training is useful for the specific needs of our product. It communicates how skills need to be developed through a number of small steps, each of which builds on the ones before. But it is different from most technical training. In most technical training, you go on a course and come out with a certificate. But what I think we need is more like a video game, where you work your way through the levels to gain more skills and more recognition. For many people, this is a familiar way to think about skills and achievement. If we want to attract and give recognition to new developers, perhaps we need to rethink how we train them.