Developer

Making sense of the developer mind share wars

Companies such as Sun and Microsoft are courting your developers, trying to win them over to their platform. TechRepublic columnist Bob Artner explains why this initiative matters to IT managers and what you should do about it.


As a technical manager, you probably get a lot of mail from vendors. After all, IT managers control a lot of spending and either make or influence platform decisions worth billions of dollars to technology suppliers.

So it’s no surprise that vendors are constantly sending you white papers, informational CD-ROMs, and invitations to breakfast meetings to demo new products. What may surprise you if you check the other racks in your mailroom is that you’re not the only one who is getting buried by vendor pleadings.

In this column, I’m going to look at why vendors are suddenly obsessed with wooing your developers. I’ll also provide some suggestions on what you should be finding out from your programming staff.

Appealing to the hearts and minds of developers
For the best illustration of what I’m talking about, look at the continuing struggle between Sun and Microsoft for the mind share of the developer community. Both companies are lavishing amazing amounts of time and money to woo developers to their platform. For Sun, this means Java, of course, while for Microsoft it’s the .NET initiative in general, and the new C# language in particular.

Both Sun and Microsoft understand that developers hold enormous power when to comes to programming platform decisions within IT organizations. It’s not hard to see why this should be so.

After all, choosing a programming platform doesn’t lend itself to economic analysis quite so cleanly as do other technology decisions. For example, when you are deciding which brand and model of laptop to deploy throughout the organization, you can get your hands on most of the data you need to make a decision: feature comparisons, direct costs, deployment costs, and support costs. You can quibble with the results, but most of the time the process is fairly cut and dried.

On the other hand, when it comes to choosing the principal programming platform for an organization, it’s hard to calculate return on investment (ROI) or even to estimate the true costs of one product vs. another. Now don’t get me wrong; both Sun and Microsoft have reams of white papers outlining the economic advantages of their approach over their competitors. However, the answer doesn’t seem as clear-cut as with many hardware decisions. For the CIO trying to decide between Java and .NET, it’s not a slam dunk.

Therefore, software companies are skirting the technical manager and appealing directly to the developer. After all, if it’s difficult to make a dollars and cents case for selecting a platform, then the desires of the existing development staff become much more important. All other things being equal, the preferences of the men and women who actually have to do the work become critical. (Note: I know that there are important economic arguments made by each vendor. I’m simply saying those arguments don’t hold as much water right now as they do in other technology deployment decisions.)

What does this mean to the IT manager?
This isn’t a new phenomenon, and you might be wondering why you should care. I think you should care because your development staff can wield real power over the programming tools your organization uses.



In my experience, technical managers focus on the platform desires of their programmers only as it relates to retention. In other words, an IT manager will say, “I’ve got to give my folks the chance to work with X [with X being the latest hot technology], because if I don’t, they’ll get bored and leave for some company that will let them work on X.”

This isn’t wrong, but it’s also not sufficient. After all, consider the flip side of that formulation. If you need to move to X to keep your programmers, then you’re stuck with X as your development platform.

Do you want your developers choosing your programming tools? Maybe. After all, they probably have a better feel for day-to-day productivity than you do. On the other hand, you presumably have a better sense of the kind of development you’re going to be doing over the next 12 to 18 months and therefore more thoroughly understand the organization’s needs.

So what should you do? While this is by no means an exhaustive list, here are a few ideas you might try:
  • Find out what your developers are interested in: I know this seems obvious, but too many technical managers don’t have a firm grasp of the aspirations of their programmers. Spend some time, through formal surveys and (especially) through informal conversations, to learn what emerging tools and technologies your people would like to master.
  • Remember that it’s not always about the language: I spent a lot of time in this column using the Java vs. .NET example, but it’s not always about the programming language. Many developers are just as interested in the nature of the application as they are in the language they use. For example, last year developers were clamoring to work on e-commerce projects. For lots of developers, being able to put that kind of work on their resume was more important than the programming platform used to create the application.
  • Be sensitive to the career concerns of your developers: It’s easy to forget that questions about languages are about more than just personal preferences. Developers have to continually improve their skills if they are going to stay marketable. Therefore, these kinds of debates are always going to be front and center with your programming staff.
  • Let your programmers know what’s coming next: Since you probably have a good general idea about what kinds of application development you’ll be working on in the foreseeable future, let your staff know. Discuss what kind of development environment is best suited for these projects. Get them involved not only because you will benefit from their views but also because your developers will understand the issues you’re facing.

Anyone who manages developers is going to have to confront this issue sooner or later. As with all things, it’s better to act than react.

Join the discussion and win a TechRepublic coffee mug
We’re talking about programmers and how their preferences influence your decisions as an IT manager. Join the discussion by posting your comments below. Each week, the person who provides the best feedback to an Artner’s Law column will win a nifty TechRepublic coffee mug.

 

Editor's Picks