Comments on: Timeline and Risk: How to Piss Off Your Software Developers

By: Rob

Rob — Thu, 06 Apr 2006 04:01:01 +0000

Great point, Ben. Your experience should serve as a warning to all of us.

By: http://

http:// — Thu, 06 Apr 2006 01:44:52 +0000

Great post. I’ve been in a similar environment where our dev team’s best efforts (above and beyond the call of duty) were met with further demands for productivity. It doesn’t get better from the situation you’ve described, though when you’re emotionally involved it is easy to believe that it must improve, that your efforts will be recognised. When we pointed out that we’d been working 80 hours weeks we were told we should be able to work a 40 hour week and meet the deadline and that any overtime we worked was down to our incompetence. After 12 weeks of ~80 hour weeks I found myself in hospital with a heart condition, at 24 I had a pacemaker. It’s just not worth it. I found the managers I worked with there to be motivated solely in getting a sale (selling unrealistic deadlines and expectations) and then pressuring, bullying and cajolling the dev teams to meeting their deadlines. If deadlines get met then the managers take the credit, when they don’t the blame is heaped solely on the development team. These environments won’t change as long as good developers stay in them, and they stay in these environments for the reasons you said you are going to stay with your employer. I’ve moved on but I’m friends with developers that still work there and their expectations that things will change, that eventually they will be recognised and appreciated is still as strong as it was the day I left and still as unrealised.

By: http://

http:// — Tue, 04 Apr 2006 22:49:14 +0000

I wish if I can have my Planning group to read this article.. I work in large insurrance company which works with concept PBR (Plan- Build- Run) .. famous acronym from the company’s list.. do they know that every step is different than each other and can take specific amt of time.. In our case, PLANNING takes higher priority and time than BUILD… actually the equation is ( TimeLine – PLAN Time = BUILD Time )… consider remaining time for BUILD.. I totally agree with the two options that Rob gave us here… That could save our time of maintaining the low-quality software.. we can use the same time for building the next good quality software. Rob.. it was always worth to read your article and learn something new.

By: http://

http:// — Wed, 22 Feb 2006 09:14:44 +0000

The assumption that programmers work at the top of their ability is completely wrong. We developers as a group seem to have a bit too high regard of their own professionalism. If you look at other industries there have been huge improvements in time, cost and quality over the years due to improved methods. This is true even for software development. Do some analysis of your own and your teams methods and I positive that you will find several areas of improvement.

By: http://

http:// — Tue, 21 Feb 2006 20:58:12 +0000

The phrase is “reap what you sow”, unless you are mixing metaphors.

By: http://

http:// — Tue, 21 Feb 2006 15:15:46 +0000

I think you’re two best options are to 1) find another job or 2) stop caring.

By: http://

http:// — Tue, 21 Feb 2006 15:13:37 +0000

I couldn’t agree more, and it’s not just programmers. If you tell anyone they’re not doing their best then either they’ll buck up their ideas, if they’re being lame, or, more likely, they’ll take offence, as they are doing their best. I don’t think it’s just programmers who try their hardest day in, day out. My g/f works for a drug + alcohol project. Her + coworkers do an emotionally demanding job, that they are all outrageously commited to. However, all it takes is for the (ridiculous excuse for) management to tell them they’re not doing the best they can, and they’re all looking for new jobs. When will managers learn, this isn’t the right way to do stuff. Stumbling in with a solution to a problem you know little, if anything, about is both arogant and insulting. Imagine if I came round to your house and told you that you didn’t love your kids enough. (ok, if you had kids). Would you be pissed off?

By: Shanti Braford

Shanti Braford — Tue, 21 Feb 2006 09:57:37 +0000

This comment is not about you or your team Rob… …but the sad fact is that at many big to medium sized companies, people simply aren’t *really* working as hard as they possibly can. Sometimes, it’s not their fault. These are the biggest possible reasons, imho: – lack of autonomy (some middle manager chooses the tools / technologies / etc everyone is to use by executive fiat) – bureaucracy / etc. – just like Peter talks about in Office Space, what do most people get if they bust their ass 80 hours a week? hardly anything. maybe an extra $5k per year raise, or .0001% stock in a stodgy company. – team personality issues (prima donnas, etc) – being forced to commute in to a stodgy, life-sucking cubicle work environment (when you could be 2x as productive at home or in a cafe) – Sorry if I’m being idealistic at the moment, but I’m about to start an incredible opportunity, including: – working from home – my own hours – my own schedule – working with the technologies I love (Ruby on Rails, etc) – very early employee in a thriving startup – plenty of stock (duh) – having a “manager” (though it feels just more like collaboration) who just “gets it” — we’re always on the same page w/o clashes – a technical manager, who also has great people skills (they said it couldn’t be!) It might not last forever but this is a dream opportunity and I implore anyone who reads this to stick to their guns and keep searching, if you are in a toxic work environment currently. You just never know. Tip: do what you love, even if it’s after hours, on your own terms. Eventually, *just maybe* you’ll one day have an opportunity to do it full-time. Shanti http://sablog.com/ See also: http://sablog.com/archives/2006/02/17/top-coders-20x-as-productive

By: http://

http:// — Tue, 21 Feb 2006 01:05:49 +0000

It will change because your current employer will die a slow death while those who value their technical talent and hire good management staff will thrive. This is evolution. Things take time. Be patient for the trends to work out on a global level, but in the mean time don’t keep working for idiots. You only have a few years to do good stuff. Make them count.

By: rwalling

rwalling — Mon, 20 Feb 2006 17:57:53 +0000

Thanks for all your comments. The bottom line, and something I should have mentioned in the article, is that I have no intention of leaving this company. Our software team is just too good and the company itself is respectful to its employees and treats us fairly. There will always be issues between management and technical people; if technical people got everything they want the company would likely go bankrupt because nothing would ever release. If management got everything they want the software would crash every third day and all the developers would leave from overwork. Somewhere in there is a middle-ground, and it’s my goal to find it. Unless the company were to become a hostile environment, which it’s not, I view leaving as giving up. If we all leave when this type of thing happens how will it ever change?

By: http://

http:// — Mon, 20 Feb 2006 16:46:53 +0000

If it makes you feel better (it won’t), this happens in other industries as well. In a previous life I was a commercial photographer for a small ad/pre-press agency that aspired to play in the big leagues. I was sent off to study with some of the best photographers in North America and learn how they do it. As will not surprise you, the very best had two things going for them: They knew gobs about what to do, and they took gobs of time to do it, so they can control every detail. Sound familiar? Then a local builder comes along and wants shots of their houses that look like the stuff in Architectural Digest. I quote the job based on how the AD guys do things: one or two shots per day. My boss turns purple, his veins stick out, little flecks of foam appear around his mouth, and he informs me that we are going to do AD-quality photography at a rate of six to eight shots per day, and no excuses. Sound familiar? So less than a year later the agency is basically closing the studio (they still do yarn catalogs and such), and I’m out looking for another job. Sound familiar?

By: http://

http:// — Mon, 20 Feb 2006 16:34:21 +0000

It’s a bit hard to tell what your exact situation is, so I’ll leave aside the question of whether you personally are being Dilberted. However I think it *is* sometimes reasonable to aim for “better quality in the same amount of time” – as long as the timescale is long enough (an entire project or milestone). There are numerous software practices (unit testing, for example) which can be used to improve quality *and* reduce overall time-to-release. It takes a bit longer to write the code because you have test code to write as well, but you spend less time debugging weird issues in integration. I’ve seen it happen. See McConnell’s “Code Complete” for a laundry list of other practices which can both improve quality and reduce overall time.

By: RedRobot5050

RedRobot5050 — Mon, 20 Feb 2006 14:47:40 +0000

Rob, It sounds like you’re entering a death spirial. I know because I’ve been there, and the prolonged overtime doesn’t just drain your productivity and work ethic, it steals the energy from your health and social life. Its not a good situation to be in, and it occurs in this industry all too much. To be blunt, your non-technical manager is an asshat. I remember reading somewhere on an agile/xp blog that in situations like this, the way around the problem is to form a group and collectively bargain. It does not mean ‘permanently unionize and go on strike.’ Just appoint a team leader or technical lead to speak to manager on behalf of the entire team. When 20 people are not happy and demanding a 2x increase in salary, management will take notice. Especially when you go to the non-technical manager’s boss. I would also say “just plain get out”. If your manager says things like that, he doesn’t know anything about project management. Does he have any credentials? A SEI PMP certificaion? No? Get out. Companies that hire stock managers to run software projects find themselves blaming programmers for lack of ability when its really management is all to blame. I wrote a “When to get out” article on my blog. http://www.christopherwilson.net/soapbox Its about 3 posts down.

By: http://

http:// — Mon, 20 Feb 2006 03:01:51 +0000

The flip side: I work at a large insurance company where an hour of downtime = $millions lost for the company. We generally have 100% availability. We do review code very carefully before it gets to production, and we spend lots of time & effort on QA. But on the other hand: # Any downtime problems are usually solved as fast as possible, which usually means duct tape. # We’re *too* conservative, and pass over improvements that we have no experience with. # Because of the high visibility, QA can get paranoid, and will often opt to “just test everything manually.” We waste a good amount of money this way.

By: http://

http:// — Mon, 20 Feb 2006 01:25:55 +0000

Lookit, you’re insulted. That’s great… it means you have a high opinion of your existing work ethic, and of your team. So, faced with this sort of challenge, you have two options. You can be the manager’s bitch, and be blamed for the inevitable. Even if you ask for a raise, you already see it coming — this project is likely in a death spiral. Or you can quit. You can see if you’re right about your skills, and those of your team. Go work for a company that values quality — you’ve identified a few in this article. Or start your own. It’s risky, leaving the familiar. It may not work out. But that’s your option. You’re not going to educate this manager, or any other non-technical manager. Their job isn’t to build software. It’s to motivate people to work until their hearts pop, then fire them and replace them with recent college graduates. The sooner you grasp this, the happier you will be.

By: http://

http:// — Sun, 19 Feb 2006 23:27:45 +0000

This is absolutely brilliant, because the insult is coming from folks that are taught only to trim fat, cut corners, and omit excuses; they normally don’t see the big picture that is the hard work or the long schedule. In your position, I’d gladly agree to turn out better work faster… under the condition of an immediate raise. Preferably twice what you’re making, because the way production is slowing from the upset grumbles, that’s probably what it will take to get everyone working again.

By: Adnan Masood

Adnan Masood — Sun, 19 Feb 2006 19:57:25 +0000

I can’t agree more. The Mythical man month discusses several disasters caused by similar kind of Dilbert’s pointy-hair-manager approach. I’d also grade it lower than add-more-people-to-get-it-done-on-time approach since it is innately accusatory to a developer saying “Build higher quality software in the same amount of time.” This approach essentially causes constant churn and brain drain in the org; people who have worked hard to build the foundation will stay for their emotional attachment but new hires will be constantly, just up and leave. Why? I’d say because if you want excellent code coverage, documentation, immaculate process flow implementation, extensibility, auditing and cutting edge architecture with security and scalability built-in, give people some time. Excuse me for the classic building analogy again but Rome wasn’t built in a day. And as Paul Graham said about architectural design “Architects know that some kinds of design problems are more personal than others. One of the cleanest, most abstract design problems is designing bridges. There your job is largely a matter of spanning a given distance with the least material. The other end of the spectrum is designing chairs. Chair designers have to spend their time thinking about human butts.”

By: http://

http:// — Sun, 19 Feb 2006 18:19:50 +0000

The XP people will say that one other parameter you can tune is scope. If your boss wants better quality in the same time, then you may need to reduce feature set.