AKH Online, Inc

Here's how application development contractors can piss off clients and make all geeks look bad:

1. Come to the workplace in workout clothes.

Sure, it's a wicked-cool business with a hip startup environment... where jeans and hoodies are part of the employee dress code. But you're not really an employee, so you might want to demonstrate a little respect for your customer and wear some damn pants - at least until they explicitly tell you that it's OK to dress down a little. Even then, consider a shower and change to some other "casual clothes" if you're hitting the gym before work. Plus... your bare hairy legs are ugly, bro.

2. Take the programming ball and run with it - all the way to a distant planet.

There can often be a communications gap between those who write programs - and those who tell them what programs they want. If you don't take the time to fully understand the business and scope of the project - and embark on a coding crusade without stopping for regular verification; then you could over-produce a solution: providing functionality and features that were not requested or already existed elsewhere. "So, um... you're still gonna pay for all this, right?"

3. Use the lack of complete requirements as justification for... everything.

While it's true that any successful I.T. project is built on a sound foundation of documentation (requirements, personas, use cases, flowcharts, mockups and the über-geeky UML); some projects can germinate as a "proof of concept" - or undergo some urgent tweaks - without them.

Almost the exact opposite of the coder described above - is one who virtually throws back every task to the requestor, because the requirements are undocumented or too vague to be executed with error-free precision. One can almost watch the mental game of "workload ping pong" at play between these contractors and their wranglers.

4. Be very stubborn about the tools you use.

The client has selected product X to manage issues and work assignment for the project. But you've been using product Y for a while. I've sat through meetings and lost valuable lifespan - while you refused to relent, cycling back to another feature product Y has... how product Y is soooo much easier to use... even going so far as to install product Y on your own - and then using both systems at once so you could present comparisons at every turn.

Dude, the client wants to use product X. The client is paying for your time. Learn how to use it and let's move on. You're a developer, not a salesperson.

5. Treat the last developer like an idiot. Oh, and treat users like idiots too.

Guess what: All developers don't use the same coding style you do. Some use established frameworks, some actually remember and follow the design patterns they learned in school. Others will just "cowboy code" if the project is small or lightly used. But you pronounce - after just a day or two of forensics - that the whole thing is wrong and should be done over... using (drum roll): some method that you're more familiar with. Surprise!

This tendency - to cite the prior developer as the cause behind the difficulties in every maintenance call - gets old really fast (especially if the client has fond memories of the prior developer as a person); and often travels with the associated trait of user-bashing.

It's possible to build disdain for those who actually use the apps you write, especially if you're working without adequate UI or QA resources on your team. Your users just don't understand what to do, or they keep breaking things!  Even though the users are frequently skilled workers - some with doctorates and MBA's - your conclusion is that they obviously don't know how it works.

That's wrong: They know remarkably well how their job works, they just need help understanding how your I.T. works. If they knew how to program an application like you do, you'd be out of a job.