10 Things I Hate About Software Development
This blog post is intended to sabotage any chance that I’ll get a “normal” software-engineering job, because I don’t think I could ever go back to a “normal” job.
I’ve become used to extraordinary jobs, not “normal” jobs.
The following 10 things, which I hate about software development as practiced in much of the industry, I think will keep me from ever being successful or happy in a “normal” software-development job.
Along with them, I list the antiviruses that I hope will help me avoid these diseases, if I need to go back into software development, even temporarily.
-
Incompetent managers. Software development managers in general graduated from being software developers. Unfortunately, the skills you need as a developer are different than the skills you need as a manager. The best manager I ever had was not a particularly good or experienced software developer. Rather, she treated management as a profession, read books on how to be an effective manager, attended seminars, took classes, and as a result, she was good at her job. But most software-developers-turned-managers don’t treat management as a profession. Instead, some of them become telepaths, who expect you to know what they need without actually telling you; others become micromanagers, who expect to be able to do all the actual development themselves, using your eyes and hands and brain; still others become arguers, the worst of both worlds, who instead of letting you do your job, take great pride in pointing out everything they think you did wrong. So the next software job I take, I will be interviewing and trying managers carefully to make sure they know how to manage, regardless of whether they are good developers.
-
Snotty developers. I must confess to going through a snotty phase myself. It’s part of growing up. You have to live as a snot-nosed, young-whippersnapper, green-behind-the-ears code slinger before you can mature into a wizened Yoda figure. In fact, part of me still may be a snotty developer. I’m definitely snotty when it comes to my own work, because I don’t want anyone telling me how it should be done, as long as I achieve the intended results. But as someone who’s been doing this shtick for 20-something years, I’ve grown weary of junior colleagues telling me I don’t know what I’m talking about. And when something doesn’t work out as well as they thought it should, they persistently maintain that it had nothing to do with them, despite the fact that they had ignored every piece of advice I gave them. There’s only one sure-fire remedy I know of for this problem, and that is to insist on a higher rate of pay. People may balk at paying you through the nose, but when they have to—especially managers—they not only accept your advice, they seek it out, because for the money they’re paying you, they expect you to solve their problems.
-
Commoditization. That is, the devaluation of specialized knowledge. The most obvious manifestation of this disease is the company who outsources its development to a third-party contract shop in India or Mexico, and then wonders why the project is falling apart at the seams. A more insidious and pervasive symptom has employers and clients boil a job down to a long list of buzzwords, pattern-match résumés to those buzzwords, interview you to make sure you really do qualify for the buzzwords selected, and then look for the lowest price. And then they ask you to do everything under the sun, including those tasks that could be handled by a $20/hour contractor from Mexico. Instead, they ought to be looking for solutions to specific problems or for people to fill specific roles within the organization. For veteran jobs, that’s no longer about price, however, because if you’re specific enough, you’ll likely find only one or two qualified candidates, if you search for them, and whatever they want to charge you, you’ll pay. Again, the only sure-fire antivirus I know of is to demand a higher rate of pay, because for the money they’re paying you, they won’t treat you like a commodity.
-
Slipshod engineering practices. I am one of those programmers who actually believe software development is engineering. Many developers don’t believe in software engineering, or at most give it only lip-service. But software engineering is like gravity: you may not believe in it, but the result is the same when you step off that cliff. Developers who don’t believe in engineering experience bugs, hold-ups, overwork, and stress. To account for it, they blame the code, the programmers who worked on the software in the past, their development environment, the operating system… But they never do anything to fix it, because “we just don’t have the time.” Note, however, just because developers complain about not having enough time to fix the system doesn’t mean they’re using slipshod engineering practices. In fact, those developers who don’t complain are probably the worst offenders. Often, good developers complain about the code, but it’s really not that bad, because they’ve already fixed the worst parts of it, and the problems that are left just stick in their craws. These are the developers I’d love to work with. The quickest way I know of to assess the situation is to look at the code: Is it well-architected? Well-designed? Are there unit tests? If so, the team is probably using good engineering practices.
-
Neglect of quality. By “quality,” I don’t mean over-designed, fluffy, overly glitzy software. What I mean is, simply, software that works, that satisfies the customer’s needs, makes the customer swoon, has no bugs, does not constantly poke you in the eye—”See that?!” Ow! “See that?!” Hey! Cut that out! Quality is important, because it gives a team of engineers a sense of accomplishment, of pride, a healthy morale. And engineers who value quality will be professional, always improving their craft, always building better and better software. Again, a quick glance at the codebase should give some idea as to how highly the team values quality, because a quality team will use sound engineering practices. But you could also look at the finished product, and especially customer comments on the product and its support.
-
Black-and-white thinking. Frankly, I hate having my good ideas shot down with dismissive comments like: “Unit tests don’t catch every bug.” Yeah, but they catch more bugs sooner and cheaper than any other method of testing. Polarized, black-and-white thinking is actually a sign of depression, of hopelessness, of having given up. “My life isn’t perfect; therefore, I have no reason to live.” Sounds silly when put that way. But how many software teams are in a similar, self-imposed depression? “That technique can’t solve all our problems; therefore, it’s not even worth trying.” Almost every team has a naysayer, but such sentiments can cause actual depression in the more innovative among us, who actually want to better the team and its engineering practices. The antivirus is simple, if not easy: Early in working with a team, try to find one or two simple process problems and propose simple, direct solutions. Then sit back and see what happens. If you get a lot of hemming and hawing and ignoring and naysaying, think about whether you should split.
-
Focus on establishment. Humans have a natural need for stability and for camaraderie. That is, they need to feel like the floor is firm beneath their feet and that there are others on their side. But in some companies, these tendencies can become dysfunctionally pervasive. If you continue to do only what you’ve always done, only what everyone else is doing, you’ll always be safe from blame. But humans also innately need to do what they haven’t done before, to stretch their minds, to create. Because this gives one a sense of purpose. Rather than playing it safe, we should always be trying new things, and keeping those that work. But the dysfunctional company focuses on establishment, rather than on results. The antivirus is similar to that for black-and-white thinking. Early in the experience, try something new, and then see what happens. Do it early, before you develop an emotional investment in the project. It might even be best if the thing you try fails completely, because then you can see how the team handles failure. Even if your experiment fails, they should not make you feel like a failure for having tried it. If they do, think about whether you want to stay there.
-
Ignorance of modern research. Quick! Name at least 2 of the 9 teamwork-killers Tom DeMarco and Timothy Lister identified in their landmark work? It should be pretty easy, because they identified 7 of those 9 back in 1987. That’s what I mean by “modern.” Here’s another one: What 3 characteristics must a software team exhibit in order to have any reasonable chance of success, according to Alistair Cockburn in his research? Peopleware (2nd ed. 1999) and Crystal Clear’ (2005), for starters. This is what I mean by “modern.” Heck, we might as well even include The Mythical Man-Month in the list, because too many software engineers have never read it, either. At my next interview, while the development staff are quizzing me on my knowledge of Perl, PHP, and JavaScript, I’ll be sure to quiz them on their knowledge of Demarco and Lister, Cockburn, Schwaber and Beedle, Kent Beck, Michael Feathers—and of course, Frederick Brooks.
-
The blame game. Being caught in the blame game can cause stress, exhaustion, demotivation, and depression. It can also be the source of other maladies, such as black-and-white thinking, as engineers attempt to cope. Unfortunately, staffers don’t usually like to talk about the blame game, but a pointed interview question might reveal something. Something like: “Tell me about the last, big mistake someone made that cost the company money.” What was the fallout? Did anyone get yelled at? Fired? In a perfectly healthy organization, no matter how bad the error was, no one will have gotten yelled at; rather, it will just be accepted that everyone makes mistakes, because we’re all human, and the whole team will have looked at the process (rather than any particular person) to see how to avoid an analogous oops in the future.
-
Unrealistic expectations. I’m talking about the top-down variety here. Yes, engineers can—and frequently do—have unrealistic expectations of themselves. But that’s easily enough fixed. (Or at least I know how to fix it, with a bit of measurement, in my own estimates.) But I’m talking here about something different: Management wants such-and-such at such-and-such a date, and they won’t accept your promise that it simply can’t be done. When faced with such a situation, there are only 4 things you can do: Deliver less functionality. Take longer to deliver it. Reduce the quality (leading to delays because of unexpected bugs, and see #5 above—better yet, forget about sacrificing quality). Or spend more money (but adding people to a late project only makes it later—that’s Frederick Brooks, see #8 above). Management, under pressure, may not want to make real-world trade-offs, leading to overwork, demotivation, and depression for the engineers. Like the blame game, I don’t know any sure-fire way to discover this problem early on, because no one wants to admit to a new recruit that he’s walking into the lion’s den. But you might try asking about the team’s last overconstrained project or iteration, with a knowing, Columbo-esque gaze, and see if it prompts any reaction at all.
Now, if you happen across this blog post because you’re considering me for a job position, and if you think that I’m being abusive and unreasonable here, well, that might be a hint that I don’t want to work at your company.
Just a thought.
-TimK
Did you enjoy this post? Why not leave a comment below and continue the conversation, or subscribe to my feed and get articles like this delivered automatically to your feed reader.
Comments
“Always being the victim” is a habit that is hard to shake off. You can take almost all of these “hates” and turn them around to highlight your skill and expertise which is somewhat evident between the lines of this rant.
What you describe is quite accurate for most big corporations. However, it isn’t always true for small companies and is never true for 2-5 people start-ups 
So it these are the only reasons you hate SW dev and you like SW dev itself, why not think about a startup? You could, for example, base on your new experience and e.g. help with some IT/web problem the new book writers have (I bet you’ve got some).
Though startup probably breaks the whole idea of getting SW dev-related job just for money 
P.S.
I am all the time reading your blog in RSS reader and today was the first time in weeks (or months?) I visited it on the web to post this comment. At first I thought the link was wrong – the design changed really much
The current design is quite nice and I think is a bit easier to read
David: Yeah, I definitely have not gotten over being snotty.
Choy: I guess I’m just weary of being the odd man out. I’ve worked with a number of developers that I’ve admired and respected (and I trust for whom the converse was also true). But I’m tired. I want to live. I’m just tired.
Artem: Actually, the last bad experience I had (which I haven’t posted about yet—still too close to it) was with a 4-person startup. I came on as a consultant, along with a couple others, to help them out with a short-term project. They ignored most (if not all) of what I (and the other consultants) told them; the whole experiment was a disaster; and the experience plunged me into a deep depression, from which I still haven’t completely recovered. (Which might be evident in the above post.)
-TimK
Oh, I am sorry for your bad experience, Tim. I meant becoming one of those guys who start a company and therefore establish the rules.
Oh man, this sounds so much like me it’s scary. Choy is right about “always the victim” mentality, but the only alternative seems to be to stop caring.
And I’ve worked for startups and small shops a lot, but I’ve encountered exactly the same issues there as TimK describes. I’m working for one now, and I’m seriously considering moving on before I get as depressed as TimK (been there too, and not going back).
Artem: Oh. I get it now. Yeah, a startup is not a bad idea, if you have the capital or cash-flow to get you through the initial phase. I might do something like that, with a friend and colleague of mine—we’ve been informally batting some ideas around.
BTW, thanks for the nice comments on the blog design. It’s actually a stock Wordpress theme, called DeepBlue. After some research, I think it’s pretty close to what I want, but I plan to customize it.
Rick: One of the reasons I wrote this, even though it might seem negative, was to give me hope that I might actually be able to avoid some of the things I’ve hated most about working in SD shops.
Dedicating all my time to writing and being an author has helped me feel better, to lift my depression, because it’s something I really enjoy. But as I don’t yet have a large fan-base, marketing is quite difficult. And for cash-flow reasons, I fear (in the most literal sense of the word) that I may need to pick up more SD work to make ends meet. Just the thought sends me back into depression: not healthy. So I’m trying to come to terms with the idea, find some way to turn it into a positive experience.
Thanks for all your support, you guys. I appreciate it.
-TimK
I tried to do an anacrostic but gave up. These ten, I relate to. Difference is: approaching retirement I just shine shoes now for a living….
Tim,
I felt much the same as you did and when laid off after my last software gig, I decided to get into education. Went back to school, got my BA, finished my MEd in a year and have been teaching for 4 years now.
Oddly enough, all 10 are true there as well, especially number 9, the blame game. I wonder if it is the personality or the endemic problems in ’systems’ in general that cause these issues. So many people are able to completely ignore these issues, others rail against them, most seem oblivious…
Good luck to you, and I hope you find and answer that works for you!
Jerry
Jerry, I know that the same symptoms occur elsewhere as well. That’s probably why I’d also not make it in a “normal” job in any other industry, either. Ya know, at some level, these diseases are endemic to human nature. That would probably make a neat topic: exploring that question.
Thanks for the complement, octopusgrabbus.
-TimK
Tim, your post really struck me today – I’m sorry I didn’t see it earlier. But in all reality I’ve been in your shoes many times – some would call me a dinosaur because of some of my hardened but flexible ways. When I was just a Jr. Programmer in the late 70’s and early 80’s I was very cocky and one of my favorite reads was the “real programmers” (use Fortran) – during that time F-66 was my second choice of languages, and assembler was of course the primary. Throughout the years though, I’ve had to “change” my dinosaur ways and include the dreaded “C” compliers and other bloat ware compilers – As a side note I still have little if any use for many of the CASE type tools (Bloat ware). I still enjoy pounding out asm code in my spare time but for work purposes, I have to appear at least to tolerate the many Visual CASE tools. This being said, and now being one of the more SR. developers I have fun with some of the “right out of school” types that think they know it all with the bloat ware they love to write being torn apart to make it work faster and better – nothing like pulling out several thousand lines of code that are never used!
Hang in there, those of us that have been around for awhile are appreciated, but as you mentioned, we really have to be “picky” as to who we transfer to or work for. Next time you have a wet behind the ear green horn ask them to blow a prom (not more than 2K min you) that can boot an LSI and input 30- 50 inputs (analog of course) that can be streamed to a DC-600 formatted and rudimentary stats that will work with RT-11 on an old PDP! – Sorry for the reminiscing – but I do miss those days!
Thanks for the comment, Roger. That last paragraph gave me a healthy chuckle. The PDP-series is a little before my time, but indeed, I could plug my own ancient technologies in there. I’ve burnt plenty of PROMs (though by my day, we were generally using EPROMs). And I was one of the first engineers at my company to work with FlashROM when it first started becoming feasible for production use.
Although for web development, maybe a timely reference to gopher might be apropos.
-TimK
agree with number 1, incompetent manager could make worse everything, not only software development, but also another kind of development such as web development…
For me software engineer, manager and entrepreneur are all talents (they can be revealed or trained, but you need to have one). And the most important ingredient is that you have to LOVE what you are doing. Next one is result orientation which will help to see the situation from outside and help to avoid most of the problems The work should be a complete joy to feel good about yourself and achieve greatest results!
Thanks for the comments.
I agree, you have to love what you’re doing. But I’ve seen too many engineers become managers and then still act like they’re just engineers. Managing a team requires a different set of skills, and you have to study and work to develop management skills if you want to be a good manager. I agree about “result orientation,” in that you have to take joy in what your team accomplishes, and not in what you yourself accomplish. It’s a completely different mindset than when you’re doing the work all yourself.
-TimK
Your points are dead on. I’ve experienced most of the things you mentioned at my old job, which drove me to leave. Now, I’m freelancing and couldn’t be happier.
/me reads last paragraph
“Glad to see you got over your snotty phase!”
But I get your point. It’s like “If you think Dilbert is funny because it’s true, then I don’t want to work for you. If you think Dilbert is depressing because it’s true, then we understand each other”.