Office Politics and Sh*tty Code

office politics.jpg

Kent Sharkey on Code Project recently asked this question:

I’m just curious to know how everyone else here deals with poorly written code in pre-existing projects.

Here’s my answer:

A few of the common questions about the code:

  • Is it bug riddled?
  • Is it hard (or impossible) to add new functionality?
  • Does it run only on/with obsolete or soon to be obsoleted technologies?
  • Does it have performance problems, and are those performance problems intrinsic to the architecture (or lack thereof)?
  • Is there a complete lack of unit and integration testing?  Would the code simply benefit by developing a test suite?
  • Is deployment a PITA?
  • Is the project set up correctly?  Does it have development, test, stage, and production deployment environments?
  • Are the tools being used for development archaic?

Regarding office politics:

  • Is the original coder/team still around?
  • Is there an adversarial situation between the coders and the users?
  • Does management b*tch about the problem but refuse to allocate the funds to fix it?
  • Has management become jaded with in-house development and thinks outsourcing / third party COTS, or bringing in a consulting team (at 10x the cost of in-house development) will fix the problem?
  • Does management think patching the code rather than rewriting it will fix the problem?
  • Does management even trust its developers?
  • Do the developers trust their managers?
  • Do the customers (in house or otherwise) trust the coders?
  • Do the customers trust the company / managers?

So, before even touching sh*tty code in an environment rich in office politics, those questions need to be answered and the issues addressed:

  • Managers, developers and customers need to be brought on board with small wins.  This doesn’t necessarily mean fixes in the code.  It also, and much more importantly, means communication, particularly, feeling heard.  And that means not just listening to the complaints, but coming back with a prioritized plan to address those complaints.
  • Develop trust before developing code. That’s a cute slogan, but think about how you communicate a project plan, even a small one, and how you present measuring success, how you communicate progress and obstacles, so the coders, managers, and customers (in house or otherwise) all, and I mean all, feel confidence moving forward.
  • Everyone needs to see themselves as a stake holder. Particularly, that means management needs to be interested, involved, and engaged in the fixing process. No “disconnected” management, the typical “do this by then or else” style of management.  Customers need to be engaged too with testing fixes and providing feedback.
  • Fix the blame game so that people are oriented toward solutions.
  • Get 100% agreement (even if everyone starts at “this all sucks”) and move rapidly towards 100 % agreement on “this is how we make it great.”
  • Instead of daily stand ups of “what did I do, what am I working on, what are my obstacles”, focus instead on “how’s my enthusiasm level, how well am I working with others, how well are others working with me.”
  • Lastly, be honest, and if you think someone isn’t being honest, call them on it. If trust and honesty doesn’t rapidly become the new culture, then accept it and move on to another job where the climate is healthier.

Those are all things I’ve encountered and is the boilerplate list of questions and “moving forward” approach that I take.

Advertisements