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
7 November 2006

StupidClever

By Andrew Clifford

We need a new word - stupidclever - to describe stupid things that clever people do. There is a lot of stupidclever in IT.

I think of myself as a fairly clever guy, but over the years I've done some stupid things.

I've spent half my career building tools and frameworks.

I've built code generators. I've put together development frameworks - for character-based screens, client/server, and web applications. I have built design tools and repositories. I must be really clever.

In hindsight, most of this has been really stupid.

Some of it has been stupid because nobody needed it. I once wrote a tool for generating test files and database tables using all sorts of random data routines. Nobody used it. It was a complete waste of time.

Worse than that, some of it has been stupid because everybody used it. Some of my tools have been really successful, the mainstay of my employer's IT for years. Now they are stuck. Their systems depend on non-standard, out-of-date code that has never been developed further. Their systems can not easily be migrated to something newer.

Most of the stuff I have developed falls in between, which is just sad. It has been used a bit, and is just a tiresome legacy.

It's not just me. I know of a large UK bank that wrote its own indexed file system 30 years ago. That was really clever. But it is really stupid to still be using it now, when large-scale databases have been mainstream for 15 years.

I'm sure your organisation has lots of stupidclever IT, too.

Of course you need to be a bit clever. You need to make the best use of technology. You want to achieve reuse. You want to beat your competitors.

But we take it too far. We are so clever, we become stupidclever.

Here are my hard-learnt rules for avoiding stupidclever home-written tools and frameworks.

  • Only develop your own as a last resort. Work with the standard implementation. Find a framework or tool that is already well supported (there are excellent open source products out there).
  • Don't better your vendor. If your tool vendor does not think something is worth doing, it probably is not worth doing.
  • Go for minimum impact. If you must develop your own tools and frameworks, make them as small and separate as possible. Do not build fully integrated tools that go from logical design right down to code. Just develop little bits that you can easily remove.
  • Get out as soon as you can. If you have to develop your own, replace it with a good standard implementation as soon as there is one. To justify the replacement, explain that without it the system will become unsupportable.
  • Think of the long term. Do not design for speed of development. You will spend a lot more time looking after and eventually replacing your system.
  • Don't go it alone. If you really need a new feature or a new tool, work with other people. Ask your vendor to add your new features, or contribute to an open source project. In the long term, you will be better supported by sharing than by keeping it to yourself.
Next: StupidClever methods

Subscription

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.

Find out more