Development tools are dangerous

By Andrew Clifford

Choosing development tools is one of the most critical and potentially dangerous decisions that organisations make.

Many years ago, when I was young and keen, I loved development tools. I was a whizz at developing macros and extensions, and was in constant demand for my skills. My employer, recognising my enthusiasm, made be responsible for development tools.

Part of the work that I took on was to review the development tools used across the organisation.

The results I found have haunted me ever since.

The review focussed on a few questions: what makes IT development so difficult, how do people use their time, and what development tools should we use?

I only remember the main findings.

IT development was difficult because the organisation used a lot of out-of-date tools and languages. For example, we had a lot of Visual Basic version 3 code, which needed to be rewritten to version 4. Similar problems existed on every platform - most of our code was written in old, unsupported, tools and versions.

The use of time was really surprising. Programming new code took only 3% of the time of the largest development department. Nearly all their time was spent investigating existing code, testing, and analysis.

Lastly, there was phenomenal consolidation in the development tool market. In the early to mid 90's, the client/server tool market went from over 100 vendors down to just a handful.

I concluded that the viability of development tools is critical, and that programming productivity is almost irrelevant. People like me, who introduce and extend new development tools to speed up programming, were causing more problems than we solved.

15 years on, history is repeating itself. There has been a rash of new development tools, for rich internet applications, integration, and business process management. These are sold on productivity, allowing new business requirements to be met with a few clicks of the mouse.

As these tools mature, the market will consolidate. Many suppliers will fail, or bring out new, incompatible versions. Organisations will spend so much time patching up their new "legacy" systems that they will not have time to respond to new business requirements.

You can protect yourself:

• Think about the technologies beneath the development tools. If you do not know them or can not understand them, avoid the tools.
• Create simple designs and clear system structures that can be readily understood independently of the tools.
• Stick to standards-based programming languages with a good track record of version compatibility. Avoid proprietary extensions, or anything else that elaborates your code and undermines the standard.
• Choose tools that support your design and language, not dictate it.
• Assume that your current tool vendor will fail.
• Migrate to new versions aggressively. It will not be easier later.

I am not against development tools, and there are plenty of effective, productive and safe tools out there. But it is such a critical choice that you can not leave it to the vagaries of programming fashion, or give in to the perceived constraints of short-term management.

Subscription