Guest Opinion
Pace of Change Leaves No One Competent
The pace of change is on the verge of putting one-man shops out of business; no one is capable of remaining truly competent as a general .NET programmer.
The point at which anyone on the planet is competent to write .NET applications passed sometime in the last year or so. No one is competent and that should scare the crap out of us. Recognizing this reality lets you adjust your application strategies. Failing to recognize it will leave you frustrated and feeling inadequate. Fortunately, the world is not coming to an end; there are both short term and long term strategies.
Historically, competence meant you knew enough about Microsoft technologies to pick the best ones for your applications. You knew core technologies well and used them effectively. You were familiar with the tools you used. Your code was fast, high quality, documented, and secure. You understood how to interact with data and other applications. Beyond coding, you had a proper development environment.
Today the standard for competence means staying on top of rapidly evolving languages, enormous libraries, diverse data stores, and complex toolsets. The security landscape is more dangerous. Quality code must be friendly to globalization and accessibility. A proper development environment includes source control, FxCop, testing, and deployment as well as tools for designing, profiling, requirements tracking, and defect management. Interacting with data means traditional servers, caching, XML, SQL Server Compact Edition, Analysis Server, and Reporting Services. Interacting with other applications might mean Web services, up to three different Office models, IIS, Exchange Server, and SharePoint Server. The introduction of WPF, WCF, WF, and Ajax pushes the technology stack beyond the point any programmer on the planet can be competent. And then there is Orcas?
Three years ago, I raised a storm with an editorial that described hobbyist programmers as canaries in a coal mine ["Save the Hobbyist Programmer," VSM April 2004]. The effort required to uptake new technology exceeded what hobbyists or domain programmers had available. The canary metaphor was that their demise was a warning for the rest of us. The air is still getting thinner. This year we'll lose the one-programmer shop and solo application development.
No one has time anymore to maintain competence in .NET development. Of course no one can be competent in everything. But today no one can be competent in writing thoroughly modern, high quality applications in any specific genre (such as Windows or the Web). The surface area of what you need to know is simply too large.
Short-term strategies are specialization and faking it. "Faking it" is a harsh phrase, but means you pick off only the most critical new technologies. You must be pragmatic rather than theoretical, and remain dependent on old technology.
You can pair faking it with a strategy of specialization within teams. Individuals can be competent in different technology niches. Success depends on finding and retaining a complementary core group, with turnover the greatest project risk. You augment your team with expert consultants offering short-term expertise and targeted training.
Specialization is out of reach for the one-programmer shop. Reliance on "faking it" means this shop can't uptake the breadth of new technologies. It's unlikely to write applications that meet evolving quality standards, including testing and FxCop. These shops are being marginalized and en route to extinction. This year's canary is the one-programmer shop.
When I wrote the canary editorial, I was throwing my hands up, despairing what would happen as canary after canary disappeared. Every attempt to simplify development increases the surface area of knowledge required for competence.
I am more optimistic today.
I am optimistic that these strategies can buy us time for the world of .NET development to revolutionize the world around us. Underlying recent releases from Microsoft is a new level of abstraction, expressed differently in WPF, WF, and LINQ. The shift behind XAML, DSLs in Workflow, and language extensibility is huge. The best of these abstraction strategies will eventually extend past core libraries into most business programming.
It's not going to be a single product like VB3 tackling the Windows API, and it's not going to happen overnight. It's going to be a tough road requiring patience, intelligence, and hard work. But .NET development will fundamentally transform over the next five years making it easier to focus on business problems beyond today's fog of technology.
The revolution has begun.
About the Author
Kathleen is a consultant, author, trainer and speaker. She’s been a Microsoft MVP for 10 years and is an active member of the INETA Speaker’s Bureau where she receives high marks for her talks. She wrote "Code Generation in Microsoft .NET" (Apress) and often speaks at industry conferences and local user groups around the U.S. Kathleen is the founder and principal of GenDotNet and continues to research code generation and metadata as well as leveraging new technologies springing forth in .NET 3.5. Her passion is helping programmers be smarter in how they develop and consume the range of new technologies, but at the end of the day, she’s a coder writing applications just like you. Reach her at [email protected].