As a result of poor management, the never-to-be-named company I work for has its own sort of hell. It's a nonprofit research firm that gathers information for studies, and the managers of the firm are not too careful about being efficient -- either in fixing problems or in budgeting money.
On the budget side, the firm uses what can be described as a bucket system to keep track of the money for each project, and the budget per project is strictly apportioned to that task. If there is profit, none of it can be used for, say, general upgrades of the software. The way the managers run things, the budget for general operations is meager, so nothing much gets improved even if there is profit elsewhere from projects.
[ The tech inferno is not buried deep within the earth -- it's just down the hall. Do the nine circles of IT hell sound familiar? | Follow Off the Record on Twitter for tech's war stories, career takes, and off-the-wall news. ]
This leaves our projects with a shared code base, which has some glaring bugs. These bugs show up in every project, and they have to be fixed within each and every project. There's always budget to fix these bugs -- every single time, in every project. But there's no budget to fix them once and be done with it.
The irony is that if once -- just once -- the managers had the programmers apply the same effort they make to fixing the scripts for one to three projects to fixing the base code once, several universal problems would be solved forever, thus saving time, money, and aggravation.
Even worse, to cut costs further, the managers have hired a programming staff that has very little, if any, programming background -- only a couple of people have relevant experience. There also aren't any kind of programming standards, and the lack of oversight means that mistakes creep in way too often, or as is most often the case, mistakes never get corrected.
If the programmers who do have experience try to get something fixed, the management's bureaucracy stops the attempt cold with reams of paperwork and stifling workflow processes.
And problems are numerous. For instance, one branch of the program crashes if the researchers enter one set of information. Another part crashes if too much text is put into a box. The programmers have also left numeric entry boxes lacking precisely defined ranges, which should never happen in a professional environment.
There are even more problems with the logic; as coded, the system takes certain sets of data, but triggers the wrong follow-up questions. The aforementioned lack of range checks is a relatively minor issue, but the programmers' mistakes could result in bad data gathering and, thus, harm the research findings.
So far, we don't see any relief from this poorly managed situation coming our way and instead hunker down to survive as best we can. Maybe one day we'll get managers who are realistic about the problems that are hindering the business and raise us out of this hell. One can always hope, I guess.
Do you have a tech story about working with less-than-stellar coworkers? Send it to firstname.lastname@example.org, and if we publish it, you'll receive a $50 American Express gift cheque.
This story, "Meet the new bugs, same as the old bugs," was originally published at InfoWorld.com. Read more crazy-but-true stories in the anonymous Off the Record blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.