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.”)
-TimK
By eeevans June 7, 2010 - 3:41 pm
Tim,
I know your pain and psychological torment having gone through a similar situation. I find comfort in your story and relating not only the details but also hinting at how fragile it leaves you. I wish you much peace and success.
Thanks for writing!
Ed
By Tom Metro January 14, 2011 - 10:13 pm
“…I cannot see how I could have made the experience a successful one…”
This is not an ideal way to be viewing a consulting engagement. To expect 100% of your engagements to be successful is unrealistic, even if success depended on only yourself. That success is often equally dependent on the client means that a sizable percentage of your engagements will not be successful to some degree. I’ve had a bunch that I’d consider unsuccessful by various metrics, such as delivering a product, or even getting paid.
I can sympathize with the desire to walk away from software development, because there are a lot of situations that are like this. But at its best, software development can be quite enjoyable.
The goal to strive for is building a consulting practice or organization where you have enough demand for your services that you have a choice of clients and projects. Then you don’t have to be concerned with coaxing clients into following best practices. Interview the client, and walk away if you see red flags. Not easy to achieve, but an ideal to work towards.
-Tom
By J. Timothy King January 27, 2011 - 9:49 pm
Hi, Tom. I agree that you can’t expect a contract to be 100% successful. IIRC, I originally wrote that to convince myself that I actually did my job as thoroughly as I could.
However, you’ve hit on an important point. I do sometimes think in absolutes: perfect or unworkable, and nothing in between. I’m convinced, that pattern did contribute to my depression after I was laid off. Depressed people, in general, tend to think in absolutes, and the more depressed, the more absolute they think. The job I was laid off from, it wasn’t perfect, but I didn’t realize how good I had it there. And when the patterns I had developed there didn’t work elsewhere, and I didn’t know how to develop new patterns that would meet my needs, I fell into a deep depression.
I agree that software can be very fulfilling. But I actually like what I’ve been doing, developing software just for the money, and doing other stuff for personal fulfillment. I finally understand why some software developers devote so much time to open-source projects. 🙂
-TimK
By Randall June 12, 2011 - 5:48 pm
Thanks for sharing.
By Joe September 7, 2011 - 4:48 pm
Do you still write software or you are now just a fiction author? After 14 years I’d like to quit developing software and just do nothing!
By J. Timothy King October 12, 2011 - 9:42 am
Joe: I still develop the occasional software project, while I build my fiction fanbase. I do software “just for the money” now, and both I and my clients are happy with that arrangement. In the incubator, I have a blog post about that.
Cheers,
-TimK
By Mark November 7, 2011 - 5:54 pm
Hi,
I found your story when searching for solutions to being depressed from working with a computer all day. The solution is probably to have a lot of fun outside when not momentarily working. Still, I need to read upon that.
Life has a lot of entropy. Your story is quite different from mine, but the impact and experiences are almost identical.
It appears, and I still don’t know to believe that, nearly all software development companies are doing it wrong. There are no proper managers with deep knowledge of the software development methodologies. And at the same time, there are no proper engineers with that knowledge, as they are too busy with the implementation and cannot do the management simultaneously.
There are usually also no proper consultants.
I have never seen a real project with all requirements properly specified. From there, we can jump to consequences: I’ve never seen a real project delivered on budget, on schedule, and with all requirements implemented.
Is it possible that only big companies may offer the luxury of having a Business Analyst and UML for everything? When they have him, does it mean you cannot make architectural decisions, name your classes, methods, …?
When you want to do requirements specification and produce the UML, does any manager permit it?
In my experience, the only working model with todays companies is when the manager is also the CEO and the customer himself. Then, he has other customers using the project. The manager comes every day and tells you what to do. You come when finished, show him what you did, and together you make adjustments or consultations.
It’s really simple, very efficient, and guaranteed to work. And with this, you don’t need to make any unrealistic estimates. It’s simply about working on it, getting it done, it’s paid in meantime. Apart from this, I’d say all leads to failure due to insufficient adherence to methodologies or eventually unsuitability of the chosen methodology for the particular type of project.
Requirements are never clear, and there are always changes anyway. 🙂
By Mark November 7, 2011 - 6:27 pm
Sorry for flooding this place with comments.
To that, I’d like to add:
* software engineering has origins in laboratory conditions where everyone has a doctorate degree
* laboratory conditions make it possible to evaluate and analyze software development methodologies
theory:
mainstream audiences are eager to “do the same thing”, if you like, as the Ph.D. researchers or equivalent computer scientists.
Average mainstream IT employee is not working in laboratory conditions where the requirements are clear, the process well-defined and systematically approached. At the same time, mainstream IT employee does not have the same level of discipline and education relevant for the problematics. Years experience is, strictly speaking, a very misleading proof of qualification, and yet everybody is contempt with that.
hypothesis:
if everyone working on the project had a doctorate degree in the relevant occupational field, discipline and knowledge could result in adherence to formal methodologies, as well as their proper application in the relevant context, and reasonable decisions could be made. Prior to starting any project, the very essential thing is evaluation of available technology, design processes, and suitable architectures with aims to divide & conquer.
(actually, this would be a very good research proposal. Quantitative research of adherence to standards, formal methods, formal education, IT qualifications of the management, etc. I guess that most companies would not pass the evaluation of whether they are doing it right. There is always a lack of IT professionals who can code at least a working Hello World.)
By na June 14, 2012 - 6:04 am
Great…i found this article finding about “Depression and Developers” because i inside one.. now.. i dont want rebuild me.. and dont want code more.. 🙁
By J. Timothy King June 19, 2012 - 10:34 am
Na:
I’ve so been there. Since then, my feelings have recovered a lot. I still enjoy coding and developing and creating. I’ve even worked with developers and teams that do most things right and are fun to work with. They do exist, and they’re not trying to hide themselves. You just have to be persistent and disciplined in seeking them out.
I still believe that the software development industry is broken in a number of ways. But I no longer feel completely down about it, and hope you feel better about your prospects.
Best of luck.
-TimK
By Robert June 26, 2012 - 3:36 pm
Thanks for your columns here. I have enjoyed reading them. It has also been enlightening reading the comments of the other contributors.
Here in Los Angeles, employers try to hire software developers at ridiculous rates such as $14/hour, and they have the guts to ask for years of experience with twenty software tools for that price. The bad economy and outsourcing make things insanely competitive. I personally know a few homeless developers, guys who write Windows SDK calls in assembly, for instance.
I used to be a star computer science grad with dreams and ideals, then a PERL, JavaScript, C and C++ programmer. I only had 3 years of PERL etc. and every employer seemed to want five years experience. I was outgunned. I started my own computer repair business so I could call the shots and have control over all the technical aspects, and then I got into technical writing years ago when my talent was recognized by our CEO. I’ve always loved writing and as writing is similar to software development, it can be creative and fun. But I do wish I could return to the creative bliss we all pursue as developers, automating tedium and creating wonderful things.
By Robert June 26, 2012 - 4:11 pm
To keep your interest in software alive (and depression at bay), you must be working on something you love (such as a personal project, or a client’s project done some unique way, or research on good development techniques). Without a project, you can lose the interest in software development, and to some extent, life in general.
We don’t need doctorate degrees nor exhaustive analysis to follow simple, proven practices for good software engineering (up to a point). Excessive greed has led companies to attempt to get away without these essential practices, or simply cancel projects if they require too much “brainpower.”
By J. Timothy King July 5, 2012 - 2:39 pm
Hi, Robert. I hope you’re doing a little better since when we last chatted. My latest post talks a bit about these issues, and some of the changes of mind that I’ve had over the past couple years. -TimK
By Nadiia Kehrli November 16, 2020 - 6:41 am
It is easy to fall into depression when your client does not specify the requirements and experts a wonder from you. Or changes his mmind in the last moment.