In the February 28th 2011 edition of Information Weekly, Chris Murphy wrote an article called “IT Is Too Darn Slow.” Chris’ article can be summarized best by “isn’t about the speeds and feeds of technical performance, of gighertz this and gigabit that.” Chris goes on further to suggest that cloud computing, virtualization, and agile approaches are allowing CIO, CEO, and the rest of the board of the directors too demand quicker results.

I really agreed with the premise of the article although I haven’t really spent a lot of time working with virtualization. Virtualization allows us to consolidate multiple servers onto one server by allowing multiple operating systems to run on the same hardware. I really believe that being able to spin up new servers would allow development and changes to happen much more quickly.(At the very least virutalization can help all organizations save money on machines, power consumption, and air conditioning!)

Cloud computing is essentially taking distributed virtual machines (or raw hardware even) and allowing an application to make use of all the hardware and expanding as necessary. As Chris discusses in the article this allows a company to quickly add more infrastructure to meet demand which could allow for almost limitless usage.

Agile software development is based on the concept of spliting up programming tasks into very small and quick tasks and allowing the user to quickly begin to use the application and make changes as the process continues. The idea is that the user/ company can get software that meets their needs and is quickly adaptable as needs of course change.

Over all, I really felt that Chris has written a great article although I’m not sure that HP and some of the others he has discussed will be able to meet their goals of having nearly all projects under 90 days.

One point, I felt could have been stressed more in the article is that when you make software quickly and release that software when it is “good enough” is that it may end up being costly to change it later because of some mistake or incorrect assumption. We always need to invest some time in testing, and sometimes all that testing can’t be automated.

What do you think?