How to Kill a Project

I had one of those days where everything was clicking and going right; my project was nearing the finish line and just in time to make the deadline. I was going to make my deadline, and I was going to be rewarded with the promised raise. My hard work was paying off and my years of experience which told me I could hit the deadline was spot-on, a sign that I am maturing and not stagnating. Then four o'clock rolls around and I get the final piece I've been waiting weeks (months really) for . . . and everything falls apart.

I will not make my deadline, not by a long shot. Information was being withheld, the kind of information that dictates design. Suddenly my clever database schemas are superfluous and over-complicated; the code I wrote to accomplish the goal of the project doesn't quite work, and is overkill. The project's stated goal was ambitious and exciting; it would require a flexible framework to meet the demands, one that would operate on, near, or at the meta level of programming. It called for extreme flexibility, and so I built that, and it is a thing of beauty (despite the obvious need for some refactoring, but for version 1.0 alpha it's amazing). Then the pricing data comes in, the all-important data that turns the other data into money, and instead of finding flexibility I found rigidity.

My deadline is tomorrow and the pricing data won't work. It ignores all the flexibility called for by the project scope and specifications. To their defense we don't have any official documented scope and specifications, something that annoys me and might very well be my fault; however, my company operates with loose structure and with an informality with which project specification documents would go unread (or worse, would only confuse people). I'm not a manager; I don't really know what it takes to manage people, but I imagine waiting until the last minute to get pricing data to the programmer is probably covered in Project Management 101 under the section "10 Things that Kill Projects".

The problem, as far as I can figure it out, is the folks who figured out the pricing could not manage to make their system of calculating prices conform to the flowchart I handed them as to how I planned on generating prices. Under the pressure of a looming deadline they worked furiously whilst ignoring the few design documents I had given to them. In some regards I can blame them, because they did have some indication of my expectations, and instead of alerting me of a design flaw on my part they worked independently and shot me down. This may not be their fault, because they were actually in communication with the project manager.

So can I blame the project manager? Not really, not in this case, because he in fact has only been the project manager for about a week. I've been hard at work on this for a few months, but the boss had other duties to attend to and decided he was in the way of my progress and passed off the project. With only one week to go this new project manager had a lot of catchup to do, and some decisions to make. He did not (and does not) have all the information he needs to make decisions, and is, I believe, operating under a different design than the one already in place.

If this were normal at my company I would just abandon ship, but this is the first time it's happened. Regardless, that does not make it any less aggravating. I take program design very seriously. I like to have all the information up front; I want the full scope of the project laid out; I want to see the big picture. Complex systems require careful thought and considerate structure in order to avoid accidental tight coupling. I cannot build a dependency chart without having all the information.

I sympathize with my fellow programmers and designers who face this on every project. It's a wonder anything gets done.