My project at work isn’t much fun right now. It has reached that stage where the requirements are getting piled on, and that just gets really annoying. By the time the people who haven’t actually written or debugged code for ten years (if ever) get done, this is what the requirements will look like:
- It must run on systems and networks configured by idiots all over the world, and yet be blazing fast.
- It cannot assume a secure network or VPN (cf. previous requirement regarding idiots), but must thwart all forms of unauthorized data inspection/insertion/modification using internal mechanisms.
- It must be fully integrated in-kernel for every system it runs on, and it must run on several flavors of UNIX plus NT.
- It must include hooks for every other product that anyone at this company ever thought of.
Yeah, fine, and you want than when, exactly? With just two people working on it, one of whom only started yesterday?
The real problem is that this company doesn’t believe in research. Yeah, they make lots of noise about how much they spend on “R&D” but it’s all D. Don’t follow this link because it goes nowhere. The only R that gets done around here gets done skunkworks-style, by people who believe strongly enough in an idea to develop it on their own and then put up with all the political battles and turf wars that occur when people find out about it. Nobody ever says “we need to invent something new in this area, so head in that general direction and don’t worry about how we’ll productize it”. There’s nothing wrong with a good dose of pragmatism, God knows I give academics enough grief for never considering real-world applicability, but there’s also value in being “agile” and demonstrating a capacity to innovate. If every single thing that goes out the door has to have every imaginable bell and whistle, every special hook and supported platform that any political faction asks for, you’ll always be a follower. No matter what product territory you go after, someone else will already be there with an established reputation as a technology leader, attracting talent and making money to pay them to work in that area. You can spread all the FUD you like about compatibility and lack of support and whatever, but you’ll still be a follower.
A while ago, somebody told me about a military metaphor for software development in three stages (let me know if you can identify the original source). The three types of programmers in this model are as follows:
- Paratroopers, marines, rangers, or other troops who enter enemy or unknown territory, travel light, and prepare the way for…
- Plain old infantry (plus artillery, I guess) who constitute the bulk of the force and expand the initial tenuous beach-head or drop zone into a strongpoint from which to launch further operations.
- MPs, who round up the captured enemy and generally maintain order in the rear areas while the first two groups go off and do their thing again somewhere else.
No, I don’t know where navy, air force, coast guard, ordnance, quartermasters, whatever fit into that. Let’s not get carried away with the metaphor, OK? The important thing is that these three military groups correspond in the software world to research, development (of new products), and maintenance (of old products). All three are necessary and valuable, but individual engineers are generally strongest in one particular role. I’m definitely a first-category kind of guy, probably most like Ranger or Force Recon in their exploratory (as opposed to prepatory or covert) roles, in an organization that’s heavy on the second and third categories. I can do those other jobs, but it’s not the most efficient use of skills and resources. First-category folks are the rarest, and should be used to do first-category jobs as much as possible; second- and third-category jobs, which are in no sense less important or require less skill, should be done to the more numerous people who function best in those particular roles.
What I’m really getting at, in my own verbose should-have-been-two-articles way, is that maybe it’s time for me to move on. I’m not into technical trench-digging.