Minimal IT logo and link to home page
Research, training, consultancy and software to reduce IT costs
Home | About | Newsletter | Contact
Previous | Next Printer friendly
27 September 2011

Bootstrapping 2: Why are there so many tools?

By Andrew Clifford

Have we created more tools and techniques than we really need?

Last week I described how the capabilities of our MA2 product are developed within MA2 itself, and that we are currently bootstrapping a fully-fledged product from an initial core. This bootstrapping does not just cover product features, like survey tools and reporting tools. It covers sets of questions, website content, documentation, and even administrative tools such as contact forms and bug tracking. We are using MA2 to create all of these within MA2.

Because we are using the same tool for everything, we end up using pretty much the same techniques all the time. Everything we create requires the definition and structure of information, writing content, considering how users will interact with the system, and occasionally hand-crafting processing rules. This is true whether you are writing a survey tool, or presenting a handbook on the web, or creating a bug tracking utility.

Different types of requirement can easily share the same solution. We created a shortcut menu to make it easy to develop questionnaires, and found it was just what we needed when replying to questionnaires. If we had different tools, we would not have seen the similarity and would have two solutions.

The issues that we hit are much the same. For example, MA2 is extremely flexible, and we have to think how much flexibility we expose for each different use. How many different ways should we give people for defining survey questions, or for specifying what links should be available from pages, or what should be in the API for a scripting library? Without tool limitations to make the decisions for us, we face the same issues for different types of requirement.

Even the problems are the same. MA2 automatically recalculates data when the information on which it depends is out of date. Normally this works in the background without disrupting the user. But some bulk activities, such as generating thousands of tailored questionnaires for a survey, can be slowed down by the constant recalculation of pages that index the surveys. To get around this, we added options to control whether and when indexes are updated. Later, we found we had the same problem developing strongly interlinked metadata libraries, because everything changes when anything changes. We could use the same solutions to get round the problem, even though the requirements are different.

Different activities, such as development of product features, development of assessment content, writing web pages, and setting up administration functions, are much more similar than we usually think. All of them can use the same tool, require the same techniques, raise the same issues, and share the same problems and solutions.

This has really made me think. Do we have lots of different tools and techniques because we have lots of different types of requirement? Or do we just think we have lots of different types of requirement because in the past we have used lots of different tools and techniques? Maybe we have made IT much more complicated than it really needs to be.

Next: Bootstrapping 3: Building a business


To subscribe to the newlsetter, simply send an email to
Privacy policy

Subscribe to RSS feed

Latest newsletter:
Magical metadata

We use the term "metadata-driven" to describe IT solutions in which functionality is defined in data. Taking this to the extreme can provide unparalleled levels of speed, simplicity and versatility.
Read full newsletter

System governance

System governance helps you implement high-quality systems, manage existing systems proactively, and improve failing systems.

Try it for free!

Find out more