Slashdot Mirror
How Can a Programmer Make Everyone Happy?
Nuttles1 asks: "Ever since I became a professional programmer, 4 years ago, I have struggled with giving my superiors everything they want. For instance, I have a programming supervisor that stresses correctness in programming first, amount of time needed second, features third, but I also have upper management stressing features and amount of time needed first and correctness of programming a distant second. The nature of my job requires pretty strict deadlines so time is not very variable. So, things get done in a way that fits the time allotted. The problem is that I don't make my direct supervisor happy because of the time constraint shortcuts in correctness must be made. The other problem is that, because I perform within the time constraints, they think that the time constraint can either stay relatively the same or that they can be squeezed a little more. Upper management also expects the advantages of having a strict programmatically correct program (code reuse, loose coupling, ease of maintenance) and are at loss when things are less then perfect after the initial release. It doesn't seem like a programmer can come out ahead. I have read many books but they usually have a utopian viewpoint or view time to develop as a variable. In real life, how do programmers handle this situation?"
Hate to say it, but in both cases here, he was absolutely right. You're an engineer. You don't deal with customers on anything other than the purely technical level. What you were doing --- making estimates, adding functionality --- was making business decisions. You got away with it this time but you were running the risk of seriously screwing up any business relationships your company was participating in. For example, in the business with the estimate, what would have happened had the customer insisted on going by your estimate and not your manager's (doubled) estimate? At a stroke you would have halved the company's billable hours. Not good. The only way they could have gotten out of that is by telling the customer that you'd spoken out of turn, which would probably have led to you being told to find another job.
First rule of dealing with customers: find out exactly what your responsibility is, and don't overstep it. If the customer asks about a new feature, say, "That sounds feasible, but of course I'll have to run it by X first," where X is your business contact. Or even better, say, "You'll have to talk to X about that, I'm afraid." This is the kind of thing management is for; use it...
IF that's the situation you're in, then first and formost, your company has a HORRIBLE corporate culture for development. If your boss and upper management are not in sync as to what's important, then I recommend you do what your immediate supervisor wants. If upper management has a problem with what you're doing, refer them to your manager. Your manager isn't there just to give you work to do, but he's also there to act as the sh*t filter and keep you from being swamped with all the other political crap that happens in a company. That's part of what he gets paid for.
Only other option is find another job where things ARE done correctly and management is all on the same page.
Well, I was going to post an angry missive about how the IT industry is going down the toilet, and "correctness" is going out the window, but it looks your boss is spot on: strive for correctness *first*. Make sure you have unit tests striving for 100% coverage. Make sure the database has full constraints. Make sure you have actually studied the relational model if you're in charge of it. Make sure your code is clear and simple and well-thought-out. If you had to write code in a hurry, THROW IT AWAY and write it anew (maybe test-driven this time).
And the other piece of advice is: always do what your immediate boss wants, let him report to HIS boss.
Looks like your solution is easy. Just do what the super says. And if he starts saying that correctness isn't important, but "shipping" or "features" are, find a new job. Don't pollute the IT industry with more insecure, crash-prone garbage.
How do you mean the idea that making estimates is a business decision?
If you mean that giving an estimated delivery date to the customer is a business decision, I can agree with that.
If you mean that estimating the amount of work a project will take is a business (or at least, non-technical) decision, I disagree.
If I worked on multiple projects, I would rely on my manager to schedule my time between the projects -- but I would rarely trust my manager's estimate of how much work there is in any particular project more than my own estimate. The difference seems important.
how to invest, a novice's guide