Today we have a guest editorial from Phil Factor.

IT departments often tend to be loathed or derided by the Businesses that employ them.  Most businesses have to react quickly to changing economic circumstances, make compromises, and take risks. Business managers have to take decisions impulsively. IT Departments, in contrast,  soon develop an arcane cocoon of policies, reviews and procedures that are guaranteed to slow  any application development to a crawl.  They can’t keep up with changes in the business. Even worse, they sometimes even deny the need for change. The staff of IT departments are seen as alien creatures who think in a pedantic super-logical way. In its own way, IT sees the intuitive decision-making of businesses as being due to lack of rigorous thinking. Gridlock.

I have seen many businesses and government departments actually go to the lengths of concealing the development of key IT applications from their IT departments just to get things done.  Usually, the loophole is that the Microsoft Office suite is seen to be merely an office productivity tool. Outside contractors will sneak in vast Excel spreadsheets or Access databases that trespass on the scale of large corporate SQL Server databases.  Once these systems become indispensible, the IT departments will be encouraged to ‘do it properly’, to legitimize things.

The contemporary zeitgeist of corporate and government  IT has lost the art of quick and dirty IT developments.  Despite the Agile initiatives, whole new species have been known to evolve in the timescales of some IT initiatives. When Charles ‘Chuck’ Moore voices the opinion ‘Get a bare-bones application running quickly. Demonstrate it and get feedback from users. Then modify and expand capability: much more satisfactory than planning in advance’,  the man who is one of the founding fathers of modern IT, and whose software underpinned the success of the space program, seems like a young hothead. The truth is that his generation thought in terms of weeks rather than years for software development time.

Agile methodologies aren’t, by themselves enough. The change in thinking has to insinuate itself throughout corporate IT culture. Even the technology must change.  Most of all, we must once more permit ourselves to create applications that are simple, temporary fixes, using an architecture that encourages software change.