• original article rescued from the mists of time

Introduction

There is a realization that comes with the accrual of software development experience across a reasonable number of organizations, and it is this:

Though the names change, the problems remain the same.

Traveling from project to project, from one organization to another, across disparate geographies, domains and technologies, I am repeatedly struck more by the similarities between the projects I work on than their differences. Scenes from one job seem to replay in the next one, only with a different set of actors.

You might finish a gig in which you've seen a project flop due to inadequate consultation with end users, only to find your next project heading down the same path for exactly the same reason. And it generally doesn't matter how much you jump up and down and try and warn your new project team that you've seen the disastrous results of similar actions in the past. They will ignore you, insisting that their situation is somehow different. You will stand back and watch in horror as the whole scenario plays out as you knew it would, all the while unable to do anything more to prevent it. The IT contractor's career can be like some cruel matinee of "Groundhog Day" - without the moral resolution at the end.

But this technological deja vu is not limited to technical scenarios - it extends to people. I find myself working with the same programmers over and over again. Their names and faces change, but their personalities and predilections are immediately recognizable. I find myself playing mental games of "Snap" with my fellow developers. "Bob over there is just like Ian from Acme. James is this workplace's equivalent of Charles from that financial services gig I had last year" - and so on.

Sometimes I fancy that I have met them all. There will be no new developers for me to work with in future - only the reanimated ghosts of projects past. The same quirks and foibles that I've endured in the past will haunt me the rest of my days.

I've listed below the cast of characters that have been following me around for some years now. Coincidentally, there are exactly twenty six of them, one for each letter of the alphabet. Perhaps you've encountered some of them yourself. Perhaps you're one of them. If so - please go away and find someone else to bug.

Arrogant Arthur

The three hardest words in any techie's vocabulary are "I don't know". Arthur never has to struggle with them, for he knows everything. Any technology you might name - he's an expert. Any problem you might have - he's solved it before. No matter what challenge he's assigned - he's sure it will be easy. Whenever Arthur appears to have made a mistake, closer investigation will reveal that the fault in fact lies with someone or something else. Arthur is a pretty handy conversationalist. Whenever you're having a technical discussion with someone and he is within earshot, Arthur will generally join in and quickly dominate the discussion with his displays of erudition. Uncertainty and self-doubt are states of mind that Arthur is entirely unfamiliar with. Arthur has a tendency to make big generalizations and sweeping statements, as if to imply that he has the certainty that only comes from vast experience.

Belligerent Brian

Nobody in the office is particularly fond of Brian. Sure, he's a smart guy and seems to be technically well informed, but he has such a strident and aggressive manner that it's difficult to talk with him for any length of time without feeling that you are under attack. Brian likes it that way and his hostile manner is entirely intentional. You see, Brian is a go-getter. Highly ambitious and energetic, he is determined to advance up the corporate ladder, no matter who he has to step on in the process. Whenever any action is undertaken or decision made, there is always a part of him thinking "How will this make me look to my manager?". It's not surprising then that not all of Brian's decisions are good ones. He has been known to select cutting edge technologies simply for their buzzword compliance, betting that cool acronyms and shiny new methodologies will make him appear progressive and forward-looking. Although he regularly makes mistakes, Brian never admits to any of them, and generally blames third parties, vendors and colleagues for errors that are actually his own.

C++ Colin

Colin is the local language bigot, whose language of preference is C++. He began programming in C, moved on to C++ when commercial forces threw the OO paradigm at him, and has been working in C++ ever since. Colin has watched the ascent of Java with a mixture of disdain and veiled jealousy. Initially, it was easy to defend C++ against criticisms from the Java camp, by pointing to C++'s superior performance. But with the growing speed of JVMs, this advantage has been lost. Now, most of the advantages that Colin claims for C++ are the same language features that Java enthusiasts see as disadvantages. Java developers (or, "Java weenies" as Colin is fond of calling them) point to automatic memory reclamation as an eliminator of a whole category of bugs that C++ developers must still contend with. Colin sees garbage collection as disempowering the programmer, referring to the random intrusion of garbage collection cycles as payback for those to lazy to free memory themselves. Java weenies consider the absence of multiple inheritence in Java an advantage because it avoids any confusion over the rules used to resolve inheritence of conflicting features; Colin sees it as an unforgivable limitation to effective and accurate domain modeling. Java weenies consider C++'s operator overloading to be an archaic syntax shortcut, rife with potential for error; Colin sees it as a concise and natural way to capture operations upon objects. Colin displays a certain bitterness, resulting from the dwindling variety of work available to him within the language domain he is comfortable with.

Distracted Daniel

Daniel's mind is only ever half on the job, or to put it another way, he doesn't have his head in the game. Daniel lives a very full life - indeed, so full that his private life overflows copiously into his professional one. He has several hobbies that he is passionate about, and he is always ready to regale a colleague with tales of his weekend exploits in one of them. It looks as if his job is just a way of funding his many (often expensive) hobbies. His work is strictly a nine to five endeavor, and it would be very rare to find him reading around a particular work-related topic in his own time, or putting in an extraordinary effort to meet a deadline or project milestone. He is constantly taking off at lunch times to take care of one task or another, and does not seem to be particularly productive even when he is in the office. Daniel refers to this as "leading a balanced life". He may be right.

Essential Eric

Eric knows that knowledge is power. Partly by happenstance but mostly by design, Eric has become irreplaceable to his employer. There just seems to be a vast amount of technical and procedural arcana that only Eric knows. If he should ever leave, the company would be in a mess, as he would take so much critical information with him. This gives him a good deal of bargaining power with management, and good job security. A few of the company's managers have recognized the unhealthy dependence that exists upon him, and have attempted to document some of the valuable knowledge about certain pieces of software central to the business, but Eric always finds a way to get out of it. There always seems to be something more pressing for him to do, and if he is forced to put pen to paper, what results tends to be incoherent nonsense. Sit seems that he just can't write things down - or rather, that he chooses to be so poor at it that no one even bothers to ask him to document things any more. Eric is not keen to help others in those domains that he is master of, as he doesn't want to dilute the power of his monopoly.

Feature Creep Frank

Most of the trouble that Frank has got himself into over the years has been heralded by the phrase "Wouldn't if be cool if ... ". No matter how feature-laden his current project may be, Frank can always think of one more bell or whistle to tack onto it that will make it so much cooler. Having decided that a particular feature is critical to user acceptance of the application, it is a very difficult task to stop him adding it in. He has been known to work nights and weekends just to get his favorite feature incorporated into the code base - whether he has got permission to do so or not. Part of Frank's cavalier attitude to these "enhancements" comes from his unwillingness to consider the long term consequences of each addition. He tends to think of the work being over once the feature has been coded, but he fails to consider that this feature must now be tested, debugged and otherwise maintained in all future versions of the product. Once the users have seen it, they may grow accustomed to it, and so removing it from future versions may well be impossible. They may even like the feature so much that they begin requesting extensions and modifications to it, creating further burden on the development team. Frank justifies his actions to others in terms of providing value to users, and often professes a greater knowledge of the user demographic than what he actually possesses, so that he can claim how much the users will need a particular feature. But Frank's real motivations are not really about user satisfaction, but are about satisfying his own ego. Each new feature is an opportunity for him to demonstrate how clever he is, and how in touch with the user community.

Generic George

George delights in the design process. Pathologically incapable of solving just the immediate problem at hand, George always creates the most generic, flexible and adaptable solution possible, paying for the capabilities he thinks he will need in the future with extra complexity now. Sadly, George always seems to anticipate incorrectly. The castles in the air that he continually builds rarely end up with more than a single room occupied. Meanwhile, everyone must cope with the inordinate degree of time and effort that is needlessly invested in managing the complexity of an implementation whose flexibility is never required. It is a usual characteristic of George's work that it takes at least a dozen classes working together to accomplish even trivial functionality. He is generally the first to declare "Let's build a framework" whenever the opportunity presents itself, and the last to want to use the framework thus created.

Hacker Henry

Henry considers himself to be a true hacker - a code poet and geek guru. Still in the early stages of his career, he spends most of his life in front of a keyboard. Even when not at work, he is working on his own projects, participating in online discussion forums and learning about the latest languages and utilities. Software is his principal passion in life. This single-minded pursuit of technical knowledge has made him quite proficient in many areas, and has engendered a certain arrogance that generally manifests as a disdain directed towards those his colleagues whom he regards as not being "true hackers". For his managers, Henry is a bit of a problem. They know that they can really on him to overcome pretty much any technical challenge that might be presented to him, provided that the solution can be reached by doing nothing but coding. For unless it's coding, Henry's not interested. He won't document anything; certainly not his code, because he feels that good code is self-documenting. He is early enough into his career to have not yet been presented with the task of adopting a large code base from someone who subscribes to that same belief, and to have thereby seen the problems with it. Also, Henry can generally only be given "mind-size" tasks to do. His tasks have to be small and well defined enough for him to fit all their details in his head at once, as he simply refuses to write anything down. The architecture of enterprise-scale systems will likely forever be a mystery to him as he does not possess, and has no interest in developing, the facility with abstractions and modeling that is necessary to manage the design of large systems.

Incompetent Ian

Ian is a nice enough guy but is genuinely incapable of performing most of the job functions his position requires. It's not clear whether this is a result of inadequate education, limited experience or simply a lack of native ability. Either way, it is clear to anyone who works with Ian for any length of time that he is not really on the ball, and takes a very long time to complete even basic tasks. Worst of all, Ian seems to be blissfully unaware of his own incompetence. This can make for some embarrassing situations for everyone, as Ian's attempts to weigh in on technical discussions leave him looking naive and ignorant - which he also fails to notice. Ian tends to get work based upon his personable manner and the large number of friends he has working in the industry. Most of his employers have come to view him as a "retrospective hiring error".

Jailbird John

John has been working for his current employer a long time. A very long time. Longer than most of the senior management in fact. John has been working here so long that it is highly unlikely he will ever be able to work anywhere else. Over the years, his skill set has deteriorated so greatly and become so stale that he has become an entirely unmarketable commodity. He knows all there is to know about the company's legacy applications - after all, he wrote most of them. He has been keeping himself employed for the last decade just patching them up and making one piecemeal addition after another in order to try and keep them abreast of the business's changing function. Tired of chasing the latest and greatest technologies, he has not bothered learning new ones, sticking to the comfortable territory defined by the small stable of dodgy applications he has been shepherding for some years. John gets along with everyone, particularly those more senior to him. He can't afford the possibility of getting into conflict with anyone who might influence his employment status, as he knows that this will likely be the last good job he ever has. So he tries to stay under the radar, hoping that the progressive re-engineering of his pet applications with more modern technologies takes long enough for him to make it over the finish line.

Kludgy Kevin

Kevin is remarkably quick to fix bugs. It seems that he's no sooner started on a bug fix than he's checking in the solution. And then, as if by magic, the very same bug reappears. "I thought I fixed that", declares Kevin - and indeed he did - but not properly. In his rush to move on to something else, Kevin invariably forgets to check that his "fix" works correctly under some boundary condition or special case, and ends up having to go back and fix it again. Sometimes a third or even fourth attempt will be necessary. This is Kevin's version of "iterative development."

Loudmouth Lincoln

Terror of the cubicle farm, Lincoln incurs the ire of all those who sit anywhere near him, but remains blissfully unaware that he is so unpopular. His voice is louder than anyone else's by a least a factor of two, and he seems unable to converse at any volume other than full volume. When Lincoln is talking, everyone else is listening, whether they want to or not. People in his part of the office know a great deal more about Lincoln's personal life than they would like, as they have heard one end of the half dozen or so telephone calls that he seems to receive from his wife every day. Lincoln's favorite instrument of torture is the speakerphone. He always listens to his voicemail on speakerphone each morning, so that he can unpack his briefcase while doing so. He also likes to place calls on speakerphone so that his hands are free to type at his keyboard while conversing with someone else. He either doesn't realize or doesn't care that he is disturbing those nearby. Nobody seems to be game enough to tell him how inconsiderate he is being.

Martyr Morris

Morris is very conscious of the impression others form of him. Probably a little too concerned. He has observed that many of his colleagues associate long hours with hard work and dedication. The longer the hours, the harder you're working - and having a reputation as a hard worker can only be a good thing when it comes performance review time. So Morris makes sure he is at the office when his boss arrives of a morning, and that he is still working away when his boss leaves of an afternoon. Everyone agrees that Morris certainly puts in the hard yards, but are a little perplexed as to why his code is so often buggy and poorly structured. In fact, it seems like Morris has to put in extended hours in order to compensate for the poor quality of his work. The net result is that he gets almost as much achieved as his team mates who work more sensible hours. Morris hasn't yet twigged to the fact that his defect injection rate rises dramatically as he fatigues, meaning that the extra hours he works often have a negative effect on his productivity. Worse yet, his know-nothing manager rewards him for his dedication, thereby reinforcing the faulty behavior.

Not-Invented-Here Nick

Nick has a near pathological drive to write everything himself. Due to hubris and ambition, he is rarely satisfied with buying a third party utility or library to help in his development efforts. It seems to him that the rest of the industry must be incompetent, for every time he looks to buy rather than build, he finds so many shortcomings in the products on offer that he invariably concludes that there's nothing for it but to write the whole thing himself. It also seems that his particular requirements are always so unique that no generally available tool has just the functionality that he needs. Not wanting to work inefficiently, he insists on only using tools that do exactly what he wants - nothing more, nothing less. Little wonder then that he finds himself having to write such fundamental utilities as text editors, file transfer programs, string and math utility libraries. The real problem is not that Nick's requirements are so unique, but that he deliberately fabricates requirements so specific that he can find commercial offerings lacking, and thereby justify reinvention of those offerings himself. In short, he is looking for excuses to write what he considers to be the "fun stuff" - the development tools - rather than the "boring stuff" - the application code. He generally has little difficulty in finding such justifications. Most people who work with Nick note with interest that the tools that he writes himself are rarely of the quality of the equivalent commercial offerings.

Open Source Oliver

Oliver is very enthusiastic about open source software development. He contributes to several open source projects himself, and tries to incorporate open source products into his projects wherever possible - and it's always possible; mainly because Oliver begins a project for the principal purpose of providing himself with an opportunity to try out the latest and greatest CVS build from Apache, Jakarta or wherever. Oliver rarely has to justify his technology selections to his colleagues, as he is always sure to surround himself with other open source believers. On occasions when he needs to explain the failure or buggy nature of some open source package, he relies upon the old saw "we can always fix it ourselves". However there never seems to be enough time in the schedule for this to actually occur; so every release of his project bristles with the underlying warts of its open source components. If all else fails, it can at least be said that the price is right.

Process Peter

If you want to see Peter get worked up, just start a discussion with him about the poor state of software development today. He will hold forth at length, and with passion, on where it has all go wrong. And Peter has decided that all of software's woes have a common genesis - a lack of disciplined process. Peter's career history reads like a marketing brochure of process trends. BPR, Clean Room, Six Sigma, ISO - he's been a whole-hearted enthusiast of them all at one time or another. His dedication to strict process adherence as a panacea to a project's quality ills is absolute, and he will do almost anything to ensure that ticks appear in the relevant boxes. Unfortunately, this uncompromising approach is often self-defeating, as it denies him the flexibility to adapt quality levels on a case-by-case basis. It has also made him more than a few enemies over the years. He is prone to considering the people component of software development as a largely secondary consideration, and views programmers a little like assembly line production workers - interchangeable parts whose individual talents and proclivities are not so important as the procedures they follow to do their work. Those subject to such views tend to find it more than a little dehumanizing and impersonal.

Quiet Quincy

Quincy is one of those guys who has no need to brag about his technical skills or the depth of his technical knowledge. He's not much interested in being "alpha geek" at the office, he just wants to do a good job and then go home to his wife and children. Quietly spoken and unassuming, he looks on with amusement at Zealous Zack's ever-changing enthusiasms and shakes his head, knowing that in a few more years Zack will have gained enough experience to know that the computing industry is full of "next big things" that generally aren't. Given a task, he just sits down and does it. He doesn't succumb to heroic bug-fixing and late night coding efforts - his code is good enough to begin with that there are rarely any problems with it. He probably won't get many pats on the back from management, whose attention will largely be captured by the technical prima donnas that swan around the project space, dropping buzzwords and acronyms like they were the names of celebrities they knew personally. But without Quincy and those of his ilk, the project would fail - because someone has to get the work done.

Rank Rodger

Rodger is very good at what he does. He's a techie through and through, and delights in problem solving. The problem is that Rodger lives in his head. At times he feels like a brain on legs, so focused is he upon intellectual pursuits. His body is a much neglected container for cortical function that he generally pays little attention to, except to meet its basic functional requirements for food and clothing. As a result, there is a certain funk surrounding Rodger which nearby colleagues are all too aware of, but of which Rodger is olfactorily ignorant. Halitosis is his constant companion and dandruff a regular visitor. In general, he has unkempt appearance - his shirt often buttoned incorrectly, hair not combed and tie (which he wears only under the greatest duress) knotted irregularly. Rodger doesn't really care what others think of him and is largely unaware of the message his poor grooming and hygiene is sending to others. Rodger is likely to remain unaware for a long time, as nobody can think of a way of broaching the topic with him that wouldn't cause offense.

Skill Set Sam

Sam is just passing through. If he is a contractor, everyone will already be aware of this. If he is permanent staff, his colleagues might be a little surprised to know just how certain he is that he won't be working here in a year's time. Sam is committed to accumulating as much experience with as many technologies as he possibly can, in order to make himself more attractive to future employers. His career objective is simply that he remain continually employed, earning progressively higher salaries until he is ready to retire.

Toolsmith Trevor

Trevor loves to build development tools. He can whip you up a build script in a few minutes and automate just about any development task you might mention. In fact, Trevor can't be stopped from doing these things. He is actively looking for things to automate - whether they need it or not. For some reason, Trevor doesn't see the writing of development tools as a means to an end, but an end in itself. The living embodiment of the "Do It Yourself" ethic, Trev insists on writing common development tools himself, even if an off-the-shelf solution is readily available. Rather than chose one of the million commercially available bug tracking applications, you can rely on Trevor to come up with an argument as to why none of them are adequate for your purposes, and there is no solution but for him to write one. At the very least, he will have to take an open source tool and customize it extensively. So too with version management, document templates and editor configuration files. Trevor is right into metawork, with the emphasis on the meta.

Unintelligible Uri

English is not Uri's native tongue. This is blatantly obvious to anyone who attempts to communicate with him. He speaks with a thick accent and at such a rapid pace that listeners can go several minutes in conversation with him without having a clear idea of what he has said. Trying to work with Uri can be an excruciating experience. He cannot contribute to technical discussions effectively, regardless of how well informed he might be, because he is always shouted down by those with more rhetorical flair, regardless how uninformed they might be. Delegating work to him is a dangerous undertaking because you can never be certain that he has really understood the description of his assignment, as he tends to respond with affirmative cliches that can be easily said, but don't necessarily reflect that information has been successfully communicated. Very often, people choose simply not to bother communicating with Uri, because they find it both exhausting and frustrating. Whoever hired Uri has failed to appreciate that fluency in a natural language is worth ten times as much as fluency in a programming language.

VB Victor

Sometime in the nineties Victor underwent what is colloquially referred to as a "Visual Basic Lobotomy". He found himself a programmer on a misconceived and overly ambitious VB project, and fought to write a serious enterprise application for some years in a language that was never conceived for more than small scale usage. Visual Basic Land is a warm and soothing place, and Victor let his skill set atrophy while he slaved away at VB, until eventually VB was all he was good for. Now, dispirited and deskilled, he is a testament to the hazards of building your career upon a narrow technological basis. Victor will likely survive a few more years, pottering from one VB project to the next, until he loses the enthusiasm even for that.

Word Salad Warren

Unlike Uri, Warren's native tongue is English; but it does him little good. Listening to Warren explain something technical is like listening to Dr Seuss - all the words make sense when taken individually, but assembled together they seem to be mostly gibberish with no coherent message. Such is Warren's talent for obfuscation, he can take simple concepts and make them sound complex; take complex topics and make them sound entirely incomprehensible. This is big problem for everyone attempting to collaborate with Warren, for they generally find it impossible to understand the approach Warren is taking to solving his part of the problem, which virtually guarantees it won't work properly in conjunction with other's work. On those rare occasions when he tries to document his code, the comments aren't useful, as they make no more sense than Warren would if he were explaining the code verbally. Management has made the mistake of assuming that Warren's diatribes are inscrutable because he is so technically advanced and is describing something that is inherently complex. That's why he is in a senior technical position. But his pathetic communication skills are a major impediment to the duties he must perform as a senior developer, which routinely involve directing and coordinating the technical work of others by giving instructions and feedback. Warren is a source of great frustration to his colleagues, who would give anything for precise and concise communication.

X-Files Xavier

Xavier takes a little getting used to. Although his programming skills are decidedly mature, his personality seems to be lagging behind. He has an unhealthy fascination with Star Trek, Dr Who and Babylon 5. Graphic novels and Dungeons & Dragons rule books are littered about his cubicle, and he can often be found reading them during his lunch break, which he always spends in front of his computer, surfing various science fiction fan sites and overseas toy stores. Project meetings involving Xavier are generally ... interesting, but somewhat tiring. He regularly interjects quotations from Star Wars movies and episodes of Red Dwarf, laughing in an irritating way at his own humor, oblivious to the fact that others without his rich fantasy life are not amused by his obscure pop culture references. Xavier seems to spend most of his time by himself. No one has ever heard him mention a girl-friend. Those who have worked with him for any length of time know that he is best kept away from customers and other "normal people" who would not understand his eccentricities.

Young Yasmin

Yasmin has only been out of University for a few years. She is constantly surprised by the discrepancy between what she was taught in lectures and what actually appears to happen in industry. In fact, there seems to be a good deal that happens in practice that was not anticipated at all by her tertiary education. She concludes that the numerous shortcuts, reactive management and run-away bug count of her projects are just localized eccentricities, rather than a widespread phenomenon. Yasmin fits well into the startup company environment, with its prevailing attitude of "total dedication." Indeed, she is the target employee demographic of such firms. She is at that stage of life where she has the stamina to work 60 and 70 hour weeks on a regular basis. She is not distracted by family commitments, and is ambitious and eager enough to still be willing to do what is necessary to impress others. Lacking industry experience and the perspective that comes with maturity, she is not assertive enough to stand up to management when they make excessive demands of her.

Zealous Zack

Zack is a very enthusiastic guy. In fact, there seems to be very little going on in the world of computing that Zack is not enthusiastic about. Like a kid staring in the candy store window, Zack gazes longingly at every new buzzword, acronym and advertising campaign that crosses his path, immediately becoming a disciple of every new movement and technology craze that comes along. Sometimes these enthusiasms bring with them certain ideological conflicts, but Zack is too busy downloading the Beta version of the next big thing to be worried about such matters. He runs Linux on his home PC, has a Mac Mini in his living room, and worships at the church of Agile. Having Zack on your project can be challenging, particularly if he exercises any control over technology selection. He will invariably try and load down your project with whatever "cool" technologies he is presently over-enthused about, and delight in the interoperability problems that result as an opportunity to introduce even more technologies to save the day. Zack never quite learnt to distinguish work from play.