Back in the late 90’s I was the primary, and often the only, developer of a fairly large project that I had the pleasure of being associated with from beginning to end. The software was the core product of a commercial credit bureau, and that product was desperately needed by grateful paying customers. In addition, no one else had ever done it before, and perhaps more gratifying, some have tried — and failed — since. The owners of that startup successfully cashed out, and I have that warm, fuzzy feeling deep down of having worked hard to produce something I’m very proud of.
Alas, such projects are extremely rare.
I’ve known developers who go through entire careers without having anything resembling the above experience. I was fortunate to be in the right place at the right time, and I know it.
Most projects, by contrast, suck in one or more significant ways.
A surprising number of them are actually, in some way, doomed.
In the “alternate reality field” that surrounds many businesses, software development projects are more often then not, created for the wrong reasons, to solve the wrong problems, in the wrong way. It’s one of the dirty little secrets that not only are most projects over budget, late, and wrong … but quite frankly, off target in the first place. You don’t read much about this problem for some reason. But I have a notion that a lot of those screwed up projects would manage to “gel” and produce something grand if everyone involved knew in their deepest soul that what they were doing was actually meaningful. Think about the projects you have the fondest memories of. I’ll bet not many of them were exercises in futility.
And so I come to the point of this essay: what do you do when you find yourself (as you inevitably and often will) in the midst of The Project That Will Never See the Light of Day, or The Project that Solves the Wrong Problem, or one of the other horrors of project management?
Well, there are some prerequisites:
- Never, ever give a client bad advice. It’s true that their eyes will often glaze over and they will not follow your good advice. But, that is their choice. Never tell them what they want to hear. You can learn to do this without being needlessly confrontive. Sometimes both you and the client know their request for your input is only pro-forma; they’ve already made up their minds and don’t really want to be confused with facts. Go along with it … but make sure that no one can tell you, down the road, you didn’t tell them a better course. You’re a consultant, after all. Give good counsel. It’s the only way to build respect. Shoot straight!
- Never accept abusive or exploitive situations, such as death march environments, a constant crisis atmosphere, lousy working conditions, insufficient tools, broken payment promises, etc.
- Always confirm all agreements in writing. In practice this doesn’t generally need to be a contract, just a series of emails along the lines of “To confirm our conversation today about Project X …” You’ll be astounded at how seeing what they’ve just told you to do, in writing, and having it documented as their idea, can suddenly turn around an insane idea and bring it down to earth. But, if it doesn’t — you don’t hang for it later.
Assuming the above … you have a paying gig, a forewarned client, reasonable working conditions, and clearly agreed-to responsibilities. Now maybe the misbegotten project will not serve the client or employer; maybe it will ill serve them. But, you have a learning experience before you — a chance to make the architecture, the implementation, the realization the best it can possibly be. If it turns out that you created a pencil sharpener where a screwdriver was what was needed — so long as that’s what the client insisted on, despite your counsel — just make sure it’s a damn good pencil sharpener. A job well done is its own reward.
The sad fact of our craft is that most of our best work will be largely invisible to the world, even when the finsihed product is widely and successfully used. Most often no one will know how you jumped through rings of fire and ate little pieces of glass so that the transaction layer works correctly every time, and is fault-tolerant. But you know … and for most of us, most of the time, that has to be enough. If it’s not, you’re in the wrong line of work.
