The economy brings more bad news every day. The dollar is battered, interest rates are at record lows, salaries are shrinking, and overall unemployment is expected to hit 10 percent by year's end. Times are tough -- for everyone except software developers. It's time we gave credit where it's due.
According to recent studies, development budgets are actually increasing despite the recession, and the market for programming jobs will still grow by 7.4 percent in 2009. The U.S. Department of Labor ranks software engineering as the country's fourth fastest-growing occupation, a trend it expects to continue through 2016.
What gives? Surely in these lean times, in-house development teams are just like everyone else? They must be cutting corners, creating efficiencies, trimming the fat, and doing more with less?
[ Not lucky enough to be a developer? Vent and get support at InfoWorld's Slow IT community area. ]
The sad state of software development
Not so, say the analysts. According to one IDC study, 7 out of 10 companies report that their in-house code bases have grown increasingly complex in the last two years. Often they're so complex that debugging is "problematic," leading to slower development cycles and escalating costs. Meanwhile, a study by the consultancy Voke found that application development is fraught with waste; a third of all projects are abandoned after being implemented, and of those that get deployed, only slightly more than a third meet user requirements.
That's one hell of a résumé. Yet in the midst of a recession, software development has garnered an ever-increasing share of the bottom line, thanks to a bravado mix of poor quality control, inefficient processes, missed deliverables, and broken promises. Doing more with less? Hardly -- we're doing less with more.
So let's take this opportunity to say to all the software project managers out there: Thank you. Thank you for keeping programmers in high demand, even when folks in other fields are losing their jobs. Thank you for ensuring us a never-ending supply of programming work, even when other projects are scaling back.
Dare we list the many ways you've made our jobs recession-proof? How about these, for starters:
Feature creep. Most developers like to work from a well-conceived plan. You know better. Instead, you allow the client to keep piling on new features right up until ship date. That way we end up with unmanageable code spaghetti full of countless bugs, and we spend more time writing patches and doing revisions. If we've negotiated our contracts right, emergency bug fixes could even mean overtime!
Re-inventing the wheel. When we need to implement basic functionality, most of us will start looking for an open source library or framework to fill the bill. You won't let us cut corners like that, though; you've convinced senior management that open source licenses expose the company to liability. Instead, you have us rewrite that code from scratch and on a per-job basis, so this week's rewrite can't be reused on next week's project.
Choosing the wrong tool for the job. The proliferation of development tools is a wonderful thing -- if you're trying to shave off billable hours. Let programmers choose their own tools and they might complete their tasks in half the time you've budgeted. Someone upstairs is sure to notice. Better to pick a personal hobby-horse and stick with it: You want to use Python to process that data? No way, José; we're a C# shop.
Micromanagement. Whenever the team seems to be running too efficiently, that's the time to take our bearings. What better way than with an all-hands meeting? And maybe we can break off into groups after that. Play your cards right and you can take developers off their code for days at a time. A really great manager can even turn the "short meetings" of agile methods into an endless time-sink. We are on the clock, after all.
Discouraging documentation. Who wants to be replaceable in this day and age? If we actually took time to document our code, someone else could maintain it and we'd be out of a job. On the other hand, in the unlikely event of layoffs, there's only one thing to do with our fallen comrades' cryptic, unreadable code: rewrite it from scratch! But what if senior management knew that most modern languages include self-documentation features? It's unthinkable.
Not enough testing. The best bugs are small bugs -- and they're even better when you have a really big haystack to find them in. That's why you don't budget time to design good unit tests, and you mark all problem areas as bugs to be fixed post-delivery. Plus, if there are QA specialists on staff, you'll stonewall them -- developers have enough people criticizing their work without some outside "experts" raining on our parade.
Yes, I've got to hand it to you, software project managers of the world. Thanks in large part to your diligent efforts, developers are working twice as hard for twice as long, and we're all reaping the rewards: bigger development budgets, more programming jobs, and more billable hours.
Maybe you could next work on keeping developers happy while they're on the job? Judging by this list, though, that's probably too much to ask.