Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

How Can a Programmer Make Everyone Happy? 174

Posted by Cliff from the you-can't-just-do-the-best-you-can dept.
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?"
This discussion has been archived. No new comments can be posted.

How Can a Programmer Make Everyone Happy? More

How Can a Programmer Make Everyone Happy?

Comments Filter:

  • hmmm, is there a missing party here? (Score:5, Interesting)

    by yagu ( 721525 ) * <yayagu@[ ]il.com ['gma' in gap]> on Tuesday October 18, 2005 @07:32PM (#13822436) Journal

    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.

    • Re:hmmm, is there a missing party here? (Score:5, Informative)

      by david.given ( 6740 ) <dg@cowlark.com> on Tuesday October 18, 2005 @08:05PM (#13822707) Homepage Journal
      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.

      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...

      • Re:hmmm, is there a missing party here? (Score:5, Insightful)

        by chris_mahan ( 256577 ) <chris.mahan@gmail.com> on Tuesday October 18, 2005 @08:36PM (#13822911) Homepage
        Well, really the manager made the mistake of taking the engineer in there in the first place. The second mistake from the manager is not taking him in "the room" and laying out a plan of action.

        Ultimately, it's ALWAYS management's fault.

        Yes, Always. Always, always, always. Remember: It's always management's fault.

        Did the programmer slack and not deliver the program on time/at all? Management should have motived him or replaced him. It's always management's fault.

        Therefore: It's not the engineer's fault, ever.

        • Therefore: It's not the engineer's fault, ever.

          That's simply not true. Any member of staff working at an organisation shares a certain amount of collective responsibility to do their part well, and help others to do likewise. Only a smart-ass manager would expect an engineer to produce 100% bug free code and make no allowance for screw-ups. Only a smart-ass critic would expect management to hire only perfect staff and fire them instantly if their perfection diminishes. The real world doesn't work that w

      • Hate to say it, but in both cases here, he was absolutely right.

        Well yes. But a manager should have made expectations clear before bringing a subordinate into the room. If THAT didn't happen, then the manager is at fault.

        Those that suggest software (or any other product) should do EXACLTY what is contracted and NOT ONE SINGLE THING MORE are being, I think a little short-sighted. Yes there are IP issues, but those can be addressed with a bit fo boiler-plate legaleze -- this feature is provided as is --

      • 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 particu

        • It's just as you said: making estimates is a technical decision. Giving the estimate to the customer, isn't.

          The engineer overstepped his boundaries. He should have told the manager the estimate and let the manager run with it (if the manager wants to double the estimate, that's his prerogative and a matter of ethics.)

          Also, the engineer should have gotten clearance with the manager before adding new features.

          But in the end, it's the manager fault. He should have gotten the engineer aside before the meeti
        • Estimating the amount of work is a technical decision. Allowing for contingency is a management decision. If it's a fixed-price contract (as most are) rather than time and materials, the estimate MUST include a multiplier for contingency. Most projects will come in on time, some will spill over, and none will come in in less time, so overall you lose. Hence contingency to allow for that and still let the firm make a profit.

          Also remember that engineers are *notoriously* bad at estimating (see the famous
      • If the programmer was not supposed to comment during the meeting on such subjects then manager suffered a colossal failure by not making that clear. We always have ground rules on what can and can not be discussed and *anyone* taking *anyone* to a meeting with clients without such grounds rules is a fool and should be fired themselves.

        Regarding the extra functionality, I agree that it should have gone through management, which would have been able to assign a value and probably made a few bucks. On the othe
      • Yes - God forbid that you actually help the customer. They will hate you for that. Dodge and weave whereever possible. Delegate where you can and take no responsibility. This sort of internal empire building does nothing for the customer and ultimately nothing for the company. I will be modded as a troll.
        • You have a point, of course. But these are not the engineer's responsibilities. These are the manager's responsibilities. If this particular engineer is bucking for a management position, he might do well one day, considering he knows how to provide good customer service.

          But he'll have to quit the insubordination before anyone considers promoting him to managment. And I think that's the real "moral of the story", as they say. In the end, you have to do what the company asks, or you'll find yourself loo
      • Management were wrong here. A lot of programmers just want to provide high quality code that does what the customer wants. They're eager to please and they have pride in their work. They will go above and beyond because they want to produce things that work. This "don't do any more than the minimum" attitude demotivates. I agree that programmers shouldn't run screaming off adding expensive features that push the cost up, and if this happened a lot and had an impact on the business, I'd have a quiet word. Th

    • Re:hmmm, is there a missing party here? (Score:5, Insightful)

      by DrSkwid ( 118965 ) on Tuesday October 18, 2005 @08:08PM (#13822732) Journal
      Your manager was right on both counts.

      1) Although you know how long it will take you, you do not know how many other projects will be multiplexed into your time. It is your manager's job to decide how long it will take you to complete a task for a client, regardless of how long it will take you.

      2) You gave away your time for free, you released code without authorisation which is added risk to your employer.

      • 3) He implemented a fix to an old system that wasn't spec'd in the job, when his manager might have had another (possibly more important/lucrative) job waiting for him to do when he was done with the first job.
      • Yet it is pretty clear that management didn't outline the rules and responsibilities and instead of doing so "took him to the room". That isn't management, that is freaking out *after* the cat is out of the bag. Real management would have never allowed un-reviewed code out of it's hands nor would it have sent someone to a meeting without ground rules.

        Both sides suffered failures, but management is supposed to, you know, manage these things and not blow up at the apparently unmanaged employee.
        • Yes, you're right. I didn't outline the failure of the manager's responsibility to his employee in that situation.

          Being angry after the fact and expressing that at an employee is mismanagement. Hurting an employees feelings in that way is just not fair. It sounds like the OP is actually a good worker and as such should have his skills nurtured and chalk such minor mistakes up to experience instead of getting all shouty. That he ended up posting here means they didn't even talk about it properly !

        • Real management would have never ... have sent someone to a meeting without ground rules.

          Sure, but isn't a basic level of common sense and awareness part of the job any more? Would you expect a manager to have to tell a senior developer before each customer site visit to remember to be polite and turn up well-presented? Of course not. Granted, it's smart management not to make unnecessary assumptions, so you might mention that as a "friendly aside" to the rookie guy the first time, because he's a rookie

      • This is a weirdly circular argument. The people arguing for management are essentially telling you that you're doing this work for your manager. In other words, your manager is your customer. Your manager is also telling you that its OK for a supplier to (a) do the minimum, (b) bill more for work than it actually cost, and (c) it's never OK to do work for free.

        In other words, the manager is telling you on one hand that it's not ok for you to shaft your customers (him), but it's ok for him to shaft his cu
        • It's not about doing the minimum, overcharging or doing work for free.

          It is about your company deciding what they will do, you are there to perform the tasks, the manager is there to manage when and what you work on.

          It's not about making a job stretch in order to charge more. Lets assume the job will take 5 days work. During those 5 days all sorts of things can happen that may disrupt things. What if you are ill for a day, or your terminal breaks or a critical bug appears in some old job and you're the best
          • I agree with what you're saying and in the situations you describe, you're right. However, the tone of the parent was one of "Don't do extra work, even if it's required, because we can charge more for it later on." There was also an implied assumption that the manager was padding estimates so they could charge more. If this is standard practice, (and I have no reason to believe that it is not), then a company can hardly complain when programmers use the same techniques to "maximise" revenues earned from th
        • In other words, the manager is telling you on one hand that it's not ok for you to shaft your customers (him), but it's ok for him to shaft his customers (the end user)

          Screw 'em. Do your job the way you want to do it. Never feel guilty about making money for doing the least amount of work. Don't worry about doing work for other people on your bosses time. Within the context of your contract, sell the work you do to as many people as you can.

          The problem I see with this line of thinking is that it ruins you,

    • atrocious management (Score:5, Interesting)

      by mosel-saar-ruwer ( 732341 ) on Tuesday October 18, 2005 @09:45PM (#13823337)

      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

      RULE #1: We never promise a deadline to a client unless we first clear it with accounting.
      REASON FOR RULE #1: Time is money, and if we haven't generated enough billable hours this month, then we're gonna need to generate more [not fewer] billable hours. Welcome to the real world, kiddo.

      RULE #2: We never give away free code unless we first clear it with accounting.
      REASON FOR RULE #2: Code is money, and if we haven't sold enough code this month, then we're gonna hafta sell more [not less] code. Welcome to the real world, kiddo.

      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.

    • Clearly you knew what you were doing... this time.

      IFF you can do this 95% of the time then obviously the smart thing to do is find yourself a salesperson and go into the consulting business doing this type of work.

      As soon as you have to start paying the salary for the salesperson, the overhead of running your business and doing the tapdance of handling more than one client at a time while simultaneously trying to land more work for the near future you will probably understand exactly where your boss was co

    • It is one thing to know how long something will take, but delivering features should be a business decision.

      When you say you can do something, and they agree it would be nice, the proper response is "Settle the price with my boss and I'll get right on it." Given your experience with then original meeting you should then secretly write down on paper your time estimate so the boss has a clue how to bill.

      Actually this isn't correct yet. Before the meeting you tell your boss that you can do something and

      • Your job is to write code. Not make your manager look good. While deliverables and timeline should be ironed out between management and client. riding coattails is only for those who want to go into management, and only happens at higher levels. *If* the poster wants to do that, he needs to make himself look capable, not his manager.

    • I have to say that I personally disagree with all of the people that said "your manager was right." Right about what? Taking care of your customer? Working with them as a human being and giving them 110% instead of just being a drone? Customers love that. They find you a pleasure to work with, they were surprised by the results and how your company met their needs better than they thought. Guess who has money? The customer!

      A happy customer is a returning customer. They're also more willing to recom

      • There's a difference between taking care of the customer, finding out what they want and all that, and going out and giving them freebies. Obviously the customer will love you if you give them freebies, but *your* company will crash and burn. And guess what, it's *your* company that pays you.

        Grab.

    • Re: Going the extra mile (Score:4, Interesting)

      by some guy I know ( 229718 ) on Wednesday October 19, 2005 @02:39AM (#13824513) Homepage
      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.
      • My major objection to the GP post was that he gave an estimate on the spot. That is something all of my guys are schooled NOT to do on the occaisions they do talk to clients. There are several reasons for it, among them are:

        Any non-trivial project needs to be reviewed to make sure that nothing was missed.
        I run their schedule. It's nice that you can get this done in 2 weeks, but we already promised client Z that we'd have this other thing done by t

        • Re: Going the extra mile (Score:4, Interesting)

          by yagu ( 721525 ) * <yayagu@[ ]il.com ['gma' in gap]> on Wednesday October 19, 2005 @10:59AM (#13826679) Journal

          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.

          • Your Manager was an ass.

            I've been lucky, most of the time I work with the customer directly, they have far more work than I can ever get done so things are simply prioritized and I do what's next on the list. I don't have to worry about a Manager demanding a different estimate from me than what I would say to the next person in the chain.

            But I have seen instances of exactly what you describe.

            As for customer expectations, here's my story:

            I was once asked to go to a meeting with a client, one for which I did
            • I've been lucky, most of the time I work with the customer directly, they have far more work than I can ever get done so things are simply prioritized and I do what's next on the list. I don't have to worry about a Manager demanding a different estimate from me than what I would say to the next person in the chain.

              Ah, but usually it's not that simple, someone has to bridge the gap between engineers or techies, and management or marketing. After reading all these comments here, I'm starting to suspect those

  • Your organization is fscked. (Score:3, Interesting)

    by p2sam ( 139950 ) on Tuesday October 18, 2005 @07:36PM (#13822471)
    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. :)
    • I agree. If your direct manager was doing his job properly, you should never have to talk to upper management. Then that solves the problem. Why are you stressing because someone else isn't doing what they are supposed to do? Explain to your manager that his job is to buffer all the political BS, so that you can do your job. Do what he tells you to do, and if upper management ever questions you, you tell them "I was doing what I was told, if you have a problem with it, talk to my programming manager."
      • Explain to your manager that his job is to buffer all the political BS, so that you can do your job.

        hehe... Ahehhehe... AHAHAAHAHAHHHAHA!!!

        Explain to your manager! That's a good one!
        • Yes, exactly. You go to his office and tell him you're getting mixed signals, and please straighten things out. Then when the higher level manager asks you again, you tell him the same thing. They work it out. If they don't, ignore both of them and do whart you think needs to be done. If it doesn't meet their expectations, its their fault.

    • Honesty and Forthrightness. (Score:4, Insightful)

      by mosel-saar-ruwer ( 732341 ) on Tuesday October 18, 2005 @09:26PM (#13823233)

      Nuttles1: ...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...

      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

      Dick Weed
      dickw@uppermanagement.acme.com

      Brown Knows
      brownk@middlemanagement.acme.com

      Then your emails would read like:
      TO: dickw@uppermanagement.acme.com;brownk@middlemanage ment.acme.com

      SUBJECT: Conflicting priorities

      BODY: In re: the new feature set that was promised to the client - I can probably "make" the deadline of Friday the 13th, but I'm gonna hafta break a lotta rules, and write some pretty darned ugly spaghetti code, and I would definitely be cheating on those ISO 9000 standards that we were trying so hard to adhere to.

      It's your call.



      • I have learnt to avoid giving management choices like "either this or that but not both". Most of the time, they'll try to get you to do both. :)
        • They'll definitely try - that's their job. Your job is to tell them that it isn't possible. And make sure that it's documented in an email that it isn't possible. If they tell you to do both, send an email back (and CC'd to boss's boss) saying that it isn't possible.

          Grab.
          • You're assuming here management will believe you when you say "it's not possible", or that they'll accept simple facts like documentary proof that it's their fault. This is a bad assumption.

            In my experience, non-technical managers tend to have a mysteriously selective faith in developers - namely that:

            1) We can simultaneously do an unlimited number of things in an ever-decreasing timespan with no loss of quality, and
            2) Our own estimates of "time to complete a job" are always inaccurate to the point they ca

  • Uh, welcome to the world of business? (Score:5, Insightful)

    by WebHostingGuy ( 825421 ) * on Tuesday October 18, 2005 @07:37PM (#13822484) Homepage Journal
    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.
    • This is not so much a programmer problem but just a business problem; also known as a people problem. [...] There is no right or wrong answer only the relationships you have to deal with.

      I agree that this is a people problem, but I think there are specific solutions that work well in programming environments. Personally, I'm pretty happy with the planning approaches I've stolen from Scrum and Extreme Programming:
      • Get everybody who wants work out of you together for a meeting
      • Break the work down into independ

  • Use hierarchy to your advantage (Score:5, Interesting)

    by Mark of THE CITY ( 97325 ) on Tuesday October 18, 2005 @07:38PM (#13822491) Journal
    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.

    • Better yet, ask your supervisor to help you with this. Your supervisor should instruct the more senior managers to bring all of their issues and concerns to him/her. It's their job to shield you from this type of thing.

      If that doesn't work, politely ask the senior managers to discuss their concerns with your supervisor. Tell them that you cannot work efficiently in an environment where you get conflicting direction.

      • This is an example of why middle management gets hit in budget cuts. It sounds like the supervisor has different priorities than senior management. If this is creating a situation where the senior management's goals are not getting implemented on time, the problem lies with the middle manager.

        You can either try to help your manager learn how to do his job, or you can recognize this as an opportunity for a promotion. Very few people get fired for being responsive to the needs of their boss's boss. This c

  • How To Deal With It (Score:5, Funny)

    by RealityMogul ( 663835 ) on Tuesday October 18, 2005 @07:46PM (#13822551)
    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.
    • "another job that has smart people in charge"

      Does this exist?!?!?
      • If you're self-employed.
      • It's rare, but it happens. There are fairly smart people in charge where I work. Of course, I may be biased because they listen to me on technical issues. =)

        The most important thing to me is working with people I get along with. My boss is a programmer and easy to work with. There is another director and VP I work with frequently who are business people with little technical experience. They know the part I'm not interested in (business side) and I know the part they're not interested in (technical), s

  • Several things to consider (Score:3, Interesting)

    by Geshem ( 901676 ) on Tuesday October 18, 2005 @07:49PM (#13822584)
    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).

    • Re:Several things to consider (Score:4, Insightful)

      by Osty ( 16825 ) on Wednesday October 19, 2005 @02:30AM (#13824480)

      * "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.

      That's not necessarily true. At least, not the way you explain it. Deadlines can be real "dead lines", in that if you miss the deadline you're dead (or your project, anyway). However, don't forget that time (deadlines) is just one part of a triumvirate of quality, time, and features. If time is fixed (you're on a contract with a specific end date, you've publicly promised to ship on a certain date, a different team has publicly promised to ship on a certain date and your project is a requirement for their shippnig, etc), then something else has to give. Enlightened managers will cut features in favor of quality. Unenlightened managers will cut quality in favor of features. The only way to deal with this as a front-line developer is to make sure you're getting pressure from only one place -- your direct manager. If your manager's manager is dictating something else, you have the right to tell him or her to go through your own manager (in a diplomatic sort of way, unless you like being on the shitlist). Of course, you can go the other way, too. If your manager is setting unrealistic goals, or is damaging the project (focusing on features instead of quality), you can and should go to their manager and discuss the problem. Either way, you can't perform two contradictory actions at the same time, so you need to speak up.

      * 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 must not work in the commercial world. Looming deadlines and a list of promised features often means you have to sacrifice some quality. Usually you'll do so with the intention of cleaning it up in V.Next, but the vicious cycle of less time and more features conspires against you. The best you can do is argue in favor of doing things right, or at least taking some time to do a postmortem to evaluate why quality had to be cut and try to get time to clean things up. That's a problem with shrink-wrapped software, though, because nobody's going to buy a new version just because you cleaned up the architecture (assuming the previous version works well enough already). So you're back into doing features rather than fixing brokenness. While it sucks, you can at least take some solace in knowing that you wanted to do the right thing but couldn't because of someone higher up the chain.

      * You should always please whoever controls your future (but first, yourself).

      In the broadest sense, you control your future. But more pragmatically, it's really difficult serving two masters. You'll be happier and better serve your career growth by using the chain of command to work for you. Make sure you're only taking tasks from your direct manager, and don't accept any tasks that didn't come down that chain. There are times when you can and even should take tasks from people other than your manager, but when crunch time is on and it's a Do or Die situation, funnel those requests.

      Finally, evaluate why there's no time to do things right. Are you giving bad estimates? Are your estimates being changed by others besides you (people who aren't going to do the work)? Are your estimates assuming a perfect working environment? (if so, adjust your estimate to include context switching time to deal with interruptions, or lobby for "dark days" where you can turn off email, shut your door, and stop any interruptions so you can get a full day's work done.) Maybe you can change some things. Maybe you need to change your own view. Maybe you need to change jobs.

      • 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 must not work in the commercial world.

        On the contrary. IME, people/organisations that truly understand the value of good design and best practices are usually very successful in the commercial world. This is precisely because if you take a longer-term view and keep your house in order, even taking a small hit in the short term to do it, then in the long t

  • When you've made everyone happy... (Score:3, Insightful)

    by billybob2001 ( 234675 ) on Tuesday October 18, 2005 @07:50PM (#13822591)
    ...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.

  • Bill Cosby said it best (Score:5, Interesting)

    by Pyromage ( 19360 ) on Tuesday October 18, 2005 @07:51PM (#13822600) Homepage
    "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.
    • Best advice ever.

      Usually you want to please your direct supervisor. If you do what he likes, the only person with direct knowledge of your work says good things about you. If you don't please your bosses boss, it's not you that will be taking heat.
      • If you don't please your bosses boss, it's not you that will be taking heat.

        Not always true. I managed to please my boss (despite not having "the numbers", because I did good work and worried about making things work right, rather than checking off boxes), but when the 4th round of layoffs came around, my Boss's boss called me to tell me I was laid off. Of course, he called my boss just before that...

  • The Three Programmer's Virtues (Score:5, Insightful)

    by Linux_ho ( 205887 ) on Tuesday October 18, 2005 @07:53PM (#13822613) Homepage
    You don't need anything else. Pay special attention to the last virtue. It's middle-management's job to provide upper management with a realistic schedule that allows time for a quality implementation. If upper management questions you directly, tell them they can have any two of these options: (A) fast, (B) cheap, (C) good. Chances are, they will understand that a quality implementation takes more time. If they choose (A) and (B) anyway, start resume polishing, the company probably won't be around long anyway.
    "We will encourage you to develop the three great virtues of a programmer: Laziness, Impatience, and Hubris."

    LAZINESS: The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don't have to answer so many questions about it. Hence, the first great virtue of a programmer.

    IMPATIENCE: The anger you feel when the computer is being lazy. This makes you write programs that don't just react to your needs, but actually anticipate them. Or at least that pretend to. Hence, the second great virtue of a programmer.

    HUBRIS: Excessive pride, the sort of thing Zeus zaps you for. Also the quality that makes you write (and maintain) programs that other people won't want to say bad things about. Hence, the third great virtue of a programmer.

    - _Programming Perl_, p. xiv, by Randall Scwartz & Larry Wall

    • If upper management questions you directly, tell them they can have any two of these options: (A) fast, (B) cheap, (C) good. Chances are, they will understand that a quality implementation takes more time. If they choose (A) and (B) anyway, start resume polishing, the company probably won't be around long anyway.

      That's often not true in today's capitalist, commercial world. The fact that good managers realise this, and may make a decision to go with (A) and (B) under some circumstances even though the d

    • ...tell them they can have any two of these options: (A) fast, (B) cheap, (C) good. Chances are, they will understand that a quality implementation takes more time. If they choose (A) and (B) anyway, start resume polishing, the company probably won't be around long anyway.

      I guess you haven't been developing software too long. Companies always always always pick A & B. Always. Examples? Take a look at most shrink-wrapped software out there. Internal enterprise software has bugs as well.

      Why? People (a

    • tell them they can have any two of these options: (A) fast, (B) cheap, (C) good. Chances are, they will understand that a quality implementation takes more time.

      I don't know where you heard of A, B, and C but I think you have the concept mistaken. The three typical competing priorities in a software project are the following:

      • Schedule
      • Functionality
      • Cost/Resources

      You may notice that quality is NOT a variable. That isn't to say that software professionals shouldn't care about quality. Rather, quali

  • Get them together (Score:3, Funny)

    by dtfinch ( 661405 ) * on Tuesday October 18, 2005 @08:05PM (#13822705) Journal
    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.

    • Exactly (Score:3, Interesting)

      by JavaRob ( 28971 )
      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

  • Welcome to hell! (Score:2, Informative)

    by Ledfoot ( 75412 )
    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 th

  • Hi Peter! (Score:5, Funny)

    by Cthefuture ( 665326 ) on Tuesday October 18, 2005 @08:14PM (#13822766)
    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.

  • Honest self assessment time (Score:3, Interesting)

    by heinousjay ( 683506 ) on Tuesday October 18, 2005 @08:25PM (#13822833) Journal
    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.

  • Wrong Question Your purpose is to make you happy (Score:5, Insightful)

    by Crashmarik ( 635988 ) on Tuesday October 18, 2005 @08:27PM (#13822850)
    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.

  • In real life, how do programmers handle this situation?

    You deal with it the same way anyone else with a job does: you learn to set, and meet, proper priorities.

    An employee's job is to satisfy your manager's expectations that you are fulfilling your duty within the organization. This is true for anyone with a job, no matter what that job might be -- programmer, sysadmin, manager, garbage collector, whatever. It's true for anyone with a boss -- and pretty much everyone has a boss, whether it's a manage

  • You have bad managers (Score:3, Insightful)

    by Metasquares ( 555685 ) <slashdot.metasquared@com> on Tuesday October 18, 2005 @09:11PM (#13823141) Homepage
    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 :)
    • "Never attribute to malice that which can be adequately explained by stupidity."

      The bosses are not bad, they are just disorganized. They appear not to know what each other want. They each have a different view of that triangle, and they are each trying to lay that view on you.

      The upper level management are going directly to you when they should go through your boss. If they do, they are breaking the chain of command that they themselves hold so dear.

      Correct them. Tell them to find your boss and tell him

  • The project can always afford to slip a little bit (Score:4, Interesting)

    by cgenman ( 325138 ) on Tuesday October 18, 2005 @09:14PM (#13823162) Homepage
    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!

  • Check it out [dreamsongs.com].
  • let's just say, dead people don't have expectations..

    (dramatic) *DUN DUN Dunnnnnnnnnnnnn*
  • This is the first good "Ask Slashdot" I've seen in a long time.

    I wish I had an answer to give you. Since your immediate supervisor is a programmer, just try to level with him and keep pleasing his superiors. Hopefully he'll remember having to cut corners and crash a project... if not, maybe he was kicked upstairs because he couldn't meet his deadlines....
  • 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...

  • do what your supervisor tells you (Score:2, Informative)

    by Anonymous Coward
    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 wri
  • "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."

    Simple, do as your immediate supervisor tells you to do. It's his job to worry about what the upper management says, to worry about the deadlines, to worry about budgets, to protect you from upper management interference and stupidity.

    Yo
  • I would say that your direct superior has the responsibility to make the case to upper management that code quality matters (I would agree with his priorities, in fact!). This is, after all, the supposed point of a management hierarchy.

  • A Kent Beck quote (Score:3, Insightful)

    by Beek ( 10414 ) on Tuesday October 18, 2005 @10:53PM (#13823680) Homepage
    From Extreme Programming Explained:
    If you have six weeks to get a project done, the only thing you control is your own behavior. Will you get six weeks' worth of work done or less? You can't control others' expectations. You can tell them what you know about the project so their expectations have a chance of matching reality. My terror of deadlines vanished when I learned this lesson. It's not my job to manage someone else's expectations. It's their job to manage their own expectations. It's my job to do my best and to communicate clearly.

  • Where's the product manager? (Score:3, Insightful)

    by skybrian ( 8681 ) on Tuesday October 18, 2005 @10:58PM (#13823720) Homepage
    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.

  • Perfect interview question (Score:4, Interesting)

    by kbielefe ( 606566 ) <karl.bielefeldt@gma[ ]com ['il.' in gap]> on Tuesday October 18, 2005 @11:00PM (#13823730)
    It can't really help you now, but this is the perfect question to ask the next time you are changing jobs. You know the part where they ask, "Do you have any questions?" They actually mean it.

    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.

  • Another blurb from another pro business app dev (Score:3, Interesting)

    by RingDev ( 879105 ) on Tuesday October 18, 2005 @11:36PM (#13823909) Homepage Journal
    Number one montra in business application development. "I'm doing this for the user"

    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 .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.

    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 [ringdev.com]
    http://ringdev.com/code/GFCNamespace.gif [ringdev.com]

    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

  • How do programmers handle this situation? (Score:3, Funny)

    by Crimsane ( 815761 ) <clarke@nullfs.com> on Wednesday October 19, 2005 @12:15AM (#13824044) Homepage
    We drink.
  • I was a professional developer for seven years, and I've got three words for you:

    Get Out Now.

  • My wife saw it instantly (Score:5, Insightful)

    by ancientt ( 569920 ) <ancientt@yahoo.com> on Wednesday October 19, 2005 @02:44AM (#13824525) Homepage Journal

    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.

    • It depends on how much you're willing to look for a new job. I got to the point where I was looking for a new job anyway, so there was little risk in taking a more confrontational position. I ended up with my boss wanting to fire me, but his boss not letting him. I doubt many people get fired for doing what's important to their boss's boss.
  • Given you indicate your deadlines are inflexible; time is a constant and can only be considered top priority. I wouldn't even call it a priority, but a requirement, as it is something which cannot be compromised on.

    This leaves only the features/quality priorities to be listed; let your managers battle it out together. I dare bet that "features" will be top priority, since that's what customers pay for.

    In my job we have such priorities too; listing quality first, features second and time third. When it all c
  • Ah young Grasshopper,

    You have now reached a maturity level in your career where you will be able to read books like 'The Mythical Man Month' and understand them. With that book, you will first be shocked by the fact that someone has written so clearly on these issues, and then you will be shocked to find out he wrote it most likely before you were born.

    Read the following books, in the following order:

    The Mythical Man Month
    The Rise and Fall of the American Programmer
    The Pragmatic Programmer
    Af

  • Educate your manager... (Score:5, Insightful)

    by JazzManDRP ( 158742 ) <slashdot@puz e y .net> on Wednesday October 19, 2005 @05:39AM (#13824971) Homepage
    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.
  • The problem is not a technical one but rather business. What's helped me more than anything was learning to negotiate. I'd recommend "Secrets of Power Negotiating" by Roger Dawson [rdawson.com] which you can probably get from your local Library (I prefer the audio cassette series).

  • Easy (Score:2)

    by smileyy ( 11535 )
    Abortions for some. Tiny American flags for others.
  • Is to help you understand the real-world constraints you are operating under, and then protect you from being further bothered by senior management. It sounds like he is not doing either one.

Slashdot Top Deals

BLISS is ignorance.

Close