Java application deployment

Software project managers must handle difficult application developers

By Deepika Ganeshan

TheServerSide.com

Application developers, in layman’s terms, are folks who can take business requirements and translate them into a working product using specific programming languages or by applying minor tweaks to packaged software. Project managers are the folks who make sure those software developers stay on track and deliver high quality applications on a timely schedule. Project managers tend to work with a variety of applications developers and have to deal with multiple personality types.

In my experience with working with a multitude of software developers I have found them to fall into one of the following categories:

  1. The developer who has a holier-than-thou attitude
  2. The developer who really shouldn’t be a developer
  3. The RockStar

Holier-than-thou

The developer who falls into this category can be identified by their:

  1. Rather overly presumptuous belief that they are God’s gift to the technical world
  2. Overwhelming conviction that they know the requirements best, they know the clients best, they know the solution best, they know the technology best… well, you get the drift
  3. Thinking that business requirements are an unfortunate thorn in their path to attaining technical nirvana

The developer who really shouldn’t be a developer

Lack luster programming skills, convoluted logic in their code, and inability to produce a “Hello World” statement – makes these developers stand far out from their brethren. Sometimes, though not always, these folks may have attained their credentials via fly-by-night technical schools or in some cases may even be self taught. In an unfortunate failure of the recruiting process, these folks slip through the cracks and end up on a project that you may be involved with. (Shoring up the recruiting process – now, that’s the subject for another article altogether)

The Rockstar

These folks, ironically enough, may be tougher to identify than the two categories of developers highlighted above. These are the kind of developers who have a true passion for what they do, get under the skin of the requirements and the business process, question the logic of requirements, and keep usability at the forefront of every solution that they develop.

I have been fortunate enough that I have had more than my fair share of “Rockstar” developers – which is not to say I have not had my run-ins with the first two categories.

Dealing with dubious developers

So – how do you deal with the first two categories of developers – short of pulling your hair out? The answer is simple – Nip it in the bud.

How do you deal with difficult developers? 
Nip it in the bud.

 

Whether you are dealing with a "holier-than-thou developer" or a "developer who really shouldn’t be a developer" – it is infinitely less painful in the long run to sit the developers in question down and address the root of the problem.

A lack of technical skills can sometimes be overcome by training – provided your project timelines and budget allow for it. It’s more difficult to find a satisfactory solution to the developer who exhibits the holier-than-thou attitude.

The solution is akin to removing a band-aid. Deal with the termination or transition of the developer's responsibilities swiftly – even if it will mean a short term hit to your project.

Rockstars

Finally, let’s not forget the rockstar. They need to be encouraged to take on more responsibilities, acknowledged for their contribution to the project, and in general made to feel like their input counts.

To all my rockstar developers – Thank you!

02 Aug 2011

Related Resources

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.