It's not meant to be hard

By Andrew Clifford

Solutions should be simpler than problems, and development processes should be simpler than solutions.

I've been giving some training at a partner company, training their people in the Metrici platform. We've been through the basics easily enough, but when we got to the sessions about designing whole solutions, I didn't know what to say.

Of course we know how to develop solutions. Most of our work involves creating complex assessments, and we have evolved effective patterns for that. But Metrici can be used for many other information management tasks, and I had never really thought through how best to approach the design of these.

In IT we have a tendency to systematise everything, and our gut reaction is to think up some sort of structured design method. But systematising your processes can easily lead to a method that is more complicated than the solution you are trying to create.

The whole point of IT is to make things simpler and quicker. If you can complete a task (to the right quality, etc) in one hour without an IT system, then if it takes you more than one hour with an IT system, the IT system has no value. The solutions that we create must be simpler than the problems they are intended to solve. Similarly, if it takes us, say, one day to write a program (including documentation, validating the requirements, testing, etc), then if it takes us two days if we follow a method, the method has no value. The methods and processes we follow should make things simpler and quicker, not harder and slower.

Traditional systems development is hard, and structured methods and processes add value. But simpler tools like Metrici are a different proposition. Metrici is good for the sort of information management tasks you could do in Excel, but when you want it multi-user, on the web, properly managed, and looking like a proper application. The underlying development process is about as complicated as building the same functionality in Excel, which we wouldn't usually surround with lots of complex processes because it isn't worth it.

Instead of presenting a structured method for developing Metrici solutions, I realised I needed to communicate the important aspects of development. These are the same whatever technology you are using. It is really important to establish and validate the objectives and purpose of a solution before you start the design. It is really important to think about outputs and how they deliver value before you create the inputs. Once you have done that, the "method" is to build the solution incrementally, starting with the outputs and working back.

If you are using technologies that are inherently simple, surrounding their use with structure and formality can undermine the simplicity of the technology. Of course you need to control the development activity, and I am not suggesting that you do away with controls on requirements, testing or deployment. But the development process itself, the analysis, design and build, needs to be tailored to the technologies you are using. Your processes shouldn't be more difficult than the work they contain; if they are, you need to change your processes.

Subscription