Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Sara Chipps is a software programmer specializing in ASP.NET/C#/SQL.
My friend Lisa has a prejudice against those lip glosses that come in a little jar. The kind you dip your finger in and rub on your lips? She calls them little petri dishes, with all the bacteria and germs from your fingers just living in there waiting for their next home.
I see many similarities between lip gloss germ factories and corporate IT. There are good bacteria, and there are bad bacteria, but what they have in common is that they fester.
The good developers fester in frustration, the frustration of change request forms. The frustration of knowing the right thing to do, and not being able to do it until four months later when the “budget is there.”
The bad programmers fester in sloth, in the fact that their work goes largely unnoticed, and as long as their tie matches their shirt we can ignore the fact that their classes go on for days, their code is illegible and their methods bloated. In these environments you’re taught that to care is to waste time. The only thing that’s important is that it GETS DONE, not doing it right. A culture of apathy and wanton disregard for standards is enforced.
The biggest issue here is not the bad programmers, and it’s not the suffocated good programmers. As they say, “A fish rots from the head.” Management decides what the priorities are. If the priority is to “get it done so it works for now and ship it out,” you’ll get exactly what you asked for.
It starts at the top, when the CTO puts pressure on the IT Directors who put pressure on the Department Managers who in turn flip on their coders and turn the screws that bind them. Some symptoms of this are projects that are constantly coming back for work, deadlines that are constantly pushed, and the blame game from QA to the developers to the testers.
Can a large corporation have a healthy team? Yes. I didn’t used to think so, but I’ve kept my eyes and ears open. I haven’t experienced it, but I have met people that have shared their good experiences.
The friends I have in corporate IT who are happy have one thing in common: small teams. When you break up a big group into small teams, and hold the leaders of those teams personally responsible for the health of the team, it succeeds. When you give them the tools they need for success, when you make it about who is contributing the best, when managers take the time to examine who is touching the code — and IF what they are doing is the best solution — that’s when you can succeed.
When you allow for enough time and budget to make sure that things only need to be done once, and changes can be easily made, that’s when you can succeed. A book entitled The Five Dysfunctions of a Team is a great place to start if you are looking to do so. I can imagine it’s hard work, but when you look at companies like Microsoft and Google the reward is obviously worth it.
