2003-05-09 13:53:24

Small ISVs:  You need Developers, not Programmers

Context is critical.  Management advice can be worthless or worse if it is not appropriate for your situation.  The right decisions for a big company can be fatal in a small one.  Make sure you consider your context before you listen to anybody's management drivel, including mine.  :-)

I run a small ISV (Independent Software Vendor) with no substantial outside funding.  SourceGear is 6 years old and has 25 employees.  I've learned plenty of interesting lessons along the way.  One of the things I've learned is that a small ISV should not have any programmers.

For the purpose of this article, a "programmer" is someone who does nothing but code new features and [if you're lucky] fix bugs.  They don't write specs.  They don't write automated test cases.  They don't help keep the automated build system up to date.  They don't help customers work out tough problems.  They don't help write documentation.  They don't help with testing.  They don't even read code.  All they do is write new code.  In a small ISV, you don't want any of these people in your company. 

Instead of "programmers" (people that specialize in writing code), what you need are "developers" (people who will contribute in multiple ways to make the product successful).

My apologies if I'm trying to be too cute with my word definitions, but it really doesn't matter what terminology you use.  In a small ISV you can't afford to have people who think their only responsibility is writing code.  There are far too many other things to be done, all of which are critical to having a successful product.  If you were a BigCo, you would just hire more specialists until every job function is covered.  But as a small ISV, what you need are fewer people who are more versatile.

Boundaries vs. Flexibility

This is a really important difference between small companies and big ones:

• In a small firm, most people wear multiple hats.  It simply isn't feasible to have a person who focuses on just one small area.  Small companies need versatile people who are content and capable to step in and do whatever it takes to help the company succeed.  One accountant or bookkeeper handles basically everything.  There is often a utility infielder who is always busy but nobody knows what they do.  The key concept here is flexibility.
  
  
• Big companies have more specialists.  Payroll is different from "accounts receivable" which is separate from "accounts payable".  Architects do design.  Programmers write code.  Technical Leads manage programmers.  Program Managers keep the spec and schedule.  Product Managers do positioning and message.  Evangelists do, er, well, nobody really knows what evangelists do.  :-)  Anyway, each person has a specific, well-defined job.  The key concept here is respect for boundaries.

By the way, these are two very different cultures and ugly things can happen when they intersect.  Flexibility and boundaries don't mix very well.  A person who has been successul in one of these cultures often stumbles badly when they transition to the other one.

Developers

In a small ISV, every developer is first and foremost a programmer.  The bulk of their time should be spent writing code and fixing bugs.  But every developer also needs to be involved in other areas such as the following:

• Spec documents
• Configuration management
• Code reviews 
• Testing
• Automated tests
• Documentation
• Solving tough customer problems

Using my terminology, these things are the difference between a programmer and a developer.  The developer has a much larger perspective and an ability to see the bigger picture.  The programmer writes code, throws it over the wall to the testers and waits for them to log bugs.  The developer knows it is better to find an fix bugs now, since he just might be the one talking to the customer about it later.

When your team evolves from programmers to developers, your pecking order may change.  Your best developer may not be the person who usually gets thrown the really tough problems.  A programmer of amazing talent can be a lousy developer.  Coding is a necessary but insufficient part of being a developer.  Similarly, the less gifted members of your team can still distinguish themselves as excellent developers through their contributions to the non-coding parts of the product.

Frequently Asked Questions

Can't we just let our programmers be coders and hire a separate group to do everything else?

Maybe.  SourceGear has tried it this way in the past, and sometimes it has worked well.  But in the long run you will regret the decision to insulate your programmers from everything but code.  Programmers in a small ISV have too much influence to let them have a narrow perspective.  Make them see the perspective of the user.  Put your programmers on the phone to help a customer with a tough problem.  Your product quality will improve as you expose programmers to the consequences of the bugs they create.

Our programmers don't know how to do all this other stuff.

Really?  Surely the university CS programs are teaching SCM tools and tech support skills, right?  :-) 

Yeah, my school didn't teach this stuff either.  It's a foregone conclusion that your programmers don't know how to do the non-coding aspects of product development.  Teach them.

Formal training might play a part here, but the best learning comes from experience.  Your developers need to borrow the advice of Nike and "Just Do It".  Make sure they are allowed to fail.  Let them learn from their mistakes.

Our programmers don't want to do all this other stuff.

Some people don't want to be developers -- they want to be programmers.  That's okay.  A programmer can have a fine career.  But you and the programmer may want to talk frankly about whether your small ISV environment is the right fit.

Ultimately you can decide to manage this in whatever way makes sense for your context.  I'm suggesting that every programmer in a small ISV needs to be getting involved in something beyond the code, but most rules have exceptions.

Isn't it rare to find developers who have such a diverse skill set?

Yep.  True developers are precious  You probably can't hire them from the outside.  You have to help your programmers morph to become developers. 

Once they do, you may have to work very hard to keep them.  When a developer leaves, he or she will either become a manager at a BigCo or a founder of their own company.

How do developers get any code written if they're constantly being interrupted with other stuff?

Yep, that's a problem.  I'll take this opportunity to cite Eric's Axiom of Software Management:

You can't eliminate problems,
but you can make trades 
to get problems that you prefer
over the ones you have now. 

Your developers still need flow time or they will never get any code written.  This problem is far preferable to the set of problems you get when you surround yourself with people that have a narrow "code-only" perspective.  Try to structure your time.  For example, don't try to write code and do tech support on the same day.

So are you saying our developers have to do all that other stuff?

No.  Ideally, your developers still spend most (but not all) of their time writing code.  If your budget allows, there are several categories of specialists that you might want to consider hiring:

"Level 1" technical support

A lot of technical support work involves answering the same questions over and over.  This is probably not the best use of a developer's time.  Keep your developers involved in "level 2" support, diagnosing and solving customer problems which are tough and mysterious.  But it's a good idea to have one or more specialists to catch all the easier stuff.  We usually look for someone with good communication skills and some sort of a background in technology or science.

Manual testing, bugfix verification, etc.

As long as you're building a level 1 support team, overstaff it by just a little.  Give them some slack time so they can be involved in a certain amount of QA work.  Let them do some of the manual testing and bugfix verification work.  This will reduce the load on your developers and will dramatically slow down the burnout rate for people in pure tech support positions.

Documentation

Have your developers write the spec or the first draft of content, but the final creation and editing of your documentation is a job best suited for someone who can spell.

System administration

Your developers probably can do sysadmin work, but there's no particular product-related reason for them to do so.  Hiring a sysadmin person is one way to reduce the distractions on your developers.