Out of Bounds : Avoiding Career Protection Faults

#define KNOW_IT_ALL_DEVELOPER 64 
#define TEAM_VIEW_OF_THE_NEW_GUY 8 
#define UNWANTED_INPUT 1

int team_integration[TEAM_VIEW_OF_THE_NEW_GUY]; 
team_integration[KNOW_IT_ALL_DEVELOPER] = UNWANTED_INPUT;

The following is an email I could have gotten recently.

Hi there. First time caller, long time listener. You're the greatest, and your words are like gold!

I recently took a new software development job, and I've been experiencing a lot of ill will from coworkers and peers. It's really been killing my job satisfaction.

To explain, I was recently brought in to help a software team get a product out the door, with a mandate of helping with some web app code. I've been trying my best to integrate with the team, trying to earn some credibility and respect by making myself useful.

I've been forwarding various Joel On Software essays to All, recommending that the office stock up on Code Complete, Peopleware, and the Mythical Man Month, and I make an effort to point out everything I believe could be done better. I regularly browse through the source repository to find ways that other members could be working better.

When other developers ask for my help, I try to maximize my input by broadening my assistance to cover the way they're developing, how they could improve their typing form, what naming standard they use, to advocate a better code editing tool, and to give my educated final word regarding the whole stored procedure/dynamic SQL debate.

Despite all of this, I keep facing resistance, and I don't think the team likes me very much. Many of my suggestions aren't adopted, and several people have replied with what I suspect is thinly veiled sarcasm.

What's going wrong?

Are these developers just afraid of change? Are they so stuck in their ways? Do they simply LIKE doing things the wrong way?

Yours truly,
The New Guy

Thanks for writing New Guy. It's a thrill when I can manufacture a cheap strawman to make a point, so I welcome the opportunity to address this scenario.

Let's get to why you're experiencing what you're experiencing.

The Politics of Software Development Teams

Many development shops operate as a zero sum game: there are a fixed number of promotions, raises, and apple-of-the-boss'-eye positions that everyone is competing for, and thus one developer's gain is at the cost of the rest of the group.

Given this sad reality, when a new recruit joins the team, there may be resistance, particularly among less confident groups and team members, and attempts could be made to limit the recruit's influence by deriding their ideas, limiting their input, and marginalizing their contributions.

The longer the existing team has been in place, and the less confident they are about their positions and their skill, the worse this problem usually is.

Of course, their fears may be well-founded. Many new hires are motivated to push silver-bullet methodologies, to lazily advocate quick-fix online essays, and to make superficial commentary about how to improve the code and the products, is the desire to earn themselves enhanced credibility with the overseers, and thus the opportunity to fast-track past the existing team members.

The Ugly History of Most Projects

About a decade back, I was tasked with building an aggregation system to pull together data from facilities across the continent, and to perform some rudimentary filtering upon it. The eventual result of this effort was a rather ugly creation that I was both proud of and ashamed of at the same time.

This system originally grew out of some Excel macros, growing into an Access solution with some simple automation, and then to a SQL Server database with on-demand manual data extractions, and finally to a DHTML web application reporting framework against a data warehouse. Through that evolution it incorporated a mish-mash of technology advances, methodology changes, and of course changes based upon my own knowledge increasing. 

Many of the project steps weren't actually authorized -- I built the original application because I was lazy, and wanted to automate some manual tasks I had been assigned -- and the project was always viewed by management as a short-term hack until another of the organization's products could render it irrelevant, so rewrites and major refactoring were out of the question. Requirements and user input was incredibly sparse, and most of the project was developer initiated, with the users choosing what color to paint the shed after the fact.

Remarkably that ugly hack job continues to process data today.

Yet having that product history under my belt made the position close to untenable: With each new developer I got to hear how the data should have been structured, whether more normalized or less normalized; how it should have incorporated as yet uninvented technologies like XML; how it doesn't conform with coding standards imposed years later; how it was theoretically rendered redundant by hypothetical solutions released far later; and how the hack-job code, one of my first projects created in Delphi and Object Pascal, was less than ideal; and so on. Many of these criticisms were made as widely and as loudly as possible, in standard To: All fashion.

Yet, despite all of its real-world warts and appendages, it was a critical part of the enterprise. Despite all of the bold talk about its shortcomings, no one could more than superficially improve it or deliver any real alternative.

And that's the reality that new recruits walk into -- products created in less than ideal conditions, with limited requirements and limited sponsor backing, under absurd time constraints, by developers not entirely adept at the technologies, and with limited or non-existing supporting technologies (ADO, for instance, didn't even exist yet). Developers who live through such a history are often resistant to brash or unrealistic commentary.

Of course, this doesn't mean that the project deserves no constructive criticisms. Indeed, I would be the first to say that lessons should have been learned from its implementation and failings, and a much better replacement built using all current generation technologies. I was always open to discussion regarding some of the choices made, and to explain its less than ideal architecture.

Yet I grew an instant dislike to anyone who haughtily pronounced its shortcomings.

This is the sort of reality that many new developers walk into, with ugly-offspring projects that are nonetheless loved. The legacy developers know its faults, and while they work to improve those that they can, they accept others as necessary compromises (often compromises of time -- it may be ugly, but it's worked for years so it's not the best place to spend critical time changing). They are naturally defensive of their legacy, while more pragmatic than a fresh "everything should leverage all of the advantages of .NET 2.0" recruit.

Real World Requirements

In the real world you probably don't need GUIDs for your employees table primary key. In the real world you can use basic authentication and extremely heavyweight reporting solutions (such as Excel automation) on a high value, single customer web server. In the real world client-server architectures can often suffice, and less-efficient code is often satisfactory. In the real world you can often get away with unilingual applications.

Of course in the artificial one-sized-fits-all ecommerce world, all of these are sins. In the artificial world every solution has to be database vendor netural, platform neutral, infinitely vertically and horizontally scalable, immediately multilingual, using n-tier connection pooling via a hierarchy of web services.

The conflict between the real world and the artificial one-sized-fits-all world is a frequent point of contention between new hires and existing teams. One organization's Enterprise solution is another organization's short sighted mistake.

Practical Knowledge

To draw from personal experience again, I farmed some code off to a new recruit once, asking them to build some extensions. Some time later they returned to tell me that the code I sent was clearly flawed, and that it couldn't possibly work due to some perceived flaws. I assured them that the code worked, and they were off again. Once again they returned to tell me that I was wrong. I imagined myself a bumblebee with a distraught aerodynamics scientist informing me that it was impossible that I could fly.

The code I sent them was straight from the production branch, and had been operating robustly for over a year. I quickly demonstrated that they were wrong.

This is a fairly typical scenario, where new recruits place too much confidence in their own knowledge and skills, despite what is often a domain knowledge deficiency, while simultaneously placing too little confidence in the team they are joining.

More often than not that quirky piece of code has a reason, and that seemingly less-than-optimal solution probably has a very good explanation.

Putting It Together - How To Fit In

• Always first presume that you're wrong. While developers do make mistakes, and as a new hire you should certainly assist others in catching and correcting mistakes, you should try to ensure that you're certain of your observation before proudly declaring your find. It is enormously damaging to your credibility when you cry wolf.
  
  
• Be discreet with constructive criticism. A developer is much more likely to be accept casual suggestions and quiet leading questions than they are if the same is emailed to All. Widening the audience is more likely to yield defensiveness and counterstrikes.
  
  The team is always considering what your motives are, and you will be called on it and exiled if you degrade the work of others for self-promotion.
  
  
• The best way to earn credibility and respect, and an elevated position in the pecking order, is through hard work and real results. Cheap, superficial substitutes -- like best practice emails sent to all, or superficial comments about how great it would be to implement some silver bullet -- won't yield the same effect, and are more easily neutralized.
  
  
• Actions speak louder than words. Simply talking about implementing a team blog, or a wiki, or a new source control mechanism, or a new technology, is cheap. Everyone knows that you're just trying to claim ownership of the idea when someone eventually actually does the hard work of doing it, and they'll detest you for it.
  
  If you want to propose something, put some elbow grease behind it. For instance, demonstrate the foundations of a team blog, including preliminary usage guidelines, and a demonstration of all of the supporting technologies. This doesn't guarantee that the initiative will fly, and the effort might be for naught, but the team will identify that it's actual motiviation and effort behind it, rather than an attempt at some easy points.
  
  
• Not every application is a high-volume e-commerce site. Just because that's the most common best-practices subject doesn't mean that it's even remotely the best design philosophies for the group you're joining.

Conclusion

Despite all of the selfish and illogical traits described above, many teams are staffed with confident developers who are ready and willing to accept new hires into the fold, and who welcome and respond to criticism and doubt fairly and respectfully. Similarly, many new hires are selflessly trying to contribute their knowledge, and their contributions often are founded on nothing but good intentions. When they are jockeying for position, it's often to earn the respect and trust of their peers rather than to impress the boss.

Having said that, the development community is (at least thus far...unless the robots take over) full of humans, and humans are imperfect. Often we try to boost our own relative position by pushing down others, and we stake out domains that we defend against all logic. By nature most humans are prone to resisting change. New hires need to keep these realities in mind, not only to identify and minimize their own weaknesses, but also to identify the same in others and to adapt to the greatest extent possible, working to integrate without become life-long foes of their coworkers.