Over the past forty years, the thought patterns of people working in the information technology industry have slowly narrowed from the creativity of contributing generalists (Polymathic thinkers) to process-driven software delivery that rely on armies of specialists.

At the beginning of the industry’s Agile journey, Agile teams were designed to include an one or more generalizing specialists. These people leveraged thought patterns that were the sweet spot between people who know a lot about a narrow domain, and generalists that know a little about a wide range (aka “scanners”). Polymaths were rewarded both professionally and financially.

The Frog Began To Boil

In 1988 in a midtown Manhattan consulting company office, an Indian company named Tata Consulting sublet space . They gained a toehold into the financial industry with three visible people crammed into one office. The unseen part of the equation were the 100’s back in India. We worked in the office and only a few of us “got” what was happening. Who knew what would happen next? Ed Yourdon did. In 1992, Ed Yourdon wrote “The Decline and Fall of the American Programmer”. Most technologists ignored his books and articles, or they just didn’t believe them.

In the late 1990’s certifications became popular. This appeared to be the golden ticket to make recruiting technical professionals simpler. All a recruiter now had to do was search for a certification acronym, and the premise was that the person they found was a perfect fit. Generalists saw their pay rates drop, until they acquiesced and narrowed their skill sets deliberately. First they saw their pay rise, then drop like a rock again, as the skills became commodities and tasks requiring commodity skills were sent offshore in greater numbers. The process was mirroring what happened in American manufacturing decades earlier.

The year 2000 proved to be the tipping point. Businesses were faced with a lack of resources to check all their code to eliminate two digit years. The software development outsourcing to India and Japan that had been predicted s came true. When corporate information technology budgets were exhausted shortly after the dawn of 2000, many people were rapidly ejected from the industry. Many 30-something men and women left to form restaurants, construction companies, promotional marketing companies and more. These were my cohorts - my first peers. And the software delivery process model continued to change to value specialization over generalization.

Today we create software factories that are built on the premise that components can be assembled like tinker-toys into working solutions using patterns. And processes of automated testing and deployment can shrink the time to market and improve software quality. There is no need to think, because just assembly is required. Yet somehow when you step back and take a look - you can see that today it takes more people to build complex software than it did in 1984 - not less. Medium-sized software solutions that used to take a team of five to seven people to build in the late 1980’s using a combination of generalists and generalizing specialists (Polymaths) now takes an army of over twenty-five specialists to build using an offshore model, service level agreements and contracts. In many places, the specialists don’t even really understand the overall objective of the software they are building - or how it empowers business operations to work better, safer, faster or more profitably. Is this really a good thing? How does this empower innovation?

So here is a question: Do we really have a shortage of information technology professionals? Or in the mechanization and de-humanization of software design and delivery, did we just simply break the way software is delivered? Did we by collectively place too much value on specialized skills, and not enough on the generalized thought patterns needed to leverage all the specialized skills?

Do we really have a shortage of information technology professionals? Or in the mechanization and de-humanization of software design and delivery, did we just simply break the way software is delivered? Did we by collectively place too much value on specialized skills, and not enough on the generalized thought patterns needed to leverage all the specialized skills?

We Can Fix This

We can collectively change the business of software to “highly value” the polymaths and their contribution to the practice of software development. This should reduce the number of specialists required to do things, and should also improve the cohesion of assembled solutions. Read Part 2 of this article February 22nd to learn how to best leverage a Polymath during the software development process.