Forgot your password?
typodupeerror

Smart Software Development on Impossible Schedules 225

Posted by CowboyNeal
from the man-hours-and-myths dept.
Andrew Stellman writes "Jennifer Greene and I have an article in the new issue of Dr. Dobb's Journal called "Quick-Kill Project Management: How to do smart software development even when facing impossible schedules." We got a lot of great feedback from our last article on open source development, but there were a bunch of people who wanted to know whether it was really feasible to do planning and reviews on a tight schedule. That's a fair question, and this article is meant to be an answer to it. We pulled out bare-bones project management practices that will help you protect your project from the most common and serious problems, and gave instructions and advice for implementing them that should work in a real-life, high-pressure programming situation."
This discussion has been archived. No new comments can be posted.

Smart Software Development on Impossible Schedules

Comments Filter:
  • Tried and true (Score:4, Insightful)

    by Anonymous Coward on Friday July 07, 2006 @12:17AM (#15673221)
    Just make your developers pick up the slack by working lots of overtime.

    • Re:Tried and true (Score:4, Insightful)

      by Aceticon (140883) on Friday July 07, 2006 @09:36AM (#15674773)

      Just make your developers pick up the slack by working lots of overtime.


      A couple of points:
      - If you don't have a clear vision of what the software is suposed to do and how to get there, having people work 10h/week or 80h/week produces exactly the same result - you get nowhere - either the project is late and gets canned or what you deliver is not accepted because it doesn't match the expectations of the customer.
      - Long hours => tired developers => a lot more bugs => much more time is needed to implement the same features => long hours. Unless long hours are restricted to a couple of days, the end result is a vicious circle where removing the extra bugs introduced by tired designers/developers ends up consuming more time than whatever extra time you got from those extra work work hours.

      Making people work extra hours gives the appearence of getting more work done while reducing the actually amount of work that does get done. This is one of those management techniques that sites high up in the list of "Things that managers that have no sense of strategy do", right above measuring productivity by "lines of code written" instead of by "requirements features implemented".
  • by gasmonso (929871) on Friday July 07, 2006 @12:21AM (#15673234) Homepage

    In the real world, no amount of tips and tricks is going to make up for a bad schedule. We end up doing code reviews while are software is in verification and validation. Is that smart? No. But when you need to get features done, that takes priority. As for documentation, that always falls to the wayside as well. The truth of the matter is this. The only way to make schedule is to totally inflate your time estimates on the project. We developed a rule of taking the engineers estimates and double them. Of course we're still running a little late ;)

    http://religiousfreaks.com/ [religiousfreaks.com]
    • by AuMatar (183847) on Friday July 07, 2006 @12:38AM (#15673292)
      I don't disagree that tricks won't help you. I do disagree that getting features done should take priority. If you don't take the time to do things right, it will bite you in the end, either in debugging or maintenance, and likely take longer than doing it right in the first place.
      • by Baddas (243852) on Friday July 07, 2006 @02:31AM (#15673618) Homepage
        The problem, in general, is that often the need for an application is immediate, while maintenance is a later problem.

        In otherwords, the future value of 'doing it right' is lower than the immediate value of 'damn the torpedoes' and getting it done. (unfortunately)
      • by gutnor (872759) on Friday July 07, 2006 @06:52AM (#15674108)
        Unfortunatly developers knows that very well. But features takes priority because they are the only reason why you get some budget to develop.

        Some companies works with a sick "problem bringer"/"problem solver" mantra. Removing feature to allow you developping beter code invariably put you in the "problem bringer" section and that is bad.
        On the other hand, putting all the features = "(management) problem solver".
        When the application crashes in production and the situation looks very bad for the manager, if you come with any way of cleaning the mess you are again a "problem solver".

        Every time you remove a feature or refactor the code preventively, from a management perspective you move 1 step in the dark side of the force, so you must handle that with political gloves, not common sense ( i.e. use fear factor, find tactical advantage for your manager not to include a feature, sneak "cleaning" code into features your manager think are worth extra-time to be able to cut budget later on a refactoring, ...)

      • by MickDownUnder (627418) on Friday July 07, 2006 @08:15AM (#15674346)
        "...take the time to do things right...."

        It's this notion that not going off and making a total ass over end cock up of a project, and "taking the time to do things right" that is really the problem with allot of developers, and managers attitude to software development.

        The quickest way to get a project done is to do it right ONCE! Not five times badly. At developer meetings I've often heard managers or developers call UML and other methodologies a waste of time or unnecessary, it always flabbergasts me to hear such ignorance.

        I've been in a situation where an (un)manager told me "We don't have the time to do document and do things the right way", my response was "No, we don't have the time not to do things the right way". We only had 6-8 months to get a large project out, with four programmers, a business analyst and two DBA's. I was told I wasn't to spend time in UML and documentation land, and you know what, I ignored him and spent 3-5 days creating high level class diagrams and interaction diagrams, the core of which lasted us through the entire project.

        Any project that you forecast is going to take longer than 3 man weeks ie 120 hours needs some sort of design in place to ensure that the major architectural constructs are already decided before coding takes place.

        The key to employing methodologies in projects successfully is unfortunately experience. It takes experience to use methodologies successfully, it takes experience to create good designs for applications and to judge when a design has become mature enough to allow development to commence without the risk of major refactoring later on in the project.

        It does in fact take time to acquire this experience (years in fact), but it does not take time to employ this experience once it has been acquired. If you feel like your project needs some sort of methodologies in place, but "you don't have the time", the answer is simple, it's not that you don't have the time, you don't have the right personnel. It's true if you have no one with the experience of delivering the architecture required in a professional and timely manner then taking on methodologies new to everyone on the team is going to take time and lots of it. A good manager however will make sure that the project is correctly resourced.
        • If you feel like your project needs some sort of methodologies in place, but "you don't have the time", the answer is simple, it's not that you don't have the time, you don't have the right personnel. It's true if you have no one with the experience of delivering the architecture required in a professional and timely manner then taking on methodologies new to everyone on the team is going to take time and lots of it. A good manager however will make sure that the project is correctly resourced.

          Unfortunately

        • Any project that you forecast is going to take longer than 3 man weeks ie 120 hours needs some sort of design in place to ensure that the major architectural constructs are already decided before coding takes place.

          I agree completely that one should spend time making sure the design is right. But I disagree that it should all happen before starting coding. You will never know less than at the beginning of the project. Improving the design should be a continuous process; then you get to take advantage of new
    • We would take the estimates, double them and add 30%, that is how I bid out all work. Now... The challenge is when you, the lead developer do not control you schedule and you are having meetings twice daily to discuss the progress. In that situation, well, it doesn't matter what the WBS says, or whether or not there is a code review, it matters that the features get done. Granted that is the anomolay for me, when it does happen, the goal is to get done and get out as quickly as I can.

      Is that the norm or the
      • by fbjon (692006) on Friday July 07, 2006 @05:59AM (#15674023) Homepage Journal
        the anomolay
        Something like blind sex, I presume?

        ( -> anomaly)

      • by Anonymous Brave Guy (457657) on Friday July 07, 2006 @08:27AM (#15674399)

        We would take the estimates, double them and add 30%, that is how I bid out all work.

        It's interesting to look down this thread and see how many different rules of thumb are employed, apparently by quite experienced developers/managers.

        It seems to me that we can make two reasonable assumptions based on this:

        1. Development usually takes longer than most engineers estimate up-front.
        2. No-one has yet found a reliable way to assess how much longer up-front.

        One might hypothesise, based on these assumptions, that any project plan that quotes hard figures up-front will be inaccurate most of the time, and without allowing a huge defensive overhead that inaccuracy will often be in the wrong direction.

        Now, working from unreliable estimates is in no-one's interests. If a company overestimates by too much on a fixed-price contract, it risks being undercut by a more realistic competitor. If it underestimates, it will look bad when things over-run, its profits will fall, and its reputation will suffer as well.

        So what conclusions can we draw from this?

        Firstly, if we're looking for realistic management, the way to go is almost always some sort of time and materials contract, with floating deadlines based on when features are actually ready. This allows good developers to do their job properly, which in the long run will be more efficient, and it means that other groups such as sales, marketing and customer support can be kept informed and given realistic expectations.

        Secondly, fixed-price contracts are only a good bet for a software development firm if it can include enough slack to be safe, without including so much that it can be undercut by more realistic competitors. The corollary, of course, is that if you're a client, you're almost inevitably going to be screwed by agreeing to a fixed-price contract, even without considering the lack of flexibility it entails.

        It is a rare project indeed that truly requires hard deadlines. Smart clients and smart development shops will reach a more flexible arrangement, and come to respect each other for having realistic expectations and providing realistic updates as time goes on.

      • We would take the estimates, double them and add 30%, that is how I bid out all work.

        An easier approach is to measure progress.

        Divide your project into microfeatures, deliverable units of work that are either done or not done and take less than a week to build. Estimate each microfeature on a simple complexity scale (I like 1/2, 1, 2, 4; anything above 4 gets split into smaller features).

        Then just start in developing and see how many units of work get done each week. Even a manager can see that if you got 5
    • by Morris Schneiderman (132974) on Friday July 07, 2006 @01:30AM (#15673459)
      We developed a rule of taking the engineers estimates and double them. Of course we're still running a little late ;)

      Of course you're running late.

      Let me guess - you're a young pup. It's always been the same, since the dawn of history. Every generation laments that succceeding generation has to make the same mistakes, and learn the same lessons, over and over again.

      IBM solved this estimation problem back when dinosaurs roamed the earth, virtually all computers were made by IBM, and they came with a "free" (as in beer) systems engineer.

      IBM's solution was that every level of management that had to review an engieer's estimate would triple the estimate of the person who reported to (almost invariably) him. So, if the estimate required two levels of managerial approval, the quote to the client was 9 times what the engineers figured it should be. If three levels of approval were needed, the official estimate was 27 times what the engineers came up with. Now you know how IBM was able to afford that "free" systems engineer with every computer.

      Actually, there are ways to drasticly increase the likelihood of success on "mission impossible" projects. I successfully led an EDI implementation project where there was no spec, no data, no customer, no access to the computers, the programming had to be done in an obscure language, and there was an arbitrarily set deadline of three weeks. Sometimes you take on such projects because you want to stretch yourself. But that's a story for another day.

      • by hackwrench (573697)
        What's so irritating is that the previous generation pretends that they've known the lessons all their life and takes them for granted, begs the question as to the right way, and any other similar sins of... what sort of sins are these anyways?

        Oh, and none of them come up with a cure to the problem, but insist that doing it their way is the cure.
    • by fprog (552772) on Friday July 07, 2006 @01:51AM (#15673521)
      Seriously, doubling the time is NOT enough.

      Top 12 - Rule of thumb says:

      1) Triple the estimated time + 10%.

      2) Add 2 weeks to that amount for a complete code review.

      3) Any changes by the customer means "adding 2 weeks to the schedule", even if it's one line of code... why? because, it must pass documentation, Q.A., validation and be reviewed by the entire department, without accounting for "double bug", bug induced by another bug and stuff like that or bugs that are in the core library and means retesting "everything", "every module", etc.

      4) Any changes must be approved, reviewed and means adding delay (normally a big NO-NO) and therefore, 99% of the case thoses changes are left for future phases or abandonned by the client when they realise the implication. If not, it's your objective to discourage them or force them to reconsider by any means. =P

      5) Don't give any feedback to the customer unless you must! If you do, downgrade any progress to minimum to reduce expectation and refrain the customer from adding new stuff to the TODO list.

      6) Which means, each phase must be clear, consise, humble, realistic, feasible, with lots of buffer time for fixes, reviews and testing. Exagerating how complicated it is to a customer is always a good idea, because in the end, everything that seems easy is actually very difficult.

      7) Do minimum documentation, UML to get started... They'll get rewritten at least 30 times, before everyone in the group agrees after what 40 meetings?

      8) Once the phase somehow works and the thing is somehow settle, start documenting it, so you don't forget. It's actually a very good way to detect logical mistakes, misbehaviors, bad coupling, bad cohesion, missing corner cases, bad design choices, usability problems, etc.

      9) Best teamwork is small team of 3-5 senior people working toghether hand-in-hand, sometime helped by 1-2 junior, which can do much better than 120 junior who are completely clueless and never deliver on time...

      10) For big projects split things up in component and/or phases that a small team of 3-5 people can do, keeping in mind of the big picture so its scales up, but ignoring any meaningless future details that don't matter "right now".

      11) Rush the people to do it in "the simple 1/2 time delay", keeping in pocket the "double time" remaining for any arising issue and reworking the core libraries, overhaulin the code, reviews, fixing bugs, etc. This means that if you are really late, you are actually late on your "buffer time". If things goes well, then the project will be done before it's expected, which will impress any client.

      12) Finally, but not the least, there's no such thing as a bug, it's just a "small improvement", a "new feature", "code overhaulin", "mispelled requirement" or a "security enhancement". It keeps customer smiling, it's less depressing for everyone and overall keeps the mood up on everyone face with a laugh or two! ;-)
      Furthermore, no ones want to hear that the code is "full of bug", but saying that a group of people are always "enhancing, overhauling and improving the code base" also means bigger bonus! =)

      Hope it saves you from any future project delay or cost overrun!
    • We end up doing code reviews while are software is in verification and validation

      wow you do code reviews? My last employer dropped those over 3 years ago to "speed up the process"

    • We developed a rule of taking the engineers estimates and double them.

      I've found a more reliable estimation rule is to take the estimate, double it, and change units to the next larger (common) increment of time. E.g. 2 hours => 4 days, 5 weeks => 10 months.

    • From a cursory look at the article i got the impression that the "tricks" listed boil down to "doing what should've been done in the beginning during analysis".

      Starting a project without gathering requirements, scoping the project, hammering the list of business rules and doing a high-level design is a great way set the project up for getting out of control after a couple of months, even without the extra pressure.
  • Smart? (Score:5, Insightful)

    by qbwiz (87077) * <john&baumanfamily,com> on Friday July 07, 2006 @12:24AM (#15673249) Homepage
    It seems to me that if you have an impossible schedule, then you've already failed.
    • by EmbeddedJanitor (597831) on Friday July 07, 2006 @12:37AM (#15673288)
      The main problem with getting late is that everyone lies. People only admit to being late when things get really bad and by then everyone is stressed.

      Step 1: Admit being late as early as you can. If people start ranting, keep cool. Tell them that ranting won't fix it. The sooner you admit to being late, the sooner you can stop screwing around and start getting the project back on track.

      Step 2: Help management prioritise what they want and what can be delivered when and what options are available. If they want a product to sell, they'll need to make some compromises.

    • Re:Smart? (Score:5, Insightful)

      by Monkelectric (546685) <slashdot@monkele c t r i c . com> on Friday July 07, 2006 @12:41AM (#15673297)
      Thank you. As a Software Architect, I'd like to say you are 100% dead on. I can spot a deathmarch project from the next county, and they *ALL* begin with phrases like "The market window for this product is..." or "We have to complete this by XXX or we all die" or my favorite, "My research shows every month we don't have capability X we loose Y dollars."

      The appropriate response to any of these is "You should have proposed this project X months ago (where X is a conservative estimate."

      • Re:Smart? (Score:5, Informative)

        by g2devi (898503) on Friday July 07, 2006 @09:29AM (#15674724)
        I was in this position twice, in succession.

        In the first case, my company tried to break into the professional market (we were big in the education market) so we announced a major overhaul and several new new features. It was a fantastic vision but unfortunately the president made the mistake of announcing the full feature set and that we would start accepting purchase orders that summer. By the time spring rolled around it was clear that were were going to miss the deadline by several months (very bad when most of your sales are in September), but since the feature set was set in stone, we couldn't cut features. The writing was on the wall but we accepted it and started working 13 hour days nonstop for 6 months. Customer complaints over late orders flooded our phone lines and prevented our previous customers from calling tech support, so our old customers felt neglected and our new ones started cancelling orders. We gave up in christmas and released the complete but buggy product and got more complaints.

        The president was replaced, and under his leadership we were able to finish the product we wanted to finish within a reasonable schedule. Depite all the doom and gloom earlier, we survived. Unfortunately, we lost the senior software engineer and another developer in the process.

        Then, president hired a vice president which wanted to revamp the whole product and move it to an even higher market. I gave a detailed estimate that said it would take 2 years. The VP said we'd go bankrupt if we didn't release in 9 months. I repartitioned the estimate and said that we could do it in two stages, each 13 months long or three releases each 9.5 months long. No go. It had to all be done in one release, and that release could take no longer than 9 months or we might as well close up shop. I came close to losing my job over the issue, but since I was the most senior programmer there with the most experience about the product, the new senior software engineer told the VP if I went he'd have to give up too. 2 years later, after a complete turn over of the team twice (including the new senior programmer), the product was finally release It had more bugs than we'd like, but it was recieved well by the market so it was "good enough". At release time, I was the last person standing from the original team, but I had enough and left soon after. The product was well received but since the team was new, a new version of the product wasn't released into three years later.

        All the VP's threats didn't change an impossible schedule. You can't squeeze 2 years of work in 9 months, not matter how you try to force it. If you try, the most you can do is destroy your team and lose sales in the process. Most of those doom and gloom professies don't pan out. If they *are* true, someone is running the company wrong and development schedules are the least of your problems.

        In the later case, had the VP chosen either a more reasonable schedule (like any of the 3 I laid out above), we would have had most if not all of our original team at the end and been able to do subsequent releases at the same measured pace. We would have had regular sales and the company would have prospers much more.

        Being a software architect or project manager is hard, but ultimately, the best ones just lay out out all the credible options on the line and stick to their guns, even if it means risking your job. My experience in that job showed me that you can do it even in a hostile environment. If you lay things out properly and tell the truth, you may be resented, but you will be respected, even by those who chose to ignore your advice.

      • Re:Smart? (Score:3, Interesting)

        by dubl-u (51156) *
        I can spot a deathmarch project from the next county, and they *ALL* begin with phrases like "The market window for this product is..." or "We have to complete this by XXX or we all die" or my favorite, "My research shows every month we don't have capability X we loose Y dollars."

        I don't have a problem with that, really. The trick is to only give the suits levers you want them to pull. The deal I make with my clients is that I control the estimates and they control the scope. I estimate each feature; they d
    • Yes, but no specifically in regards to this article.

      What the article says is "when faced with impossible demands from management, do a quick but brutal project plan that shows what the actual realities are". I.E. blast through this and come back with what the real schedule is.

      I was disappointed that it didn't mention my all time number one schedule shortening trick though: lose features. Brutally. Slaughter the bastards. Keep slaughtering until someone says "but if it doesn't do that then what's the point".
  • Code reviews (Score:2, Interesting)

    by tcopeland (32225) *
    I was kind of suprised to see the recommendation for formal code reviews. In my experience those end up either as "hurt feelings" slugfests or, just as ineffectively, full of "you should put a space after this brace" comments. I feel that pair programming is more effective way of getting multiple eyes on the code, spreading knowledge around, training the new guys, and all that good stuff.

    And of course there's always static analysis [sf.net] to catch any problems that do manage to sneak in there...
    • Re:Code reviews (Score:3, Interesting)

      by bill_kress (99356)
      What kind of a group do you work in? Sheesh! Perhaps what you need is some training and a little maturity. Shouldn't any kind of suggestion be considered an oppertunity to learn? And when two teammates argue, there should be a lead/architect/manager that can tell which approach is better, at which point the decision (if it was really that tough) should be documented and added to your groups' coding standards.

      I'm not saying code reviews are the end-all be-all, but is static analysis really going to tell
    • Pair programming works well, but it can still lead to oversights and other issues. It helps to have a reviewer that has no personal attachment to the code, to get a truely critical review.
      Mind you, this can also be solved by picking appropriate people to pair with, and having the person not 'driving' being critical enough.
    • Re:Code reviews (Score:2, Interesting)

      by kiran_n (228321) *
      The problems you mention (as regarding formal code reviews) would tend to get compounded in pair programming - the main factor being - does the pair get along well enough to be able to work as an excellent team. Even if they can - you are really putting two resources where one (and some more) can get the basic job done. Pair programming is effectively replaced with a combination of good old fashioned mentoring and code reviews!

      --------------
    • Re:Code reviews (Score:3, Insightful)

      by cerberusss (660701)
      In my experience those end up either as "hurt feelings" slugfests or, just as ineffectively, full of "you should put a space after this brace" comments.

      Aye here. I've experienced this a number of times and started thinking about it. Generalizing a bit, most developers who like to do code reviews, like to do all sorts of things throughout a week (set up a build system, do some design, code a module, do some testing). However, these are exactly the same developers who often have trouble with the nitty-gritt

      • Re:Code reviews (Score:4, Insightful)

        by Anonymous Coward on Friday July 07, 2006 @02:52AM (#15673652)
        The message your coworker was giving you, that you missed, is, "Hey, this code is illegible! For starters, how about splitting up this monolithic function into something remotely comprehensible, and then maybe I could give you some useful feedback."

        No charge for the clue.
    • Re:Code reviews (Score:5, Interesting)

      by Bodrius (191265) on Friday July 07, 2006 @01:42AM (#15673490) Homepage
      Although I think pair programming can be great in many contexts, I think they really have mostly complementary advantages:

      a) An in-depth code review (formal or not) has a big difference from pair programming: the analysis is done by a fresh pair of eyes. Pair programming can result in two people who are too close to the code to detect flaws in their underlying assumptions.

      In my experience, code reviews are not that useful to detect syntax or style errors, nor do I think they're meant to be. That's the kind of thing you can automate with a tool anyway. If you're spending all your time looking for that, I agree most people will feel it is a waste of time.

      But code reviews can be extremely useful at a higher level: to detect design gaps and flaws in the implementation, or just get improvement suggestions that a fresh set of eyes ban provide, once you see the whole solution.

      Often the very process of explaining the whole solution top-down after implementation allows you to detect issues. Other times you can identify common patterns and needs in different features that we're not visible before ('hey, I had to do the same thing elsewhere and we have a common utility class/method for this that avoids this obscure bug here').

      b) I don't see how it should be that different regarding the attitude problems you are describing.

      If people get so easily offended by a code review, it seems to me it'd be because of team problems bigger than a code review process: either the programmer thinks their code is perfect (which is something to fear) or they don't trust their peer enough to have honest conversations about code.

      I guess this is the one advantage of pair programming, it forces people to work closely and practically guarantees that trust. But I do not think you need to lock two people in a room and do everything together for them to trust each other professionally in a healthy work environment.

      Heck, code reviews should be fun.

      They're peer conversations about code, and if you enjoy programming it should be fun to argue techniques and solutions with your colleagues, even (specially?) when there are strong disagreements. Both sides typically learn something from it; even if a lot of times it is not something you want or need to change in the current code, it will be useful knowledge elsewhere in the future. Just like college or academia, for that matter, back when coding was done for fun.

      • Re:Code reviews (Score:3, Interesting)

        by Bodrius (191265)
        After I RTFA'd, I realized I would agree a bit with you if code reviews were typically performed as described in the article, although for different reasons.

        They're not only suggesting a formal code review (with fancy printouts and email tracking and logs and supervision and lots of program management stuff). They're suggesting team-wide formal code reviews.

        Although they do suggest being selective about the pieces of code to review, and this can be very useful for very critical code, in most cases such a wi
    • Re:Code reviews (Score:3, Interesting)

      by Brandybuck (704397)
      1) Pair programming doesn't count for code reviews, because the "reviewer" is vested in the code.

      2) If your code reviews end up being "slugfests" and nitpick sessions, then you're not running them right.
    • Pair programming is the worst form of code review. I include the option of "absolutely none" in that statement. Not only does it devolve into that same slugfest in about 20 minutes, but the back and forth on even simple things causes it to be slower than just writing code, yet takes two people. And very few bugs are found in the process.

      A well run code review does not go into slugfests. I personally like how my company does it- we have a web based program that shows the effected files (with the diffs i
    • In my experience those end up either as "hurt feelings" slugfests

      The recipient of the review should in that case, grow up. Unless the reviewer is being unnecesarily nasty, in which case they should grow up.

      or, just as ineffectively, full of "you should put a space after this brace" comments

      Find or grow a code layout standard. Use it. debates on the topic should then run like this: "Minor differences to layout standards on lines 35 to 45", "Noted and will fix. Next?".
      For even more fun, find a code beautifi
    • Review checklist (Score:3, Interesting)

      by amightywind (691887)

      was kind of suprised to see the recommendation for formal code reviews. In my experience those end up either as "hurt feelings" slugfests or, just as ineffectively, full of "you should put a space after this brace" comments. I feel that pair programming is more effective way of getting multiple eyes on the code, spreading knowledge around, training the new guys, and all that good stuff.

      A good way to avoid pissing matches over brace indentation and other nits is to lay down a qualification checklist that m

  • Well if you are desperate or evil enough to not give a damn about keeping a well motivated and trained staff (which will reflect on the product) then by all means outsource it to other parts of the world, you will be a fool not to.

    /cut to the point.
    //If you start with an impossible schedule wouldn't that be a bad sign to start with?
  • Easy! (Score:5, Funny)

    by gillbates (106458) on Friday July 07, 2006 @12:31AM (#15673269) Homepage Journal
    Stop reading slashdot!
    • by chaboud (231590) on Friday July 07, 2006 @02:04AM (#15673546) Homepage Journal
      Reading slashdot during build-times is the only reason that I'm still here at 1am, working on an app in crunch time.

      I think that the most important thing to do when a project is on an insane schedule is realize that you aren't super-human and pace yourself. If you don't, and crunch hard nights or extra-long 50-hour sessions, you'll spend the next few days with a fried brain and a complete inability to make use of your time.

      If you're normally a 9-5 guy, pull 10 hour days. If you're normally longer, possibly consider working longer, but notice when you've started lagging because of fatigue.

      Other things:
      • Take walks. Get out, get blood flowing, and rest your eyes. Don't stop to talk to people on your walks, because you'll smoke hours talking about nothing (like postings on slashdot).
      • If you're angry, or burned out, take a day. You can spend entire weeks in a funk if you can't get yourself out of it. It doesn't help you, and it doesn't help your team. If your boss can't make sense of needing to pull away so you can be more effective, try and find another job.
      • Be reasonable about moving targets. There's no benefit to throwing a fit when your boss changes dates/requirements on you, but let him/her know what it's going to cost in time or other features. Be quick about this. Don't stew about it and let the feature-spec gel before you're quick to pull the "we have to cut..." card.
      • Big design up front: Don't do something three times because you weren't sure how you were going to do it in the first place.
      • Less design up front: Don't overdesign something because you're so hung up on not doing it twice. You might have to code it twice, or three times. Get dirty in the code long before you've started sweating details that don't matter. If you're solid, this stuff will just flow out naturally.
      • Learn to use copy and paste, along with other tricks to save yourself grunt-work time. It amazes me to no end how much time I see some programmers spend on writing code. On the same note, learn to type quickly. I've known some great programmers who were hunt-and-peck two-finger typists, and those are the same ones who generally pulled super all-nighters typing at 20 wpm.


      And my build is done...
      • by StrawberryFrog (67065) on Friday July 07, 2006 @04:19AM (#15673822) Homepage Journal
        Learn to use copy and paste

        Nooo!

        I wish I could beat with a crowbar all the cut-and-paste programmers who make my life difficult - I have to maintain the piles of repetitive crap code that they produced - they knew how to use Ctrl-C and Ctrl-V but could not or did not bother to do the most basic of programming taske: eliminate repetition by factoring code into meaningfully-named, paramterised procedures. This was best practice in 1970 already but so many people still don't get it.
        • I know the feeling: I had to fix up some code recently with around 120 similar functions, each of which started with the same ten lines of code with one number changed. I'd have thought that by the ten or twentieth time of Ctrl-C Ctrl-V, the coder would have stopped and thought about it, but apparently not.
        • Learning to use copy/paste doesn't mean "use copy and paste for everything you do." Don't confuse the two.

          Copy and paste come in handy when you're refactoring a function call, building a table of similarly named elements, or propogating a new flag/variable. It can be a serious time-saver. Ctrl+Shift+(left or right) to select, Ctrl+V, or double-click, Ctrl+V.

          I'm not saying that copying huge chunks of code is a good idea. That ends up costing you more time. I'm saying that typing things out fully when yo
          • I'm honestly not having a dig at you personally here, but I never understand the attitude exemplified by your post:

            One last note would be that, when it comes down to it and you just have to kill yourself to get something out the door, you shouldn't expect any huge pats on the back for it. If you grind hard, you generally won't be the last guy holding up the show. Do this for a few revisions, and people will come to think of you as a closer. I don't know if this really helps in any way. I think it genera

        • My favorite experience with this was when I was working right around Christmas of 2000. I'd been brought in on the project late in the game to help "relieve" one of the programmers who wasn't exactly working out. One day I had to fix a bug in his "Frequently Asked Questions" section of the website. There was an A-Z menu at the top of the screen that was acting finicky and I got to fix it.

          Luckily for me, this programmer _had_ factored his menu code into functions. 26 of them, in fact!
        • Learn to use copy and paste

          Nooo!

          I wish I could beat with a crowbar all the cut-and-paste programmers who make my life difficult - I have to maintain the piles of repetitive crap code that they produced - they knew how to use Ctrl-C and Ctrl-V but could not or did not bother to do the most basic of programming taske: eliminate repetition by factoring code into meaningfully-named, paramterised procedures. This was best practice in 1970 already but so many people still don't get it.

          All you gotta do is j

      • Good points!

        I'd like to add another one: fitness training.

        Don't stare at me like that. Of course even you can do it, it's just a question of starting small, and working your way up.
        Trust me, when you've just sweated fifteen gallons (or at least it feels like it), really finished yourself, and took a long hot shower afterwards, you feel completely new and relaxed. Especially if you finished the shower with an ice-cold minute :)

        Have a look at, for example, http://www.bodyforlife.com/ [bodyforlife.com] - they have a pretty good
    • And read Edward Yourdon, Death March, which already covers this topic.

      I'm not sure why I should read the above linked article, so maybe I won't.
  • by gubachwa (716303) on Friday July 07, 2006 @12:34AM (#15673277)
    Replace the title with one of "Smart Bridge Building on an Impossible Schedule", "Smart High-Rise Construction on an Impossible Schedule", or "Smart Heart Surgeries on an Impossible Schedule", and I ask you, how many people would want to cross that bridge, live in that building, or get that surgery? No one!

    "Smart ... on an Impossible Schedule" is just management/corporate speak for "How to minimize the crapiness of a project when we know we can't spend the proper time required." You can dress it up all you like with sleak catch-phrases, and call it a rose if you want, but it still stinks.

  • Good On Paper (Score:4, Insightful)

    by Anonymous Coward on Friday July 07, 2006 @12:35AM (#15673282)
    I'm in a similar situation as this, but atm, without the death march schedule. I've had quite a bit of time to consider the things and here's my conclusion.

    1. Planning documents are a great thing and are pretty much invaluable to a team's success on a project. However, when you complete the document and the very same day, someone in upper management says, "Now this is a great document for you guys" and immediately starts making large changes (true story), there's not a whole lot you can do. Also, as every developer is aware, it is more than likely that the scope, goals, features, etc were never clearly defined in the first place which means you're either going to be wringing it out of management, playing guessing games or both.
    2. Same thing is true for work estimates, great when you have them nailed down from the start, but good luck if scope creep is already kicking in before you've even started.
    3. This is probably the only thing that will save your ass. If the whole team has some exposure to each part of the project, it's likely that someone's sanity check will save you days or weeks of time before a bad design decision was made (and on a lower level, coding decisions). Something that I've really noticed myself is that QA starts the first day that designs are put on the table. If a design hasn't been picked at to start with, then it's pretty much guaranteed that a developer is going to have to go back and redo a bunch of things to make a feature work the way it should.

    So yes, the article does make some good points, but they only go as far as the factors covered are under your control. Even in the best circumstances, a poor programmer or a less than perfect team lead can hamstring the whole team. In the end, I think that the only benefit that articles like these have is to make you really think about process. Process might not save you in the end, but at least going through the effort should make you a better developer.
    • when you complete the document and the very same day, someone in upper management says, "Now this is a great document for you guys" and immediately starts making large changes (true story), there's not a whole lot you can do.

      I used to work at a company that did consulting projects (we'd design hardware/software products for customers and get them through small manufacturing runs). We had one particular difficult customer who just didn't seem to understand that at some point, we had to define what it was we

  • by DreamerFi (78710) <john.sinteur@com> on Friday July 07, 2006 @12:52AM (#15673336) Homepage
    And if you do manage to produce something marginally useful in that impossible schedule, they'll give you even less time to do it next time around. After all, you managed to meet the deadline, right?
    • My old company was that way. Our deadlines were given to us without consultation. Half of engineering's job was to figure out how to strip a project down to fit into the schedule. But each time we managed to do it we got a shorter schedule next time. The scheme finally blew up when we were given the ludicrous schedule (which we of course missed).
  • by davidwr (791652) on Friday July 07, 2006 @01:28AM (#15673444) Homepage Journal
    Pick two. If you are so lucky.

    A truly impossible schedule is by definition impossible to meet.

    An extremely-difficult-but-possible schedule is by definition makeable if the correct resources are applied... correctly.

    If management is giving you an impossible schedule, they are either idiots or setting you up to fail or both.

    If they are giving you a difficult schedule and refusing you the resources you need, or do not have the authority to give you those resources, see above.

    If they are giving you a difficult schedule and you haven't requested the necessary resources, then they are testing you and you've failed the test.

    --

    What do I mean by resources? I mean anything that can make the project go faster without sacrificing quality. This may mean additional manpower, the authority to say "no" to new feature requests, the authority to make feature cuts, or the reassignment or hiring of people with key skills to your project. It may also mean late-night pizza parties and family-support to the "code widows" until the project is complete. It can also mean additional or extended time off for the entire team after the project is shipped.
  • How to be a consumer without ever taking out the trash...

    How to spend money without making any...

    How to eat without any food...

    How to find another job after your company's poor planning puts you on the street.
  • 12 Rules (Score:5, Insightful)

    by johnBurkey (986647) on Friday July 07, 2006 @01:43AM (#15673493)
    1) Make sure you know what you are building. Many project delays are because the "customer"- the manager, corporate head, you? doesn't actually know what they want.

    2) Make sure you only work on things that you need to ship version 1.0 of that.

    3) Make sure you keep the prototype running always.

    4) Show Demos every few days to make sure noone is confused about what is going on.

    5) Tell them they can ship it whenever they want, they write the check.

    6) In the meantime, work towards the goallline like a football player, do not circle it like a lion waiting for it to die.

    7) Don't make any project your time to show how clever, cute, or interesting you can be...

    8) Keep Teams/Egos/Methods/Files/Modules/Projects/build times small. Small is good.

    9) If someone is not clicking with the rest of the team:

    - talk to them privately

    - reassign them

    - if this person is you, read #11, and consider if you want to build this project, or do something else. Follow your heart.

    10) Do the riskiest part of the project first.

    11) Remember that the enemy of the better is the best.

    12) Don't worry about it. If you are working hard, and follow 1-11, you are doing your part.

    That's enough to chew on. As homework, go build a paper mache model of the project, complete with testers whizzing around, filing bugs that are actually feature requests.

    • Re:12 Rules (Score:3, Interesting)

      by pieterh (196118)
      Those are very good rules.

      Very good indeed. Did you collect these yourself? If so, do you want a job?

      I'll add a few more of my own rules:

      - Make sure you're in total control of your toolset and improve it systematically
      - Do not take the clients' deadlines literally - first accept the project, then renegotiate the deadline.
      - Don't implement anything that is not going to be used immediately.
      - Design your software around interfaces so you can make massive changes cheaply.
  • by abigsmurf (919188) on Friday July 07, 2006 @01:46AM (#15673508)
    Companies should follow EA's tactics. Say to the coders "you'll have an easy schedule during the majority of a project but at crunch time, you're expected to work huge hours with minimal overtime pay" You start the coders on a project nearing crunch time, have them slave away till it's finished then move them onto another project that's nearing crunch time. If no projects are nearing crunch time move ahead the schedule on one knowing full well you can't meet the new date but still force the overworked coders to give 110% to attempt to meet this impossible target. You keep all the experienced programmers doing the stress free base work and once the outline is done, you move them to start another project. The vital experienced coders stay happy and stick with the company and the dime-a-dozen average coders have all the work they could possibly give squeezed out of them for minimal pay. Gotta love an industry with few/weak unions...
  • by Anonymous Coward
    How about drag and drop components to speed things up? Just drag the boss to the window and drop him. Make sure you compose and print a suicide note with his computer and printer first though. Then while they try to sort things out and hire a new boss just continue to work on the project and spruce up your resume.

    How's that version of "Quick-Kill Project Management"?

    Slashdot's bot checker a mind reader?
    please type the word in this image: motive
  • by Uksi (68751) on Friday July 07, 2006 @02:14AM (#15673570) Homepage
    I haven't the experience that some of the engineers hanging around here have, so please take what I say with a grain of salt.

    However, the article appears to be far too idealistic.

    1) The only good schedule is a realistic schedule. If the schedule is intentionally compressed, it's a bad schedule. The only way to compress your schedule is to cut work (e.g. features).

    1.5) Working under the "hurry hurry hurry" "boss wants it yesterday" environment means your engineers will cut corners everywhere. When faced with a choice to copy/paste a function in 15 minutes vs. taking some time to refactor and reuse the code in 1 hour, engineers will choose the earlier. In my experience, design debt then accumulates really fast.

    2) Code reviews as suggested in the article are a drag (2.5 hours at a time?!). In my experience, they rarely get anything useful done: it's usually too late to make medium or major changes and under the gun (see 1.5) engineers will scoff at "wasting time" with minor changes. From what I've seen, the code reviews serve mostly as a cover-your-ass mechanism for management.

    Code reviews need to be short (30-45mins) and happen as soon as possible, while the original engineer has all of the reasoning and decisions in his head. Hot-on-the-heels code-reviews of bug fixes and feature check-ins (especially useful for bug fixes).

    Perhaps the code reviews need to happen as the code is written (sometimes I ask my coworkers to show me their draft solutions). That's almost pair programming though. Unfortunately, that's not practiced at my job, and so I have no expereince with pair programming.

    3) Estimates. What the article described seemed to be a basic process for doing the SWAGs and the engineering time estimates that we all "know and love." I fail to see the novelty in the proposed approach: it seems to be run of the mill waterfall stuff.

    It's so easy to say "break down estimates into small tasks, so you can estimate well." However, I found it very difficult to do so effectively. Pardon the Rumsfeld flavor, but often we just don't know what we don't know: stumbling blocks occur, requirements drift or get "clarified", surprises abound. Pressuring developers to provide task breakdowns and estimates past their knowledge point can create a false sense of security (i.e. misleading task estimates). I've seen many such a small task breakdown become trash as the project progressed.

    Often, to get a better idea of the remaining work and tasks, prototype work is required or some progress on key features.

    I have no good answer for this problem, but my feeling is that it lies somewhere in the realm of being able to react quickly to change and reevaluate the project's progress. This is where things like smaller tasks and more frequent completion points of features seem to help. At that point, changing direction is easier because you have fewer concurrent unfinished tasks.

    This is where the smaller tasks and frequent iterations of the XP fame seem to be a benefit. Unfortunately, many managers can't take the thought of not having a detailed per-small-task project plan in their MS Project window. So, in my unfortunate experience, such managers attempt XP-style iterations, but then quickly regress into more traditional long-term milestones. I've seen it happen time and again.
  • Web-u-like (Score:2, Interesting)

    by Tinz (987375)
    I was asked to create a fully dynamic, CMS backed website in 3.5 days, using ASP.Net just the other day. This was because the Marketing department had forgotten to involve me in the launch of their new spin. I managed it by working long hours, robbing code from other projects and working at a furious pace. There was no time to plan, I just had to spill out ideas on the fly. Sound familiar?

    I went on vacation, returned after 3 weeks and nobody had used the CMS to populate the site with data and graphics. In f
  • by mcrbids (148650) on Friday July 07, 2006 @02:39AM (#15673632) Journal
    I can't stress this one enough!

    As architect of a small software company, the most frustrating aspect of designing software is the knowledge and understanding that there's no way to know how to do it right until you deliver something that's wrong. People almost never seem to know what they need, but they do know that whatever they have isn't it, and they'll tell you why.

    So, we have a very different tack, similar to Agile Programming [agilemanifesto.org]. When we implement a new feature or functionality tidbit, we release very early - pretty much as soon as it more or less works without major errors, - with as much fanfare as we can manage on the cheap, and then wait for the feedback.

    We're very up front about it, and openly welcome the feedback and ideas. This takes any conflict out of the relationship and turns it into a sort of partnership. Customers love being listened to, and feedback we get, in droves. When a customer sees THEIR idea implemented a week or two after they suggest it, even when it's something stupid-simple (such as having a particular button selected by default to avoid a common mouse-click) then they're your advocate for life!

    It's that continuous, iterative cycle that's resulted in our young, 3-year-old codebase having eye-popping features, and remarkable stability. The software updates itself at the client's discretion, so nobody seems to mind much. They update as often as they like.

    With this model, there is no due date. It takes me about 15 minutes to issue a release of our software. The idea of a "release" means almost nothing - we've done more than one in a day! (we've released 46 official releases in the past year alone, with too many "unofficial" releases to count)

    Faced with this "impossible" situation, (I've lived "impossible" schedules for years now) I'd step UP the release cycle and start pre-annuoncing alphas/betas of the product the instant that something that appears demonstrable compiles and can be stuck on a dev server someplace. Invite comments and download. Call people to ask about feature X or Y. Let them know it's really early, and make sure that they have a place to bitch about the problems they find.

    When you do, you'll be surprised how much of what you thought was required was, in fact, completely un-necessary - or at least could be put off until next March for a future release. But, you'll find some simple, straightforward ABSOLUTELY GOTTA HAVE that takes a man-month to code that the users would sacrifice their firstborn to have.

    Agile software methods will find this "gotta have" pretty quickly. The waterfall model [wikipedia.org] of software development would take a decade.

    You decide.

    This model won't work for all products and/or markets. And it's very important not to take away functionality that the customer previously had, or they get the feeling that you're taking something away, and that's bad. But for us, it's been very, very successful, and the relationship we have with our clientelle is very friendly, close and intimate.

    PS: Maybe it helps that we're an ASP.
    • This model won't work for all products and/or markets.
      Glad you pointed that out. We code medical devices that cannot fail. Sending alpha or beta code to customers without a written agreement wouldn't be such a good idea.
  • by frankie_guasch (164676) on Friday July 07, 2006 @02:58AM (#15673670)
    This books explains about this in depth and it's worth every cent :

    Rapid Development: Taming Wild Software Schedules
    by Steve C. McConnell

    I'm in no way related to it, I just own it and I think every project director should have one. It contains a lot of ideas and hands-on tips you can immediately try on the field. The last section, named Best Practise, is a practical reference guide. There is also a chapter if you already are in a crazy project and want to rescue it.

  • by wysiwia (932559) on Friday July 07, 2006 @03:37AM (#15673728) Homepage
    [Sarcasm on]
    1. Quick kill the managers who set the impossible schedules
    2. Quick kill the developers who can't stay within a reasonable schedule
    [Sarcasm off]

    It's impossible to change the development time outside of the -10%/+10% margins. If your schedule is wrong you either have incompetent managers, incompetent developers or both. What ever you do, work overtime, drop in more developers or else, all you gain is a few percents.

    Development time is IMO a rather static variable, the only thing which can improve this time is education. Yet education has to be done in advance before the project is even started. During the project there's no time for education while the knowledge should be available right from the start. The easiest solution is to always plan for a 25 - 30% education phase at the beginning of your project.

    O. Wyss
  • by janolder (536297) on Friday July 07, 2006 @04:08AM (#15673793) Homepage
    I've been in the business for over 20 years, as a developer, as an architect, as a team lead and as a manager.

    From architect on up, one of your key job responsibilities is to push back on features, schedules and so on, and to set expectations right from the get-go. Early on, I used to laugh out loud when being told proposed dates by marketing. That didn't go over too well, of course, so I've adopted a more diplomatic way of saying 'no' since. :-)

    The gist of it is that many executives believe in Spanish management (very well explained in Peopleware [amazon.com]). This boils down to setting ridiculous schedules, asking for continuous overtime, etc. The idea being that every minute an engineer spends more will get the product out the door faster. Of course, this is not the case as Peopleware will tell you in great detail. It is also matched by my own experience.

    However, if you push back with data in hand (such as a detailed sizing) and a constructive proposal what to do differently, you may very well end up with a more reasonable schedule, a good product and happiness all around.

    A few more gems in Peopleware:

    • Schedules are counterproductive. Teams that don't have schedules ouperform those that do by up to 50%.
    • Overtime is only productive for one week.
    • Cubicles are sinkholes of effectiveness. Why do Microsoft and IBM only have offices for engineers?
    Peopleware is rather sobering. Every other page you think "wait - we're doing exactly what is being described here." The good news is that you can do something about it once you can recognize the signs.

    For those of you with a humorous bent, I highly recommend checking out Joel Spolsky's articles [joelonsoftware.com] on project management. A few highlights:

    As far as the TFA goes, once you've accepted an impossible schedule you're already hosed. If you can't push back, leave. The job market is good right now.

    If you can get to a reasonable schedule (by way of reducing features, adding time or people), the TFA is a bit limited in its scope. I have a few recommendations that have worked for me in the past (your mileage will vary, and you should read Peopleware anyway):

    • You need to have the spec in writing.
    • You need to use source control, even as a single developer.
    • You need to have a single button build.
    • When the build breaks you roll back the change that broke it or you stop everything until it is fixed.
    • You need to build daily. Or better yet, continuously.
    • Unit tests are your friend. They're less useful on GUIs but for logic they're a godsend. Personally, I can crank out high quality code about twice as fast with unit tests (if you consider debug time). Reduced maintenance and improved sleep is a bonus.
    • In the same vein - automated system testing (if possible) is a wonderful way to improve shipped quality. Your testers (if you have any) cannot test everything.
    • Code reviews are great. We use code reviewer [codehistorian.com] with great impact on code quality.
    • Hire the best people only and fire those you have no hope of redeeming. It may sound harsh, but allowing an ineffective developer to remain on a team is a great way to kill both the team and the project.
    • You must have a bug tracking system.
  • Dont make the deadline.

    Cripes you guys, pulling miriacles out of your asses every day means that management expects it.

    Then sales starts selling your team as "getting it done in 1/4 the time. and then youare royally hosed with the worst job ever.
  • by 192939495969798999 (58312) <info@devinm o o r e .com> on Friday July 07, 2006 @07:07AM (#15674128) Homepage Journal
    1. Stop agreeing to customer deadlines before asking the engineers how long it's going to take/if it's possible.

    I've had many, many instances where someone asked me how long something would take, and I told them that there's really no good way to do what they're talking about so at least a month or two. It was only after this that I was told that they had already agreed to 2-3 weeks, so I'd better "figure out a way". But what if there is no way? It's not like 9 women can have a baby in 1 month, you know.
  • by hey! (33014) on Friday July 07, 2006 @07:40AM (#15674235) Homepage Journal
    Sustainability.

    I've taken development teams down into the Valley of Death and out the other side. It can be done. But there are consequences, and you're kidding yourself if you think you can avoid them.

    The first consequences is that you can only do this once. If you're smart, you hire smart people. They know when you are ordering them to jump into a pile of shit. And if you're smart, you hire craftsmen, and craftsmen have pride. They resent being told to do that. What that means is that if the second time you try it, you end up losing all the people who can find a job easily -- in other words your most valuable employees.

    Another word that should be in managers' vocabularies is investment. Developers create assets that produce future revenue and expenses. You want programmers working as hard as they possibly can, but not simply to get the job done. To get the job done right, which means producing something that generatesw more revenue and less expense. When you focus on just getting the job done, you end up with something that barely breaks even. That's the minimal criteria for "not failing", not the maximum possible success.

    That's why I hate questions that start with "How hard would it be..." because they focus on the present, not the future. It should be "I think we can make X dollars a year; how much would it cost to support this feature, and would the amortized development costs be justified by the net revenue given the other things we could put our efforts into?" It's not as pithy as "How hard would it be...", but it covers the things managers should think about: the future impacts on revenues and expenses, the opportunity costs of the road not taken.

    • Sustainability.

      I don't think this is possible given U.S. corporate practices or the market for software. My day job talked about trying to shoot for long-term success, but of course they're still fighting short-term fires (layoff when a customer has a bad quarter, stage releases to get something barely working out the door, keep cutting test time, etc.) Don't know whether they were really going to do it and failed, or whether they were just telling the engineers what they wanted to hear.

      Since neither yo

  • by s31523 (926314) on Friday July 07, 2006 @07:46AM (#15674255)
    I have seen great projects, OK projects, and the-worst-projects-ever-created. This article points out some good tips, but there is no such thing as a free lunch. The best thing you can hope for when faced with an impossible schedule is to communicate with management, and not just with bitching about how they setup an impossible schedule, but offer solutions that are logical, like reducing scope, throwing more money at it, slipping schedule, reducing quality, or yes even canceling the project!
    Want some good (aka REAL) tips, check out Steve McConnel's book on Rapid Development [amazon.com] (Ignore the fact that it is produced by M$ press). This book is great, and if anyone is serious about software development they should read this book. And for the developers out there, please read his other book, Code Complete [amazon.com].
  • There is a fundamental problem with planning innovation (doing something you or others did not do before):
    Because you are doing something new, you cannot predict in front how much time you need as you don't know the problems you will encounter and the additional requirements/features that pop up during development (this always happens in software or system development).

    PS. I am talking about real innovation. Most real innovations are build upon existing ones. So this holds only is you maximize sharing or
  • by JustNiz (692889) on Friday July 07, 2006 @11:12AM (#15675570)
    ...so last project you worked 40 hour weekends to bail management out yet again. The real problem: Now you've raised their expactations of whats possible, and they'll expect that and more next time. Its the Scotty principle.

    If you want to continue to give your whole life to your comapny in the mistaken concept that you'll get recognition for it later then chances are you're still a naieve new grad. Experienced engineers know they have to train their managers.

    After 25+ years of software development heere's what I learnt works best:

    * Demand the necessary time to do good work, no matter what time problems that may cause others. Reason: You will actually need about the same time, no matter what quality concessions you make. Furthermore, your manager should have had involved you in his time-estimates for project planning. This is management 101. If he didn't then this is the only way you'll convince him to involve you next time.

    * Don't ever agree to deliver low-quality product, regardless of other peoples deadlines. Reason: Non-techincal managers mistakenly believe that time can be saved by sacrificing quality. Actually the opposite is true. Low quality software takes more time overall. Furthermore, if you deliver crappy software, people will forever identify you as being a crappy engineer, regardless of any justifications you may have had at the time. If you're a crappy engineer you're like too many others and worth nothing.

    * Don't work overtime unless you both want to and are being paid extra for it. Reason: Your employer is making significantly more money from your work than they are paying you. If they weren't, they wouldn't keep you there. Its basic business economics. They are not a charity and you deserve to be paid and treated just like any other professional. Furthermore, it does nobody any favors if you set urealistic norms and expectations. Yet another reason is that you are far more effective if you're not continually burned-out.

    The BIG secret your company doesn't want you to know:
    Nearly all deadlines are just artificial mechanisms created by management and designed solely to get free overtime/more productivity from the workforce. They usually have no relation to what delivery date was acutally agreed with the customer.

"Pull the wool over your own eyes!" -- J.R. "Bob" Dobbs

Working...