Software development teams are different than the rest of IT. They work in a constantly changing environment facing constantly changing priorities and goals. Legacy systems must be maintained, tweaked, and fixed on an ongoing basis. Web sites require constant fiddling as Web browsers and security systems change the way the client interacts with your sites. New projects with unyielding deadlines are always on the immediate horizon.

Job Description

Software developers' and programmers' duties fall into three or four main categories: maintenance, bug fixing, integration, and new development.

Maintenance and bug fixing can take an inordinate amount of time. Just this week I was working with a major international ASP because we were having some anomalies with its service. The response I got was: "Oh, yeah, we have been having problems with Internet Explorer v6 service pack 2." Now, if these guys are having problems, you better believe you might have some. A few years ago, half our Web applications started to exhibit bizarre behavior because Microsoft no longer was allowed to distribute its Java VM (virtual machine). Of course, we built our product based upon the fact 97 percent of our customers were using IE (and the Microsoft VM). When Microsoft started flipping over to the SUN VM, things broke. I am not bashing Microsoft here. Stuff happens. What I am doing is pointing out, through no fault of our own, we had to throw some of our best developers on an emergency, unplanned, and unfunded project. How about all the security issues we now run up against? I think we should have an automated response on our tech support line that says: "Do not proceed with this phone call unless you are 100 percent certain you have turned off all of your many pop-up blockers." Developers are supposed to be working on new projects–those that will bring in more revenue, not add new expense to an existing product line.

Ghosts

I love wasting my staff time chasing ghosts. You know what I am talking about. One of the VPs calls and says he just got back from lunch with a major client. Seems this client filled your VP with reports your software/Web site/application (take your pick) is not working correctly. Or the customer service manager reports "no one" can access online account information. So, what do you do? With no hard information–with nothing but anecdotal facts–you start spinning your wheels trying to figure out why some guy with an open source Web browser he modified himself can't change his billing address.

Integration of new products and services with existing ones is a developer's job–nothing is plug and play. The insurance industry has taken the lead in the integration world as it hooks up multi- tier Web services applications to legacy mainframe policy systems. System integration is a fact of life, and like death and taxes, it never will go away.

New Products

New product development is the real reason we have in-house software shops, right? At least that is what the CFO thinks. Those developers are expensive resources, and they better be bringing more revenue to the table or significantly reducing costs. Here's the rub: New development is a proj- ect-oriented process. Development teams ideally should be free to work on nothing but that project for the duration. But your best developers are too valuable to allocate to a single project. They have too much corporate and historical knowledge and are too darn good to let them just work on one thing at a time. For example, Bob is knee deep in implementing a new e-commerce solution for online premium payments when you discover a problem with a
three-year-old policy admin system Bob designed. You could put three new guys on the problem and hope the documentation is good enough and they are good enough to do the debugging. Or you could pull Bob off the new project with the expectation he can debug the thing himself in half a day. I'll bet that is what most of us end up doing. And that is a bad practice.

Multitasking

We all want our computers to multitask. We demand they multitask. We have our processors giving us time slices for 40 different processes at once. We expect that because that is a very efficient model for a processor. Unfortunately, it is not a good model for a software developer. We cannot and should not expect our best developers to slice their time between multiple proj-ects and still produce their best work. Software design and coding is an esoteric, sometimes mystical, process. OK, give me a break–I am talking about kick-a** software development, not writing endless data access routines or using a RAD tool. I am talking about the down-seven-layers-into-the-logic process where you don't even know how you got there, where everything is an "aha" and an epiphany. You cannot and should not interrupt that sort of process and pull your developer "off project" for a few minutes to solve some other problem. That few-minute fix may cost you a day in real time. There always will be code monkeys, but good software developers are a rare commodity (in fact, they probably shouldn't even be called a commodity). This is the type of talent we need to conserve and manage properly. This is the type of talent we should not expect to multitask routinely.

A Modest Proposal

The kinds of people we want in our development shops are people who understand our business: how and why we do the things we do–how we generate revenue and how we can reduce expenses. We need people who know and understand not only technology but know and understand business. And maybe the optimal way to use our best developers is by getting them out of the code.

You never are going to be able to insulate senior developers from maintenance work on projects they designed and built. Once you get past first and second line support, you need to go to the source, and the source is the person who built it in the first place. So, we take that as a given. We also should take as a given a developer who totally understands your business processes must be involved in new software development. This is the dilemma: We want our best people on our most important projects, but since they are our best people, we want them on other things at the same time.

Design but Don't Build

The solution is to take your best developers and let them design your projects. Let them find the elegant solution and pseudo code or spec out the project and then turn the coding over to dedicated coders. Let them be involved intimately in new proj-ects but as designers, architects, and managers–not as coders. This is counter intuitive. Any really tough project has elements that require you to get X out of black box Y. Great developers have insatiable curiosities, and they really want to solve that little puzzle, but here again, that is not where you want your best staff. Let the coders figure out these little enigmas.

I mean dedicated coders. Scope out the project, create proper specifications, and hand it off to an outside software shop. (You even could send it to the Love Boat. See "Tech Therapy," page 22, for more on this issue.)

Your best developers can be more effective designing, architecting, and managing. Hand over the package to an outsourced shop, and get on with other work. This will require some management of your internal business sponsors and clients. It will provide you with developers who are able to operate efficiently all the time. It will make your development shop more productive. You no longer have to worry about "burnout" because your team is working 12-hour days trying keep up with maintenance while desperately coding to get a project done on time. Let the outsource shop worry about burnout, because in this case, developers really are a commodity. This strategy may allow you to downsize your shop. Make constructive use of your talented staff. Don't expect it to work on a project mentality all the time. In the long run, your organization will not only be more efficient but save money. You don't need to create a large staff of house developers to handle peak times. Have a staff adequate to cover all maintenance, integration, and new product design. The extra time and money you spend on a per-project basis easily can be absorbed by your smaller, more powerful in-house machine. Even great developers have only so many CPU cycles. Use them wisely.