A few weeks ago, we started running a poll on DevSource about whether programmers are to blame for software problems. (This spawned from an article on eWeek that we republished here.) Here are the results of the poll:

A. 100% Yes. 162 people chose this one, or 11.70% of responders.
B. 75% - most problems are due to programmers. 263 people chose this one, or 18.99% of the responders.
C. About half of them are due to programmers. 453 people chose this, or 32.71%.
D. Very few; most are management's fault 293 chose this, or 21.16%.
E. None! It's all management's fault! 214 chose this, or 15.45%.

My own feeling is also in the middle, that the problems are half and half. As programmers, we shouldn't just assume that all problems are the result of management. It's too easy to be careless in our programming, and end up with programs with bugs in them. But on the other hand, we also need to do our best and keep management in line. It's too easy for them to promise feature after feature, and either not adjusting the ship date resulting in rushed work that's broken, or to keep moving back the ship date while the customer gets angrier and angrier.

Further, we've all been in the situation where we know that something just can't be done in the expected time, yet management doesn't want to hear that. Whose fault is that? I would argue its both our faults -- us, the programmers, and them the managers. Here's a typical scenario, take I:

Manager: How long will this take?
Programmer: Three weeks.
Manager: Excellent. Get it to System Test in two weeks and we'll have it out the door a week later.
Programmer: But...

Or, there's the overconfident programmer:

Manager: How long will this take?
Programmer: Three days.
Manager: Cool! I'll let the client know.

Or, the manager who doesn't listen:

Manager: How long will this take?
Programmer: Three weeks.
Manager: Not good enough. Do it in two.
Programmer: But... okay...

Programmers need to be realistic. The fact is, in most cases, there will be things that you didn't anticipate, and while you can't anticipate the problems, you can anticipate the fact that there will be things you didn't anticipate. (Got that?) And so when the manager asks, factor in the unknown. Managers, on the other hand, need to be willing to listen and to let the programmers speak up. They shouldn't insist the programmer finish something in a shorter amount of time than the programmer expects it to take.

Finally, without letting this blog run too long, I'd like to mention another thing I've seen out there far too many times, and that's the problem of over-engineering. Do you really need to use the coolest, biggest, most flexible design pattern involving a hundred C++ templates when you could write it in a much simpler way? True, the design pattern will allow for a robust system that you can grow over time, but does the client need that? And are the extra 10,000 lines of code really worth it? More lines of code means more places for bugs.