My Photo
Name:
Location: KLANG, Malaysia

Monday, April 10, 2006

Small ISVs: You need Developers, not Programmers (By Eric Sink)

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 successful 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.

0 Comments:

Post a Comment

Subscribe to Post Comments [Atom]

<< Home