Old Guard Developer

The ones that go red in the face when you start to talk about RubyOnRails or whatever it is that actually makes sense this week. And blue in the face when they find out you mean it. These guys are typically well-connected - they have to be to survive - and unscrupulous about defending the CodeSewer they live in. Cut 'em out of new development and find urgent maintenance work for them if you want to survive.

They're also the ones who keep the enterprise running by creating useful, robust applications using proven technology, while the wet-behind-the-ears NewGuardDevelopers are still discovering all the reasons why the latest fad won't be ready for production until they become OldGuardDevelopers. By that time, the products of the formerly-NewGuardDeveloper's adherence to the latest fad[1] have joined the CodeSewer.

[1] Which is no longer the latest fad, of course -- the new crop of NewGuardDevelopers will have latched onto that.

Of course, technology can be divided into three categories (of importance to this example)

• New-fangled technologies which are not well-proven in production, and which--despite promised rewards--introduce substantial risk to the organization. Until recently, RubyOnRails was new-fangled; now it seems to have established itself.
• Established technologies which are currently in wide use, which have been established, and which have the bugs ironed out. (The established technologies may well have shortcomings which are addressed by the new-fangled; but they are lower risk). Java, VB, etc. are all examples.
• Legacy technologies which were once commonplace, but which are inappropriate for new systems today (having significant shortcomings which the newer-but-established stuff addresses). CobolLanguage is the classic example.

The OldGuardDeveloper mentioned in this page is frequently a defender of legacy technologies (with which they are familiar) against an encroaching mainstream (with which they are not). There are good reasons to avoid the latest and greatest thing being peddled; but there are seldom good reasons to keep developing in Cobol (ignoring the need to interface to an existing deployed system). At least from the business perspective. From the point of view of the OldGuardDeveloper, OTOH, his career may be at stake.

Incidentally, these correspond to the three different markets (EarlyAdopters, Pragmatists, and Laggards) described in CrossingTheChasm.

An OldGuardDeveloper may claim to be HappyWithPerl.