Guest Opinion

Expand Your Skills, or Perish

The software world is changing-fast-and you need to adapt to these changes if you want to remain relevant from a professional standpoint.

• By Peter Varhol
• 03/01/2006

Fifteen years ago, I was a college professor. One evening, a student visited me who was a professional C programmer. Specifically, he was a wiz at Borland Turbo C 3.0, confident that that particular skill, using that particular tool, would be his ticket to a rewarding career in software.

Unfortunately, all attempts to transfer his expertise to other technologies were doomed to failure. While learning Smalltalk in an object-oriented programming class, he attempted to compile a Smalltalk program by first importing it into Turbo C. I often remember this gentleman when I see the ground shift in the market demand for specific engineering skills. This particular image came to mind while I was at VSLive! in San Francisco in January, listening to David Chappell give a presentation to well over fifteen hundred Visual Studio developers on using BizTalk and the Windows Workflow Foundation to do orchestration of services across a complex business process.

More than any news story on IT careers, the sight of software engineers paying rapt attention to building entire business workflows brought home the message that the role of the traditional Visual Studio developer is changing dramatically. Sure, enterprises still need bread-and-butter custom applications to meet the needs of their business processes and their customers, but these types of applications are being outsourced increasingly, whether in the U.S. or overseas.

Another factor weighing in is the productivity improvements built into new generations of development tools. Templates, patterns, and abstractions are making engineers more productive in building applications. Applications are getting written and put into production more quickly than ever.

But one collateral result is that the opportunities for engineers who want to code new applications from scratch are decreasing. Yes, there is still the need for engineers who work for software vendors in building new tools, end-user applications, and middleware, but this is a small percentage of the profession, and is likely to remain so in the future. A somewhat larger percentage will continue to perform traditional software engineering activities in enterprises and government, but the total number will gradually decline. New applications will be more about defining services and workflows than about writing new code.

What enterprises increasingly need are engineers who can envision the architecture before it is built, and then can fit the pieces together once they have been built. The former is the role of the architect, who defines the computing infrastructure and parameters by which applications are built to fit into that infrastructure. The latter is the role of the application or service integrator, who designs application integrations, workflow orchestrations, and business processes.

Those are considerably different skill sets than most engineers have developed in the past. Many engineers will have to adapt to one or the other to remain professionally active and relevant in software. Proficiency in C# and Visual Studio won't be enough.

This is not bad news, but it is a wake-up call. Many young people get into software engineering out of a passion for solving complex technical problems. Complex problems will continue to exist, and likely grow in number, but the nature of those problems will be different. If you're in college now, recognize that coding skills may be a prerequisite to starting a career, but such skills won't keep you in that career. Consider adapting your course work in one of these directions, even as you gain a foundation in computer science and software engineering.

If you're already in a coding job, look for ways to grow your skills into one of these roles. If you can envision what a solution could look like, and how that solution can be seamlessly inserted into an existing application infrastructure, you might have the foundation to be a top-notch architect.

On the other hand, if you can take individual applications, turn them into services, and make those services work together to solve real business problems, you should try to grow into the integrator role. The job of making applications work in a services-oriented environment will possibly be the most important and valuable skill an engineer can possess.

What you cannot do is be inflexible, like my long-ago student. I certainly hope he eventually adapted to the next wave of technology after Borland Turbo C, but I have my doubts. You can do better.