It’s either two hours, two days, two weeks… or too long.
Two things these last two weeks have brought this old saying to mind in full force. First, there is this interesting article about the woes of the Medicaid Management System in Tennessee. Here we have a program that has overrun it’s budget for multiple years, leaving the project owner facing some serious questions. Where did the money go? Why isn’t the system working? What do we do now?
Second, on a more local, and personal, scale, is the building of a new web site for a small school I’m deeply involved in. While the site is large (around 70 pages, around 300 images and growing, 20 or 30 pdf format forms, and a couple of news feeds, as well as the usual connections to social media, etc.), and I normally don’t “do” web design, the lesson was still there, in front of my face.
Why do things take so long to get done in the IT world? Why do projects so often overrun their costs, time, or even outright fail?
The classic answer is that we don’t do a good job of defining our requirements. And I’m going to answer with the same answer — but in a way you might not expect. Let’s return to our little coders ditty: It’s either two hours, two days, two weeks, or too long.
What does this really mean, after all? That coders (and network engineers!) don’t have a long enough attention span to handle larger projects? That coders (and network engineers!) are too lazy to handle the reality of large scale production systems? No. I was reminded of the real meaning in building the web site.
Here is the reality: I can find more than two weeks worth of “stuff that needs to be done,” every two days. Or, as one of my college art professors told me, “perfection is the enemy of the good.” I don’t want to get into philosophy here (even though worldview and theology are two of my favorite topics), but the bottom line is this: we are always going to find places where we’ve made mistakes, and we’re always going to be able to find things that need to be changed. There are always enough grey areas in design for honest people to disagree on the best way to get the job done.
So the key really is requirements gathering. But the point isn’t to pin down every possible requirement, it’s to know when to stop. When you get to the point on the map where it says, “here there be dragons,” leave the work to the future. Stop trying to boil the ocean.
We’ve come to the point in the IT world where we think of systems as infinitely flexible during the design phase, and infinity rigid once they’re put in place. From network architecture to applications, we think that it’s better to address all the requirements up front, that it’s better to build it right, right now, and replace it all in five years, rather than letting the system evolve in place.
We’ve come to the point where we don’t like loose ends.
Contrary to this line of thinking, there is wisdom in the dynamics of real time computation and the (humble little) TLV. There is wisdom in scoping the requirements to the known world, and leaving the dragons off the map for the moment. There is wisdom in building a flexible design, rather than a perfect one.
It’s either two hours, two days, two weeks, or too long.
It’s not about scoping the amount of work, it’s about being realistic about the scope of the requirements.