Office politics and sh*tty code.

First Prev Next

You have to ask... Marc Clifton21-Jun-16 1:59 Marc Clifton 21-Jun-16 1:59  A few of the common questions: 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)? 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? So, before even touching sh*tty code in an environment rich in stupid office politics, those questions need to be answered and the issues addressed: Managers and developers need to be brought on board with small wins. Develop trust before developing code. That's 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 them or else" style of management. 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. Marc Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Ugly old code john morrison leon21-Jun-16 0:05 john morrison leon 21-Jun-16 0:05  Treat it as you would treat the original materials of a house you are rebuilding. It may be made in an antiquated or odd way but it is work done on which you have to build. Encapsulate it so you don't have to keep looking at it. If it is troublesome then isolate it and only if it is failing in some way should you consider rewriting it.

Last Visit: 31-Dec-99 18:00     Last Update: 24-May-24 9:05 Refresh 1

General    News    Suggestion    Question    Bug    Answer    Joke    Praise    Rant    Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.