Primary + Reviewer — An Alternative IT Plan For Corporations
MOST corporate IT departments seem to follow this philosophy: Hire a fairly large group of developers (four or more), none of them particularly high-talent. Then have them develop in a really big, multi-layered, OO, framework-intensive environment, that utilizes several different languages and technologies. This approach is based on the ideas that:
- Developers should be easily replaceable — we don’t want most of our code written by one high-talent developer, because then he’ll be the only one who understands it, and if he leaves for any reason, or if his code becomes unworkable even by him, we’ll be hosed.
- Big frameworks force developers to create code that can be understood and modified by other developers.
The downside of this approach is that:
- Lots of developers cost lots of money, even if none of them are getting high-talent bucks.
- Lots of developers are slowed down by the needs to frequently communicate with each other, to avoid stepping on each others’ toes while developing, and to figure out other developers’ code.
- Having several developers, none of whom think of their current job as any more permanent than the last few similarly-paying jobs they’ve held in the past several years, results in a “fix it later; maybe never” attitude towards minor bugs, intermittent bugs, and other imperfections. The software winds up with a flaky, half-baked feel — and can become hard to work on despite its frameworks and other code-organization technologies.
- Big frameworks make an application much larger and slower, create more failure points and dependencies, increase development time, and incur much larger licensing fees.
Wouldn’t it be great if there was a way to get the best of both worlds? Wouldn’t it be great to get the speed and skill of a small, high-talent development force, programming to a limited, low-cost set of languages, resulting in a snappy, low-overhead app with a minimum of failure points — while not running the risk of having to start over if your key developer disappears or creates an unworkable mess?
Wouldn’t it be great indeed.
Primary + Reviewer
How about this:
Hire two developers: A primary developer and a reviewer. They never meet each other, and communicate with each other only by sending messages to their manager, who reads them before forwarding them to the other party. Neither of these two developers know how to contact each other independently, and they are told at the time of hiring that they are expressly prohibited from doing so.
The primary developer is high-talent, and has proven his abilities through prior programming projects which he developed from the ground up. (The polish — stability and lack of bugs — of such projects is very important in evaluating a candidate.) The primary developer does all your development work. He is paid very well — somewhere between 50% and 100% more than he would make at the software development job he could get at a typical company. He still costs a lot less than a whole team of developers, but his individually high pay provides him a strong inducement to stay with your company long-term, and to develop your software with the intention of continuing to work on that same code for years to come (i.e. to agressively attack all known bugs and imperfections).
As much as possible, your primary developer should not be required to use any particular frameworks, object systems, languages, technologies, etc., but instead has tremendous leeway to decide what he thinks is best for the company and for his own efficiency as a developer. This is certainly not absolute — for example, if the primary developer thinks that a back-end database is not needed for this particular project, and data should be stored in flat files, but management has plans for how the back-end data eventually will be used in conjunction with other products that require a database, then of course management can override that decision. But this should be done only when there is a specific reason to do so. If, instead, the manager says, “I agree with these things the primary developer wants to use, but not these other things, so I’ll override those other things” — then the primary isn’t really being given any leeway at all; the manager is simply making all technology decisions.
Whatever technologies and languages the primary chooses, his code must be well-commented, sensibly organized, and use rigorously consistent (but developer-chosen) conventions of code formatting and variable naming.
The primary developer must check-in all code changes every night.
Constant Review
The other developer, the reviewer, is paid the salary of a typical developer — not a lot more than he has been making lately — but works subtantially less than forty hours a week, and doesn’t write any code. His job is to continuously review the code written by the primary developer, and (via the aforementioned managed e-mail forwarding system) talk with the primary developer, asking questions such as “what is this statement for,” and “what happens when the user does such-and-such?” That kind of thing.
The reviewer does not just skim the code looking for obvious problems, as one might have to do if asked to review another developer’s work at some typical IT department. No, this reviewer studies all the code very thoroughly, aiming to understand how it works just as well as the primary developer does. That’s his job.
The manager also looks at the code periodically, and reads all communications between the two developers, to make sure that steady progress is being made.
The primary developer may be allowed to work remotely from any location of his choosing, or may have to spend at least part of each week working in the office with the QA and requirements personnel. The reviewer, however, never comes to the office, and is known only to the manager (and that manager’s higher-ups, of course). So, although the reviewer is not paid much more than he could make elsewhere, he still has a very strong incentive to stay with your company, since his current post allows him much more free time, plus the opportunity to work from any place where he can VPN into your network.
The Primary + Reviewer system has the potential to achieve:
- Lower development costs
- Lower technology licensing fees
- Faster, cleaner development
- Snappier and less buggy end-user experience
- Faster turnaround for user requests
- Strong, long-term loyalty from both developers
Contingencies
If the primary developer ever does leave, for whatever reason, the code is well-written, well-commented, and thoroughly understood by the reviewer, who can now step in as the primary developer until a new primary developer is found — or can permanently occupy the primary developer seat (with commensurate pay boost), in which case a new reviewer will be hired.
If a new reviewer has to be hired, for the reason mentioned above, or because the current reviewer just leaves, then the new reviewer will spend two-thirds of his time reviewing the primary developer’s ongoing work, and the other one-third of his time studying pre-existing code.
In the absolute worst case, where both developers leave nearly simultaneously, the code is still well-organized, well-commented, and consistently formatted. Plus the manager has a good feel for it from her periodic examinations — perhaps she could step in as the primary or reviewer for a time.
Will the developers like it?
They’ll love it.
And if your primary developer ever thinks that it might be a little annoying to have to explain things to a reviewer via forwarded e-mail, and to have all his new code reviewed every day, then he’ll just remember how much less he was making at all his previous jobs, how much less real coding he got to do at those jobs, how bad it was to be unemployed inbetween them, etc.
And if your reviewer ever thinks it might be a little annoying to review someone else’s code for a living, he’ll just remember how much less free time he had at his previous jobs, and how bad it was to commute to the same cubicle day after day — and how bad it was to be unemployed between jobs, etc.
They’ll love it; they really will. And so will you.
© 2024 Darel Rex Finley 
design by 