Matching Tools to Developers
Instead of just matching the tools to the job, consider the basic types of developer to better understand how to deploy Visual Studio .NET.
by Thomas Murphy

November 2002 Issue

One of the key value propositions of Microsoft's .NET Framework's is that Common Language Runtime (CLR) support makes all languages equal. The Visual Basic programmer is no longer the brunt of jokes—VB can do everything the "real" object-oriented languages can. However, this message of language equality has left many confused over how to choose which language to use when moving to .NET. Defining application patterns (categorizing architecture, scale, and use) offers one way to determine which language to use. However, I'll take a different track and look at developer patterns (groupings based on problem solving tactics, tool use, and mind set) to help you determine how to best match technology to the people and, therefore, achieve the best results from the job. I'll start by discussing three broad categories of developers: opportunists, pragmatists, and perfectionists, then discuss which languages will most appeal to them.

Thomas Murphy

The Opportunistic Programmer
The opportunist works in the here and now and wants to create solutions that simply work. He's focused on getting the job done quickly and efficiently while staying focused on the immediate business problem, the current function, and the current line of code. This tight focus drives a need for development tools that support interactive, immediate feedback that are component centric and "wizard" driven. Because this developer favors problems that can be solved "today," he's also likely to spend little time on analysis, preferring to jump in and learn as needed. Anything that "gets in the way" of productivity (such as documenting code) is of questionable value, and he believes reuse means finding example code.

The Pragmatic Programmer
While the opportunist just wants to get it done, the pragmatist wants to get it right—to build lasting solutions. This means she uses tools differently and approaches problems from a completely different angle than the opportunist. Because she's building the solution to last, it's more important to spend time analyzing the problem and creating a well-factored solution. She is also more code focused and wants to understand generated code. However, this developer is also balanced, looking for productivity in tools and frameworks. In general, she has a broader scope and parallel approach.

The Perfectionist
I began my programming life as this type of developer. I worked on embedded systems and had simple constraints: make it small and make it fast. This developer strives to build systems that receive technical praise and, like the reference books he consumes, becomes a "virtual reference manual" on the problem. He views generated code skeptically, because everything is about the code: Is it flexible? Does it perform? Is there excess? Does it behave as expected? Instead of working on a single file and focusing on a particular method, the perfectionist has a system perspective and works on many files at the same time.

Cast In Stone?
That said, developers aren't cast forever in a particular mold, and, to a certain extent, we are shaped by the tools and languages we use. Although the perfectionist loves the control of low-level languages, these languages exacerbate paranoiac behavior because they introduce hard to find memory errors and directly access system functions. As I shifted from low-level languages toward object-oriented languages, such as Smalltalk, I became a more pragmatic developer. However, I still brought perfectionist attributes—re-factoring, self-documenting code, and orthogonal design—with me. Therefore, although it's possible to migrate developers, I believe it's more important to recognize the need for different types of programmers to address different types of problems, such as line of business applications, core business logic or infrastructure, and computationally intense code.

In the Visual Studio .NET world, Visual Basic generally addresses the needs of the opportunist best. The environment and language are designed to support immediate feedback. (For instance, it complies each line of code as it's entered.) "Watch what cool thing I can build in the next five minutes" is the VB mantra, and if you have opportunistic developers today using VB, shifting them to any other language might greatly frustrate them.

C# and J# are languages targeted at the pragmatic developer, because they're most commonly used to build applications for long-term use. This is why the .NET Framework is created in C# and why I expect this language will continue to gain some features-such as example templates and multiple inheritance-that might be consumed, but not created, in VB. Finally, C and C++ will remain languages with dual personalities: one raw and untamed, designed to get to the metal, and the other managed, offering a more secure environment.

It's true that in a managed code world all these languages look very much alike, but the tools surrounding the languages and the languages specific functions will continue to match the needs of the developer patterns I've discussed. Microsoft recognizes they exist and so should you. Match your developers to the tools, languages, and problems and you'll find them happier and more productive.

About the Author
Thomas Murphy is currently a senior program director with the META Group, an IT research and advisory service, where he focuses on enterprise application development methods, tools, and architectures. You can reach him by e-mail at .