Some historical context

As a student of martial arts, I was always made aware that the techniques that I was being thought were developed over hundreds, if not thousands of years. Many of these techniques were developed by practitioners who learned the sum of existing knowledge from their masters; who then broke away to develop their own techniques and principals; perhaps in turn forming their own schools to spread their techniques to new students; thus completing the cycle of continual development.

There are generally two competing mindsets at work in a situation like this at any given time. The first philosophy states that what we have been using for years is effective, proven in battle, and well understood by all: so why should we change it? While it is true that we need to conserve the teachings of master practitioners and "best practices", a strong level of conformity can suppress innovation.

The second philosophy emphasizes the need for continual innovation. While break away students forming their own schools are often labelled as egomaniacs by their piers, these mavericks serve an important role in breaking the status quo that often exists in small communities of expertise, by challenging the community to re-evaluate commonly held beliefs on what exactly are the best practices in the field, and what tools can be used to achieve higher levels of excellence. In essence, a community without mavericks is not a healthy community.

Innovation in the IT industry and community

Innovation in the IT domain has largely followed a similar path to the one described previously, albeit over a much shorter period of history. While large computer corporations strive for the simplicity of a homogeneous market, renegade innovators such as the open source community aim to keep that market as diverse as possible. In fact most of the main software related innovations in recent years, such as the Linux operating system; [1] the MySQL database; [2] the Ruby, Python and PHP programming languages; [3-5] have all come from the open source community. In stark contrast, many of the large software corporations have instead opted to concentrate on improving existing technologies with new version releases.

IT practitioners can be responsible for maintaining this brake on innovation. For example if a computer programmer learns language X in college and works with this language for ten years, and is then suddenly asked to abandon language X for language Y: it is usually true that the programmer will be reluctant to do so. After all, the programmer has invested a lot of time and effort into being highly proficient in language X, so why should they now abandon it?

The role of the IT manager

Invariably the decision on which new technologies a development team will adopt will rest with an IT manager. The problem often arises however that the person employed in this role will not be from a strong IT background: for example they may hold an IT-related business degree rather than a pure computer science degree. The rapid emergence of new technologies, especially those emulating from the open source movement, further complicates the role of IT managers in evaluating the best approach to take.

An IT manager, particularly a project manager, needs to protect the future of any projects currently under development. Any technologies in usage must have wide support and be easily understood by a large user base, including some or all members of the development team. To balance this, projects must not be built on depreciated technologies, or technologies that are soon to be redundant. Software developers may live in fear of their skill-sets becoming redundant, so they are often tempted into continually advocating the use of the technologies that they know best to their managers.

In this scenario, it is the responsibility of the developers to gain new skills on a continual basis by exploring and developing new technologies and techniques. The IT manager has the responsibility to protect their project deliverables and medium-term technical longevity, while keeping an eye on future trends in the industry for potential long-term migration to new platforms. The manager must also ensure that the correct environment exists at team level to encourage experimentation within a controlled environment, for example on test servers of code that is separate to the production code base.

Benefiting from early adopter advantage

Organizations often try to benefit from any competitive advantages that technology has to offer, although such advantages are often short lived as competitors catch up. For software developers switching from one programming language to another, there is usually an overhead associated with the process of getting developers to accept new changes and methodologies that might also require training. Furthermore legacy code from previous versions of software might actually have to be abandoned and such systems rewritten from scratch. So why make the change to a new programming language?

Software development is a very time consuming process, especially when projects become large enough to require large, unwieldy development teams. Light-weight agile methods such as RAD (Rapid Application Development) try to address these problems by keeping teams small and dynamic, with the ability to change quickly to meet changing end users requirements. In theory such methods will help an agile team to outperform a larger, bureaucratic team in terms of development time, while the same amount of functionality is still delivered to the end user. Such an approach is useless however if the technology is not in place to support rapid development.

Conclusion

A typical end user does not care about what programming language is used to build a system, what design methodologies are used, or how easy it is to maintain the code behind the system: all they care about is getting a system that works as it should, that it is bug free and is delivered on time. The project manager and development team that can meet these business requirements will be thought of as successful by the customer, not the team who took twice as long to deliver the same functionality in order to "do things like we always do", i.e. using outdated technology and design methods.

If a new technology offers even the promise of competitive advantages, one of the latest examples being the Rails framework written in the Ruby programming language [6], then they should be explored fully by developers and IT managers wishing to deliver quality software to there clients in ever decreasing amounts of time and cost. Early adapters will always benefit: by dismissing technologies early as being unsuitable for their needs, or by embracing new technologies that give them real advantages over their competitors. All others ignore or dismiss innovation to their detriment.

References

[1] Linux Online Inc (2005) The Linux Operating System Home Page, http://www.linux.org/, Date Accessed: July 2005.

[2] MySQL AB (2005) MySQL Database Home Page, http://www.mysql.com/, Date Accessed: July 2005.

[3] The Ruby Project Team (2005) Ruby Home Page, http://www.ruby-lang.org/, Date Accessed: July 2005.

[4] The Python Project Team (2005) Python Home Page, http://www.python.org/, Date Accessed: July 2005.

[5] The PHP Project Team (2005) PHP Home Page, http://www.php.net/, Date Accessed: July 2005.

[6] The Ruby on Rails Project Team (2005) Ruby on Rails Home Page, http://www.rubyonrails.org/ , Date Accessed: July 2005.

---

Updated 2021 : note that the above post, while still relevant, was originally published in 2005 and is left here for archival purposes.