SQLServerCentral Article

About the Size of Things

,

Big IT projects are the campfire tales of the tech world. Young Silicon Valley entrepreneurs gather around the fire, huddled under blankets, torches under chins. “And then the project manager said… we have to target IE6!” Cue gasps, some laughing, maybe even a few tears, quickly and surreptitiously wiped away. The bigger kids console the most affected. “That could never happen to us. We’d just pivot in a new direction.”

Government IT projects are the apotheosis of this: massive by necessity, often coupled to aging hardware, subject to crippling security and auditing requirements. The troubled launch of healthcare.gov and the NHS move from Oracle to an open-source RIAK system are both high-profile examples of enormous amounts of money and effort being thrown at things that are incredibly hard to manage at the scale at which they are required to operate. Coincidentally, Oracle launched a whitepaper on why governments shouldn’t use open-source software at the exact same time they were dropped by the NHS.

There's a very natural tendency to roll the eyes at the news of projects like this running into difficulty - to say that they're just too big, of course they can't work. What all of this misses, however, is that there's no perfect size for a project. Big projects are certainly more risky financially, but they also get to bring together specialists in a way that a smaller project may not (how many people have made the dev-to-DBA transition because it was a best fit at the time?). Smaller projects give everyone more of a chance to branch out and work in a way they normally wouldn't, but not everyone wants to multitask, and there's less room for true specialism on tiny teams.

No one wants to work on a project that’s mired in inertia, but it’s just as fair to say that the small, exciting, constantly-changing projects with a high risk of failure don’t suit everybody, and certainly not at all points in their career. There are many of us who would rather work on something huge but well-managed, dealing with legacy code and all the attendent joy that brings. Big projects go wrong for the same reasons small ones do - lack of planning, lack of vision, and bad management.

Cheers,

Dave Convery.

Rate

You rated this post out of 5. Change rating

Share

Share

Rate

You rated this post out of 5. Change rating