Does this scenario sound all too familiar? As programmers, many of us occasionally suffer from a “god complex,” leading us to believe we can resurrect a project, bringing it back like the mythical Phoenix from the ashes, or lay our hands on a project gone bad and save it from ultimate failure. Some of us might be able to do these things routinely and be handsomely rewarded for it. But the long-term result can prove less than miraculous: a continued mismanagement of the software development life cycle, perpetuating the habits that produce miserable programmers and poor software.
We work in a trade like no other in history. We work in the ethereal. Our creations have no manifestation in the physical realm. The medium we toil with is without parallel. We are artists, perhaps some of the most talented artists ever. And artists become so absorbed in their creative process that they become oblivious to everything else around them. So we become our own worst enemies.
We moan about long hours, overwork, burnout, and the stress in our lives that comes from participating in the projects we deem mismanaged by those we perceive incompetent and unthinking. And sadly, more often than not, we do nothing constructive and concrete to improve our plight. That’s not because we don’t know how, but instead because we are so absorbed in creation that we can’t see the true source of our ills.
I have spent hours reading the project management and software development treatises of gurus such as Jim McCarthy and Steve McConnell. As a result, I’ve concluded that we as programmers manifest and facilitate the practices leading to our misery and poor-quality software through neglect and dereliction of our responsibilities.
Management, in the vast majority of cases, is not in a position to do the work for which we are hired. We are supposed to be the experts. But we do little to assert our expertise or behave as if we had it. So we bemoan our suffering.
Generally speaking, management is not sadistic in wielding authority, nor do they want to see projects fail. They’re not ignorant. What we call ignorance is often our perception of another’s lack of knowledge. Yet, those perceived ignorant often don’t know what they don’t know, and don’t know that they need to know it. And we encourage them to continue their ill-informed behavior by accepting their untenable project schedules and inadequate specifications.
How do we change? I don’t have all the answers, but I’m reminded of Midnight Madness at VBITS’97 San Francisco, when respected software development innovator and “father of Visual Basic” Alan Cooper said, “We [in this room] hold the means of production right here… .” while raising his hands before him. His premise was clear: We should neither fear for our jobs nor feel compelled to yield to the extortive techniques of management when we’re faced with projects doomed to misery or failure. And that we can begin by learning to “just say no.”
That’s just the beginning. We must dedicate a significant portion of our energies and expertise to cooperatively educate management in the processes of a successful software development effort. If management doesn’t want to cooperate, look for another employer. I know that sounds harsh. It is. But you need to stand your ground.
We as programmers must accept that the power to change our outcomes and reshape our lives is ours alone. We must exercise that power, because it is our responsibility as professionals, not only to our craft, our projects, and our employers, but to ourselves. The future of the industry and our quality of life, individually and collectively as programmers, depends on it.