The IT Hero Culture Died a Long Time Ago

Once upon a time there was an age of heroes in information technology. The IT heroes could instantly understand and do everything; they were omniscient and omnicompetent . They could tell what line of code was causing a problem by looking at your monitor screen. They could tell what was wrong with your hardware just by hearing the brand name. They spent all their spare time writing code, putting together PC hardware and maybe playing a video game for entertainment.

That age is past. Omnicompetent developer heroes could be like unicorns because neither of them really existed. They are both mythical animals. Or maybe you could say that they’re more like dodo birds or passenger pigeons: they existed once, but overwhelming predation slaughtered them and made them extinct. Or, in my opinion, they are more like saber toothed tigers. They existed once, but the specific environment that nourished them disappeared, and they became extinct.

Omnicompetent developer heroes disappeared because the environment that nourished them – one platform (the IBM mainframe), one or two languages (COBOL, Fortran) and one operating system (MVS) – is no longer the sole environment. The complexity of the current environment for IT and software development is staggering.

Some time ago, Kathleen Dollard, one of my favorite speakers and writers on software development, compiled a list of what’s changed since development methodologies seemed to have become pretty stable. Here is her list and the associated posts:

• Why Your Development is Crazy (the list)
• New Items for the List
• Looking at the List (1 of 6 or 7)
• Looking at the List (2 of 6 or 7)

The complexity of the environment has only increased since then. And this means several things for IT as it goes forward.

First, upper level executives and managers may not understand the complexity of the current development environment. This means that often the sponsors of many current development projects may not be aware of how complex it can be to accomplish the results that they have requested. Moreover, if executive level managers have come from some kind of technical background, they then may attempt to guide current projects from outside based upon their own experience with development projects from years ago. The majority of their actual, hands on technical experience would have taken place prior to the development of multitier applications, Internet and Intranet applications, and interconnected cloud, SOA and microservices infrastructure. Thus, when they try to  guide projects and people upon the basis of their own past experience, they may well stand in the way of the success of those projects and those people. In addition, they may look for heroes like they remember, but they will not find them in the actual people who are writing the software and implementing the infrastructure.

Moreover, putting more time and effort into a project may not be enough to fill the knowledge gaps. The list goes on and on, and there are not enough hours in the day or training dollars for any organization to produce omincompetent developers in everything. Project teams must therefore be composed of a mix of skillsets for any enterprise level application. This means that the person that is needed for the project may not be the best available coder in the development language for the project. The project may need one or two of these best available coders, but it may need others with strengths in other areas – such as someone who has a knowledge of Visual Basic or C#, but is much stronger in CSS and web design.

So then, no one person can know all that is necessary, and this requires development teams to be truly teams. No one brings all the technical competence to any significant project necessary to the completion of that project. This means that developers, though they have been historically an individualistic lot,  must learn to be team players to be effective in the future. This means that IT organizations need to pursue a DevOps mindset more and more as they reach forward to the future.

Next, there’s a lot of items on the list which are not related to development languages. It’s now more necessary to learn languages (C#, Visual Basic, Java, JavaScript, F#, COBOL) + operating environments (Windows, Linux, Unix, MVS) + relational database systems (SQL Server, DB2, Oracle) + user presentation (web client, smart client, character based) + project methodologies(agile) + design methodologies (Object Oriented, Structured, AOP, design patterns).

This shows why a development organization which seeks to remain competent and to remain in business for the long haul must be a learning organization. There must be a continued striving to learn new things and develop new competencies. Instructor led training is expensive and time consuming, and developers that have depended on it must learn to become much more self directed in their learning. Developers who seek to learn and master new things are the backbone of a learning organization, and managers must seek to hire them, retain them, and keep them motivated and productive.

Finally, this means that the developer who takes the initiative to keep on learning is the one who will survive and thrive in the new environment. It means that those who rest on classes taken long ago or degrees earned several years ago may in fact be behind the curve in what is needed to remain competent. It means that being able to search and find information crucial to performing a development task, and being able to learn something quickly is now as important as having done a task; capability and learning speed is now as important as experience and current knowledge.

The hero culture is dead. The environment which nourished it died and killed it. Long live the new culture of the teams of developers and operations personnel - DevOps.