Depression and the Software Developer: The Last Straw (Conclusion)

Photo © 2007 Jason Eppink CC BY-NC-SA 2.0

Another part of this series of posts, “Depression and the Software Developer.” This latest story I started on Monday, part 4 of “Depression and the Software Developer”.

[Note: You can read the story from the beginning in order to catch up.]

No client or employer will ever admit to you that he doesn’t want to deal with reality. What he really wants is for you to just deliver what he needs, with zero effort on his part, in zero time, for zero dollars. If he gives you any more than that, it is only in grudging acceptance of the fact that you are not the omnipotent God. But a surprising number of project managers still act as though developers are superhuman, even if they accept that we are not divine. And a surprising number of developers are willing to accept that they are superhuman, even if they can’t deliver the actual goods.

And that was the case with this project. So I had no idea what made up the NOKWID feature that I was supposed to be developing (called NOKWID, because No One Knew What It Did), and Pointy-Hair 1 (the developer-turned-manager) and Pointy-Hair A (the manager-turned-developer) both seemed to be going out of their way to keep me in the dark.

If I were a voice talent, it would be like giving me a stack of ill-digested notes scribbled on sticky pads and saying, “Okay. Here’s the voice-over script. We need this by Thursday. When can you have it recorded?”

Needless to say, it stressed me out.

But I made the best of the situation I knew how. I took ownership of the spec and tried implementing NOKWID the best I could. But Pointy-Hair 1 still wanted to know when it would be “done,” and every time I took a step on the road to “done,” Pointy-Hair A pulled back the curtain to reveal a whole new maze of twisty passages, all alike, that I would need to navigate. I started to feel that they were working together to make my life miserable. At the very least, they both seemed to know what the actual requirements were, even though no one was telling me.

In a last-ditch effort, I rewrote the entire spec, soup-to-nuts. I spelled out exactly what needed to be delivered for NOKWID to be “done,” and also gave options–features that could be rescheduled until later or re-prioritized as needed. I knew from experience that the truth this would reveal would look very bad indeed, but at least it would define a realistic goal that we could work toward.

That may have been Idiotic Decision #3… I don’t know. I do know it caused me to invest myself personally in the project, the end result of which was a months-long depression, from which I still have not fully recovered.

I was not the only consulting developer experiencing these same problems with the project. If I were, I might have suspected that there was something wrong with me or with what I was doing. Since that time, I’ve reviewed the ensuing events dozens of times, asking myself if I could have done anything differently to avoid the imminent meltdown that–even then I knew–was headed my way. Even with the 20/20 of hindsight, I cannot see how I could have made the experience a successful one, because what was missing was communication. Simple, basic communication. As a developer, you absolutely need clear guidance on your client’s requirements. All I could have done was to fail faster, to require clear guidance up-front, which no doubt would have ended my relationship with them sooner rather than later. So then I would not have gotten paid for all the hours I ended up wasting for them, but the experience also would have probably left me with fewer psychological issues.

Pointy-Hair 1 by this time was very fond of mentioning to all of us how far behind schedule we were–as though that could make up for us not knowing what the hell we were supposed to be doing. Eventually, he told me that he needed an estimate for how long it would take for NOKWID to be “done,” and he said that if I could not provide him with an estimate, then one would “be provided” for me. I knew this was bullshit, because he would have gotten a more accurate estimate by rolling a pair of dice three times and averaging the results. But I also knew I was also on the verge of actually having enough information to actually estimate how much work there actually was left to do. So instead of telling him to be realistic, I told Pointy-Hair 1 I’d get him an estimate within the next day. That was Idiotic Decision #4.

The truth was indeed not happy. To finish NOKWID, as I understood what was required, would take much more work than either Pointy-Hair 1 or Pointy-Hair A had ever thought. But I was confident in my estimate, having successfully estimated numerous projects before. I provided options that could get NOKWID delivered sooner, if they wanted to pick individual features to be excluded or put off until later. Instead, Pointy-Hair 1 and Pointy-Hair A got on a conference call with me and told me the two of them together would simply “bang it out over the weekend.”

I grinned.

I stuck around just long enough to see whether they would succeed. They didn’t. (And who could have seen that coming?) But within a week or two, they had released something. I glanced at it. It had bugs that I would have avoided, because I already knew where those bugs had been lurking. And their solution only implemented a fraction of the features that I had been told were needed. This reinforced my suspicion that they knew of a shorter feature list, but were unable or unwilling to let me in on the secret. Nonetheless, they seemed satisfied with what they produced, and I was truthfully happy that they had found a way to get this important software delivered, buggy or not. But I also saw that unless they–as overworked as they already were–could develop all the software themselves, they would never be able to make the project a success (unless they redefined “success”).

Since then, I’ve fallen out of touch with the people on that project. I did recently check the public-facing project website, but that wouldn’t be able to tell me when or how much of NOKWID was ever developed. The website is still up—so the company is presumably still in business—and it looks like they’ve implemented some of the features we were talking about, related to NOKWID. From what I see, compared to the state of the site a year ago, they probably found a way to get more time and funding for the project, and scaled back the requirements significantly. That’s not necessarily a bad way to go, because it allows you to make mistakes and to grow your business organically.

As for me, since then, I’ve only worked on one more significant software-development project. To my friends and family, I blame the economy. “There’s just no work.” The truth is more complex, though. The whole thought of going back into a traditional software-development project positively depresses me, because judging from my experiences and the experiences of my colleagues, most of them are run poorly and arrogantly. I would only work on an engaging project in a collaborative team staffed with capable people. Such teams do exist, but they are rare, and I have not seen one since.

(Continued: Click here for the epilogue: “Depression and the Software Developer: Smiling in the Piss Pot.”)


This entry was posted in Uncategorized and tagged , , , . Bookmark the permalink.

14 Responses to "Depression and the Software Developer: The Last Straw (Conclusion)"

Leave a reply