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?"
Well, from your narrative I see you've landed the ultimate professional progammer position: one where management doesn't listen, tries to squeeze deadlines, and thinks code more than anything else has to be correct (the unfortunate thing about that being your management, the least qualified to say, probably defines correct.)
And, forgive me, I can't help but notice but the word client or customer is not mentioned even once in the narrative which indicates an upside down world for delivering applications (not all that unusual, but still upside down).
Also, you mention superiors, try to be a little less humble, they're likely not. And, you talk about "upper management". When upper management has their uncalloused little fingers all the way down to your level in determining quality, ....
Ultimately, unless you have some strong ties, or visions of fast advancement you'd be no worse off if you looked around a little to see if there is someplace that seems a little more attuned to the real world and a little less pedantic about "coding".
aside: (but related) I first encountered how crazy a world it could be with my first big assignment. I had to sit down with my manager, and our client. The client described what they wanted, and I gave a thumbnail estimate, apparently to the surprise of my manager. Surprise number 1: my manager took me into "the room" and told me never to give an estimate to the client without his approval. (I might agree with certain aspects of this, but I was confident of my estimate and had sort of figured it was part of my responsibility.) He wanted me to double my estimate, and that was what we would base our charge to the client on.
I finished the project ahead of my original estimate -- adding enhancements and extensions to some software we'd purchased from a sister telcom. When I delivered it to the clients, ahead of schedule, I pointed out that part of the original output of the original program was just garbage, i.e., there was no code written around that output, and it had no correlation to the rest of the report. The client knew already and told me they always just ignored that part of the report. I asked if they needed or wanted that part of the report, and their eyes just lit up. So I offered to deliver yet a different version of my code which included a fix for the broken part of the old application. The client was ecstatic, a glowing letter ensued.
My manager took me to "the room" again. I tried to remain calm, waiting for the accolades, perhaps even a bonus? But, he pointed his finger in my face and said, "Don't you ever deliver more to the client than you say you will!". Stunned silence.
You should report to one mananger, and one manager alone. That will also be the person to assign you work, and give you priorities. That will also be the person who gives you performance reviews. So you better do what that person says. You have no business following low level directions like "what programming methodology to employ" from upper management. And upper management definitly has no business telling you how to do your job.
:)
Well, in a perfect world, that's how it should work.
This is not so much a programmer problem but just a business problem; also known as a people problem. Just substitute programming with any other job description and you have the problems everyone deals with on a daily basis. There is no right or wrong answer only the relationships you have to deal with.
Quality Hosting e3 Servers
Insist the "higher-ups" go through your direct boss. Not every boss will protect you this way, but unless it's a really small startup, they should, IMO.
The clearance system sounds logical. It is not. It is completely arbitrary. -- John Bolton
Here's the thing, just deal with it for awhile. Make some money, and then leave for another job that has smart people in charge. Wannabe programmers that are in management just screw everything up cause they think that if they follow the one guideline they remember from a 900 page development book they read in 1983 while studying COBOL, that everything will be perfect. Chalk it up as experience, or "paying your dues", or if you're past those points in your life, deal with it or move on.
Now of course, if you're working on some important systems like aviation, military, or any of the MMORPGs I play, then shutup and get back to work.
There are several things you should consider:
* "Dead lines" are never really dead lines. They are just guidelines to when you should reach something that works (not works well). The management (or a good management) always takes into account you probably won't make it in time anyway.
* Good design and code re-use are there to save time, not to waste it. Take the time doing things right, and it will save you time in the long run.
* You should always please whoever controls your future (but first, yourself).
|| Geshem ||
...use the ice-pick on a piece of hell for my drink.
You can't make everyone happy, nor should you try.
Delegate - upwards, sideways, anywhere - everything that is not your responsibility: business analysis, requirements definition, project planning, test planning, and steer clear of the politics.
Insist on written documents, version controlled, reviewed and signed off, to show your supervisor what the constraints are.
You have to deliver to the company's scheduling needs, and you need to keep the quality as high as possible.
Anything you can add at the technical level is only a bonus, unless you can explain it (in tech terms) to the business as a benefit to them, and they understand, and care.
Now, for the important question:
How can you make YOURSELF happy?
(otherwise, what are you doing it for? - and don't say paycheck, 'cos there's a balance and money ain't everything)
After 10 years in the industry, I've got the following three methods:
1. Do everything everybody asks you to, even if you personally think it's contradictory. Works in companies that have a strong chain of command, but results in code you would never want to include in your interview portfolio. And gets you targeted for first layoff.
2. Go your own way, but do plenty of software engineering to back things up. Gets you targeted quite often for layoff, but since you have the numbers, you rarely get laid off- this method has resulted in up to two years in the same job for me. Results in code you can be proud in, but you'll never meet a deadline, and that will eventually get you fired, so to give yourself extra time always multiply all estimates by 4 (Scotty school of engineering).
3. Give up, and offshore your job. Everything gets coded exactly to spec, even when the specs make no sense, and nothing gets done right- but at least you'll end up doing what you're told, until your bosses find out, and then they cut out the middle man (you).
In other words, I've yet to find a winning method in the situation you describe.
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
"I don't know the key to success, but the key to failure is trying to please everybody."
Please the boss that can give you the raise and fire you.
include $sig;
1;
A good way to deal with conflicting bosses is to make them agree.
Or maybe it's just your job to write correct software with lots of good features in a fixed amount of time. Get it done or you're fired.
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.
Sorry, just thought this fits too perfect:
Peter: It's a problem of motivation, all right? Now if I work my ass off and Initech ships a few extra units, I don't see another dime, so where's the motivation? And here's another thing, I have eight different bosses right now.
Bob: Eight?
Peter: Eight, Bob. So that means when I make a mistake, I have eight different people coming by to tell me about it. That's my only real motivation is not to be hassled, that, and the fear of losing my job. But you know, Bob, that will only make someone work just hard enough not to get fired.
The ratio of people to cake is too big
You need to be honest with yourself and determine how good you are, then move on. It's not worth trying to fight a system like you describe, and if you are in the top half of the talent in the industry, there's a job out there for you that's more interesting, pays better, and isn't half as painful.
If you're in the bottom half, I guess get used to it and be happy you're employed.
Slashdot - where whining about luck is the new way to make the world you want.
Lets get real here. The stiuation is bad, your'e not in a position to change it. Ask yourself who writes your performance reviews. Talk to them. Find out what they want from you. Give it to them. Wait for your review and then either move up or be prepared to move away.
Sometimes you just have to be your own best friend.
The software development triangle states that features (and, I suppose, the overhead of developing to whatever standards your managers happen to define as "correct") are balanced against resources and time. If you want to give a programmer less time, give him more resources (money, more developers, etc.) or accept a less sophisticated program.
:)
It sounds like your managers aren't respecting this principle, and perhaps the only advice I can give you is to talk to them about it and/or start looking for a job elsewhere
Not to be too pessimistic, but no matter how large the project is, no matter how important it is to everyone involved, it will be faster to slip it now and get it done right than to fsck it up and need to do it over.
Projects slip all of the time. Someone is setting up how much time you have. Time is always variable, and is negotiated with outside entities. Your boss's boss, the loonies in marketing... someone is setting the schedule. Schedules are always optimistic. The bigger and more important the project, the more likely it is to slip.
The key is not to do what people want, but what will make them happy. Your immediate boss probably wants Stanford dissertation level code, but would be happy with good documentation and re-usable classes. Your higher-ups may want it done fully featured last week, but would be happy if you explained that the extra time you spent now can save a week off of all of your other projects. And if you can only make one person happy, tell everyone else to go to that one person. It takes guts to tell a high-level executive to talk to your manager, but that's what it takes. And sometimes you have to tell your manager to talk to the high-level executives. But if you can't make lots of people happy, make one person happy, and tell everyone else to stuff it on their authority.
Most importantly, the code you make should make you happy. If it doesn't, it isn't going to please anyone else. More importantly, though, you're selling your company your time and experience, not your soul. If your experience (however young) says to do something differently, that's what they're paying you to know. And if it's your soul they want... just recognize that a wall-street banker can make upwards of 200,000 dollars their first year. Souls go for a lot more money than you probably make.
Either way, you're getting laid off in 5 years. Good luck!
The ______ Agenda
Nuttles1:
p2sam: You should report to one mananger, and one manager alone... Well, in a perfect world, that's how it should work. :)
Just be completely honest and forthright in all your communications.
Suppose you have
Then your emails would read like:Surprise number 1: my manager took me into "the room" and told me never to give an estimate to the client without his approval.
My manager took me to "the room" again. I tried to remain calm, waiting for the accolades, perhaps even a bonus? But, he pointed his finger in my face and said, "Don't you ever deliver more to the client than you say you will!". Stunned silence.
This is just atrocious management.
A good manager would have practiced [over and over again] the interaction before he ever let you meet the client face to face.
For example, he would have stressed things like
And then he would have gone through practice conversations in which he pretended to be the client, and he coached you as to what to say and what not to say, and how to hem and haw your way out of making any firm commitment [until the "correct" answer could be cleared by accounting].Your manager not practicing a client site visit like that with you beforehand, and then admonishing you afterwords, would be like a football coach not teaching his playbook to his players during practice [or never even showing them the playbook in the first place], and then yelling at them after the game because they were clueless on the field.
In moments like these, I recall a certain Dilbert strip, where pointy hair boss tells Dilbert:
PHB- This project is impossible and can't be done.
D- It's finished.
PHB- The project will never work like this.
D- It works perfectly.
PHB- There's a spelling mistake here.
D- That's a number...
http://superconfigure-supergroove.appspot.com/
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.
Slashdot is really the wrong place for this sort of discussion, but here goes: It sounds like you're working on a product that doesn't have a product manager. The way it's supposed to work is that the product manager decides what goes into the product and coordinates with the developers to come up with a realistic schedule. Anyone who has a request should be talking to the product manager to get it into the schedule.
Seriously, I am a lowly technical lead of a team that usually consists of just me but grows to 3 or 4 people for a few months during "crunch" times. My management is required by our documented process to ask me how much effort something will take before it is approved. If the deadline cannot be met, they add staff well in advance or slip the change to a later build.
This space intentionally left blank.
A good way to deal with conflicting bosses is to make them agree.
There's a very important point in here. Your bosses are not constants, they're variables (well, that's one way to put it). If they're fighting each other through you, you need to get out of the friggin' way, or end up as collateral damage.
If your direct boss tells you to do X, and his boss tells you to do Y, right away you should point him to your direct boss. "I'll let you two sort this out and get back to me." Neither one is necessarily "right" or "wrong", in that different customers expect different things and will react differently to on-time crappy software vs. late excellent software... and there's sometimes a trade-off in writing lovely reusable code that's good in the long-term vs. hasty NON-reuseable code that gets the project out the door and money in the bank short-term.
There's also the trouble that some programmers who are told to "design for re-use" will bog the project down into eternity with bloated "handle-every-possible-case" code, while others will simply spend a little more time thinking and come up with an elegant solution that's *smaller* than the one-time-only hack job, and reap the benefits in the very next project. And alas, the average programmer without strict oversight falls mostly into the former camp. So it's no simple answer.
But these are business decisions that your boss and his boss need to sort out. You should just indicate that you understand that these issues exist, and suggest (in a friendly way) that they do their jobs.
Number one montra in business application development. "I'm doing this for the user"
;)
.Net are likely the most widely used and have a collection of the greatest tools (sorry Java guys, eclipse just doesn't hold a candle to Visual Studio). One of the greatest things about developing in .Net is that we (finally!) get true object inheritance. And while people smile and nod and say isn't it great with out knowing why, I can tell you, I can't imagine coding with out it. One of the few things I really agree with Joel Spolanski [sp?] about is code up front. It takes longer to build a completely abstract data layer and impliment a standardized data object (using inheritance and abstract factory classes), but the advantage of having a DLL that can be inserted into any project and give you immediate dev time access to database metadata is immense. Having a series of base classes to handle the user interface, threading, data access, business logic, etc will save significant time in the long run.
Remember that. The user (customer/client/employee) defines the features they need. These features form the basics of the requirements document.
Your tech lead/analysist/coordinator is going to ask you for time estimates. Business sciences says the way to find this number is to find the Optimal time(a), the most likely time(b), and the worst case time(c) and apply the following formula:
Expected time = (a + 4b + c)/6
If I think I could get a roughed out edition together in 8 hours, I would use a=8, b=16, c=58 for an expected time of 22 hours. You to can sit through hours of business science and learn this too, or just use the old addage of "triple it!" and quote 24 hours
So, you kick that number back to the coordinator. The coordinator looks at other projects on your plate and priorities and sends a time estimate back to the manager.
That should take care of the deadlines and feature set. You have a rec document, and a schedule. Next up was code style. Most current business office application development is going to be in a RAD environment. VB and
Our apps now our no longer even apps. We run a portal like interface, and when we receive new user requests they get developed as modules that are simply plugged into the existing system. Here are some out dated, but still handy looks at the type of design we use.
http://ringdev.com/code/GFCTeirDesign.gif
http://ringdev.com/code/GFCNamespace.gif
Once you have a code base. Developing new apps is significantly easier, faster, and the code you produce is more stable. So your tech lead is right, code correctness is very important.
And finally, don't be afraid to say no. I have 3 tiers of projects. Immediate, Down the road, and Ignore. If my coordinater drops something on my desk with a very low priority and a very large work load, I usually tell him I'll take care of it right after I clean my desk. Which usually implies that anything on my desk gets round filed. It is your manager and coordinater's job to take care of scheduling. If they are putting to much on your plate, sit them down, prioritize, and give back.
-Rick
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
We drink.
After reading all of the sibling posts stating that you shouldn't have done anything extra, and that your manager was right to criticize you for making its customer happy, all that I can say is that if that type of thing is a preferred standard American business practice, then it's no wonder that our country is going down the toilet.
Those who sacrifice security to condemn liberty deserve to repeat history or something. - Benjamin Santayana
I explained the problems you're facing to my wife.
She said "How long has he worked for Microsoft?"
After giving it some thought, she suggests "get some balls and ask your boss exactly 'what do you want?' so that you can cover your ass, preferably by email and when the higher smucks express displeasure, hit the print button."
She goes so far to say you should include the higher smucks in that discussion of how it should be done. Carbon copy them in the email if you're emailing.
Disclaimer: I am posting her suggestion because she has been in this type of situation and came out well. Personally, I see a danger of tanking evaluations and having to keep an eye out for the next job.
B) Eliminate all the stupid users. This is frowned upon by society.
Talk to your line manager. In a private meeting, explain the compromises you're having to make in your work. Explain that the code you're being forced to release is unmaintainable, is prone to be bugged or poorly-structured because of the time constraints being forced.
Explain a compromise where you get some of the time you want in return for some of the code quality you want. You'll never get all the time you want but, if you can convince your boss that it's going to be of overall benefit, you might get enough.
Most importantly, if the shit hits the fan and your product comes back to you, make sure you're absolutely realistic with management about why this has happened. Yes, the code was sub-quality. Yes, the design was insufficient. Yes, it's management's fault on both counts for not allowing enough time for the proper running of the project.
One of the main problems is that a typical lifecycle (specification, design, implementation, testing) makes no sense to management. Even a technical manager will try to rush the specification and design so they can have demonstrable progress - something to show the client, even if it's not been thought through. And, as soon as the product looks complete, they'll want to get it out where it makes money, regardless of how thoroughly it's been tested.
Educating your superiors about the reality of these things is hard work. You might have managers that will - slowly - learn, in which case you may make some progress. Alternatively, look elsewhere: it's one of the most subtly self-destructive things, to be stuck in a job without being given the opportunity to do it well. Find somewhere that gives you that freedom.
For the record (and I haven't responded to the others, but finally, I need to respond to at least one)...:
Ahem, for the record, at the session with the client my manager turned to me and asked me how long I thought it would take. That was when I gave my "estimate". When he chastised me later it was for offering such a short estimate, way too short in his opinion. (I know I didn't make that clear in my original post.) We discussed it, always in a civil manner, I stood by my opinion I could deliver in my estimated time frame but relented to his insistance I double the estimate for an official estimate for our client. I STILL finished in less time than my original estimate (including the fix of the other part of the code).
As for that "other" fix... it wasn't something they had to test -- it was functionality they had long since abandoned as being something useful. It was a "dead zone" (3 lines per item) on the report they had learned to ignore because the data in that zone was incorrect and useless. The fix I applied took little time, and little effort, and did not put at risk the estimated delivery date (the DOUBLED estimate).
We had an ongoing relationship with this client, essentially a locked in deal (their organization was part of the same umbrella corporation). Their list of needs and projects was virtually endless so it wasn't as if finishing this in half the time cut into our revenue stream.
And the good will from this extra effort was returned in full. Our relationship with the client went from adversarial to collaborative. They LOVED the results they were seeing, and changed their attitude and demeanor with us. (They literally used to sit in meetings with scowls and arms crossed, distrusting every suggestion, estimate, etc. we proposed.)
All in all, I was quite surprised at the beating I got for my post. Not so much that I got beat up, but that these attitudes are so pervasive. Maybe I didn't elaborate enough to give enough insight to my environment. But, I believed then, and I believe now the sum total of how we all do is a result of how hard we try to do good things, not how hard we try to maximize "controls".
(example: a while back I drove to a tire service store well known for its service -- I'd never been there before. I had a low-speed wobbly steering wheel problem. I pulled into the lot, and they literally ran out to my car (an advertised "service philosophy" of theirs, but a surprise to see it as real) and asked me what they could do for me. I described my problem, they took my key and immediately put my car on a lift and did some quick diagnostics. After some tweaks and adjustments they returned my car and told me it should be better... and if there were any problems, to bring it back. No Charge! And, the steering wobble was gone!
Less than a year later I needed new tires -- guess where I bought my new tires? The good will they brought more than offset the $50 I could've save at Costco... I'm a loyal customer.
Hello mooingyak
First, I need to (and wish I could somehow propogate this better) for the record emphasize and clarify my excellent relationship with my manager. We both gave as good as we got from each other and respected each other. He gladly and without prompting rewarded me for good work done well many times. But this was a case, as you pointed out, where his job was to make sure corporate procedure and policy prevailed. I still think he was harsh, and maybe even a little wrong on this one, but he was (and to this day is) a good guy and did try to do the right thing.
To your other point, I agree, excellent point that it has got to drive a manager crazy when an employee sets off on his own, doing "extra" work. In this situation, (and I was considered a manager, technically, and expected to show appropriate behavior) the extra work needed to correct the "other" problem was less work and time than it would have taken to go through any process.... unilateral on my part, but NONE of my tasks or responsibilities were compromised... AND (I think I mentioned this in one of my posts) I ensured my deliverable was the deliverable they expected with the option of considering the other fix (which is why I forked the code... to allow for either choice, with no contamination to the original work).
The final result was a much better relationship with the clients.
Ultimately, your points are correct and well made. My disappointment was what at the time felt like excessive pedantry and strict policy adherence.
Best Regards... yagu