Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Smart Software Development on Impossible Schedules

CowboyNeal posted more than 7 years ago | 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."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered


Tried and true (4, Insightful)

Anonymous Coward | more than 7 years ago | (#15673221)

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

Impossible schedule? No problem. (-1, Flamebait)

Anonymous Coward | more than 7 years ago | (#15673222)

Step 1. Fire marketing.
Step 2. Fire overly optimistic clueless management.
Step 3. Next time, include programmers in the loop when planning.

Techniques don't make up for a bad schedule! (4, Insightful)

gasmonso (929871) | more than 7 years ago | (#15673234)

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]

Re:Techniques don't make up for a bad schedule! (4, Insightful)

AuMatar (183847) | more than 7 years ago | (#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.

Re:Techniques don't make up for a bad schedule! (3, Insightful)

Baddas (243852) | more than 7 years ago | (#15673618)

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)

Inflation doesn't make up for a bad schedule! (1, Funny)

Anonymous Coward | more than 7 years ago | (#15673330)

"We developed a rule of taking the engineers estimates and double them. Of course we're still running a little late ;)"

Problem is Scotty already doubled them. Now just wait till the admiral gets them.

Re:Techniques don't make up for a bad schedule! (3, Interesting)

UpsideUp (816056) | more than 7 years ago | (#15673353)

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 anomolay for others.

Re:Techniques don't make up for a bad schedule! (3, Funny)

fbjon (692006) | more than 7 years ago | (#15674023)

the anomolay
Something like blind sex, I presume?

( -> anomaly)

Re:Techniques don't make up for a bad schedule! (4, Interesting)

Morris Schneiderman (132974) | more than 7 years ago | (#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.

The same lessons... (2, Insightful)

hackwrench (573697) | more than 7 years ago | (#15673746)

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.

double time ain't enough. (5, Insightful)

fprog (552772) | more than 7 years ago | (#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!

Smart? (4, Insightful)

qbwiz (87077) | more than 7 years ago | (#15673249)

It seems to me that if you have an impossible schedule, then you've already failed.

Getting back on track (4, Insightful)

EmbeddedJanitor (597831) | more than 7 years ago | (#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:Getting back on track (3, Insightful)

Joebert (946227) | more than 7 years ago | (#15673317)

But don't let them know too early, they might decide to go with someone who will be on time instead.

Re:Getting back on track (4, Interesting)

Nefarious Wheel (628136) | more than 7 years ago | (#15673350)

"So, do you want the problem solved or would you like to spend the time apportioning blame?"

-- this little line has helped me throttle down a lot of rants over the years.

Re:Smart? (5, Insightful)

Monkelectric (546685) | more than 7 years ago | (#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? (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#15673558)

As a spelling architect, the appropriate answer to that last one is "You should learn how to spell 'lose' correctly."

Re:Smart? (1, Interesting)

Anonymous Coward | more than 7 years ago | (#15673573)

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

And then you:

a) get fired.

b) get yelled at by your boss for making his company seem slow and incompetent.

c) lose the contract to that company that lies and says they can do it faster than your accurate estimate.

d) all of the above.

Re:Smart? (1, Insightful)

Anonymous Coward | more than 7 years ago | (#15673646)

And if you do get fired for this you don't really want to be working for that company anyway. They just did you a big favor.

Re:Smart? (2, Insightful)

Fulcrum of Evil (560260) | more than 7 years ago | (#15673714)

And then you: a) get fired.

And then you go compete with that company and bury them because they don't know how to schedule and, most likely, can't prioritize features because they never listen to their engineers.

Re:Smart? (4, Insightful)

Bacon Bits (926911) | more than 7 years ago | (#15673727)

And then you:
a) get fired.
b) get yelled at by your boss for making his company seem slow and incompetent.
c) lose the contract to that company that lies and says they can do it faster than your accurate estimate.
d) all of the above.

Do not lie to your customers when you make a quote for them just to get one contract. Be honest about everything. The most important customers are repeat customers, and you will be #1 on their list if you get them a quality product on time and on budget.

Losing one contract is no big loss, particularly when you know for a fact that your competition cannot possibly make the goals they're quoting. They will look like fools when they ask for time and budget extentions or fail to produce anything usable, and nobody likes to do business with a fool. As they say, people might not know the difference.

Certainly there will always be competition that lies to get the sale and customers that make poor decisions based on unrealistic quotes. Dishonest business and mismanagement are commonplace. That doesn't mean you should compromise your quality or ethics. That's called "professionalism". Customers worth doing business with appreciate that, and you will attract repeat business and new customers through word of mouth.

Re:Smart? (0)

Anonymous Coward | more than 7 years ago | (#15673997)

Do not lie to your customers when you make a quote for them just to get one contract. Be honest about everything. The most important customers are repeat customers, and you will be #1 on their list if you get them a quality product on time and on budget.

You will be on nobody's list if you give them reallistic schedules. Customers are more prone to change their provider than their mind. If you are honest, somebody else will lie to them and get the contract. The sad part is that you will never hear from that customer again, no matter what you do.

Re:Smart? (4, Insightful)

jrumney (197329) | more than 7 years ago | (#15674011)

You will be on nobody's list if you give them realistic schedules.

On the contrary, in my experience companies tend to come back to you to ask you to clean up the mess made by the low bidding cowboys when they realise that you were just being honest with them. At this stage you can often get away with jacking up the rates too, as they have made that realisation that you get what you are willing to pay for.

Re:Smart? (1)

WasterDave (20047) | more than 7 years ago | (#15673484)

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". Now work out how it's going to be made, who'll do the work and how long it will take. If that number is "too long" then go somewhere f*cking else because this one is doomed to failure.


Re:Smart? (1)

Anonymous Coward | more than 7 years ago | (#15673496)

RTFA - If you have an impossible schedule, that just means your project is going to be late. Is there any programmer who hasn't delivered a late project at least once? The goal is to keep it from being even later, and that's what this article is about.

Code reviews (2, Interesting)

tcopeland (32225) | more than 7 years ago | (#15673255)

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 (2, Interesting)

bill_kress (99356) | more than 7 years ago | (#15673434)

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 you about the most important part of coding, eliminating all redundant code (fully factoring your code)? If you've got your code factored well enough, you really can't screw up too bad since any fix is going to be limited in scope and probably pretty simple to fix--and this is what your code reviews really should be doing unless you have really really screwed up code to start with.

Re:Code reviews (1)

_Upsilon_ (97438) | more than 7 years ago | (#15673446)

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 (2, Interesting)

kiran_n (228321) | more than 7 years ago | (#15673447)

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 (2, Insightful)

cerberusss (660701) | more than 7 years ago | (#15673462)

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

Code reviews should be done by developers who hate code reviews, and should be concentrated on the meaning of the code and what could be missing.

Coworker doing a review: "Hm, this function looks a bit big, maybe you should split it."
Me: "OK, good idea. But do you think these 500 lines cover the problem, or have I missed something?"
Coworker: "Umm, it looks OK".
Me: "Well, maybe you should give it some thought?"
Coworker: "I have, and it looks OK. Hey, you have some duplication here."
Et cetera.

Re:Code reviews (4, Insightful)

Anonymous Coward | more than 7 years ago | (#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 (5, Interesting)

Bodrius (191265) | more than 7 years ago | (#15673490)

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 (2, Interesting)

Bodrius (191265) | more than 7 years ago | (#15673568)

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 wide meeting will feel like a waste of time except for the smallest of teams. There's a population count and a level of detail at which a meeting has diminishing returns, because it's difficult to keep everyone focused and communication gets tricky in disagreements.

I think narrower code reviews, in both scope and audience, are far more useful to improve quality. It also makes it easier to keep it at the peer consultation level rather than an inquisitorial mood.

Re:Code reviews (2, Interesting)

Brandybuck (704397) | more than 7 years ago | (#15673494)

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.

Re:Code reviews (0)

Anonymous Coward | more than 7 years ago | (#15673684)

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.

Pair programming sucks. Sitting within 6" of a coworker 8 hours a day after day after day is not my idea of fun. And try pairing men and women together - sounds good on paper, but leads to plenty of awkward moments due to the close physical proximity. I've even witnessed a woman+man pair team turn in to a stalker+stalkee saga ending with the stalkee leaving the company.

Code reviews work just fine, and have been proven to be more effective (quicker+cheaper) at finding bugs than all forms of testing combined (McConnell's Code Complete 2).

Re:Code reviews (1)

AuMatar (183847) | more than 7 years ago | (#15673697)

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 in different colors). We email the team with the URL, and 1 or more people will read it and comment. Typical comments are "I don't understand the purpose of block X" (in which case you explain your logic), "function y is not commented sufficiently" (in which case you comment more), and alternative architectural suggestions which may be more maintainable. I have never seen a "Put the brace on the other line" or the like. The email rounds complete until either all objections are trivial (and are just done and checked in) or there are no more objections. All changes are reviewed. Its low overhead, and gives 100% coverage of the code by at least 1 reviewer.

Re:Code reviews (1)

unsorted (987376) | more than 7 years ago | (#15673731)

What surprised me is that they want you to collate all the review comments in an excel sheet. Being asked to put code comments in an excel sheet is one of my pet peeves. It's never effective in my experience. If people know they'll have to write it up in excel, then they tend to be conservative in the review itself - you'll mostly see four or five vague comments like "refactor ". Marked-up printouts (as the authors themselves suggest) are the best means of doing code reviews. Just make sure you preserve the printouts for follow-up reviews (and in case your company's "process" or "quality" dept starts hounding you).

Re:Code reviews (1)

StrawberryFrog (67065) | more than 7 years ago | (#15673844)

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 beautifier that will add the space for you.

You can explote your coders better by outsourcing (1)

sapgau (413511) | more than 7 years ago | (#15673260)

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?

Re:You can explote your coders better by... (1)

Joebert (946227) | more than 7 years ago | (#15673346)

My current team has issues communicating, so I should bring another language into the equation ?

What are you, some kind of foreign labor spokesperson ?

Re:You can explote your coders better by... (2, Insightful)

sapgau (413511) | more than 7 years ago | (#15673416)

Nope, just a manager who wants to cut the time it takes to build our product and save some bucks while doing it(I will probably get a big fat bonus). And nobody can tell me otherwise because I read it on my favourite business magazine that claims it's the way to go.

/Make sure that I bail out for maintenance and future changes
//I don't know why Crystal Reports comes to mind ;-)
///Everybody can understand english, you just need to speak a little louder :-D

Re:You can explote your coders better by... (1)

Joebert (946227) | more than 7 years ago | (#15673548)

That wouldn't happen to be a sales manager for a foriegn staffing firm would it ?

Re:You can explote your coders better by... (1)

Duhavid (677874) | more than 7 years ago | (#15673593)

Sarcasm, Joebert. Joebert, Sarcasm.

Re:You can explote your coders better by... (1)

Joebert (946227) | more than 7 years ago | (#15673620)

Oh me & sarcasam have met, it just seems that every time we do, they've undergone plastic surgery & I don't recognise them at first.

Re:You can explote your coders better by outsourci (1)

Duhavid (677874) | more than 7 years ago | (#15673605)

So that the oursourced-to crew can say
" we love deadlines, the whooshing
    sound as they go by, priceless ".

Or something like that.

Easy! (5, Funny)

gillbates (106458) | more than 7 years ago | (#15673269)

Stop reading slashdot!

That's funny, but... (3, Insightful)

chaboud (231590) | more than 7 years ago | (#15673546)

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

Re:That's funny, but... (5, Insightful)

StrawberryFrog (67065) | more than 7 years ago | (#15673822)

Learn to use copy and paste


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.

Re:That's funny, but... (1)

BenjyD (316700) | more than 7 years ago | (#15673857)

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.

Not chunks of functions... (1)

chaboud (231590) | more than 7 years ago | (#15673897)

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 you could use copy/paste can be a time saver. It's also worth mentioning that learning little shortcuts in your environment may not save you time overall, but it can make you faster when you need it. Spend slow times getting to know your workspace.

Yes... I'm still at work.

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 generally just means that you get more work to do...

Back to the grind...

Re:That's funny, but... (1, Interesting)

Anonymous Coward | more than 7 years ago | (#15673919)

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

Zark's singing fish, yes.

Even more annoying, though, is trying to fix a C&P programmer's mess and then being told to - and I quote - "just copy and paste, we don't have time to over-engineer it," not by management, but by the lead developer.

I am a rebel, a guerilla programmer, fighting to change the company from the inside...

Next task: getting them to accept that version control is a good idea.

Re:That's funny, but... (0)

Anonymous Coward | more than 7 years ago | (#15673965)

Learn to use copy and paste, along with other tricks to save yourself grunt-work time.

IMHO, copy-and-paste should be banned to developers: if you are repeating the same code over and over again, then you should rethink your dessign.

Re:Easy! (1)

Ulrich Hobelmann (861309) | more than 7 years ago | (#15673627)

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.

Why do people buy into this nonsense? (5, Insightful)

gubachwa (716303) | more than 7 years ago | (#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.

Re:Why do people buy into this nonsense? (3, Insightful)

rtaylor (70602) | more than 7 years ago | (#15673315)

Smart High-Rise Construction on an Impossible Schedule

Done regularly actually. The big difference is that the impossible schedule dramatically increases costs (heating in winter for year-round construction, running three crews in shifts for 24/7 construction), etc.

For some reason "Impossible Schedule" in software development means cutting corners instead of increasing manpower.

Re:Why do people buy into this nonsense? (2, Interesting)

Joebert (946227) | more than 7 years ago | (#15673365)

Mod parent Insightfull.

I think the prime difference is that buildings have a much greater lifespan than software, so it's alot easier to justify the increased cost of a building.

Re:Why do people buy into this nonsense? (2, Insightful)

sapgau (413511) | more than 7 years ago | (#15673385)

It might reflect how "immature" the programming profesion still is. The moment you have a larger team in software development you immediately have delays due to coordination among team members and problems with integrating components. You better make sure that everybody is on the same frequency so nobody steps on each other's toes and that scope creep is not allowed to run rampant.

Because software is something of a virtual product, people think that is very easy to make changes along the way. You wouldn't see an architect or a civil engineer accept fundamental changes to the design: "Oh how about moving the elevator shafts to the side and making space for a swimming pool on the 10th floor?"

Re:Why do people buy into this nonsense? (4, Informative)

pnatural (59329) | more than 7 years ago | (#15673431)

For some reason "Impossible Schedule" in software development means cutting corners instead of increasing manpower.

Because that's all you can do (in general). Adding man-power to a late software project only makes it later, as was shown by Brooks [amazon.com] some 30 years ago.

Manpower is not fungable (1)

davidwr (791652) | more than 7 years ago | (#15673495)

Programming isn't like building a bridge or skyscraper, where you can say "this will take x man-months" and build either a quick, expensive schedule or a long, less-expensive one.

Someone else already mentione Brooks's Mythical Man-Month. By and large Brooks is correct. There are some opportunities to "buy time" but these only work when the people you are adding have roughly the same level of knowledge as the people who are already on the team, and even then it's dicey. For example, if you manage to get someone added to your team who worked on the last release, and have him be responsible for updating the code he's already familiar with, you can make the project go faster. Bring in someone unfamiliar with the code and your schedule will suffer while he trains up. Also, if you were planning on giving a part of the project to an as-yet-untrained group, you can bulk up that part of the team before training starts and shorten the schedule. For example, if you have a dedicated team of in-house testers who have never tested your new product before, it won't be terribly costly to double the size of that team. Of course, if you don't adjust the size of the development team to account for bugs coming in at up to twice the previously-predicted rate you might shoot yourself in the foot.

Re:Why do people buy into this nonsense? (1)

mrbooze (49713) | more than 7 years ago | (#15673905)

If it's done regularly it is by definition not an impossible schedule. Heck, if it's done regularly, it's not even an improbable schedule!

And increasing manpower can only get you so much benefit, or as an old boss of mine used to say: "It takes a certain time to bake a cake, and you can't speed it up by turning up the heat or hiring more chefs, unless you really don't care what it tastes like."

Certainly if you don't have enough people, hiring more will help, and there is some window beyond that where additional resources can improve efficiency, but there will always be diminishing returns at some point. Sometimes a schedule really just is flat out impossible.

Re:Why do people buy into this nonsense? (1)

sd4l (448263) | more than 7 years ago | (#15673969)

Damn, and I'd moderated in this thread too! Oh well....

The reason "Impossible Schedule" in software development means cutting corners instead of increasing manpower is down to a idea put forward by Fred Brooks in The Mythical Man Month. Basically, in construction the foreman knows the details and tells workers "build a column x feet high by y feet square here" and the worker does it. If you need to bring a new worker in to meet an impossible schedule then you just tell them to build their columns and they get on with it at the same speed a worker that was already working on the project does.

In software it's different. Imagine coming in (late) to a project with a million lines of code and being told "we need to make the font size configurable throughout the application, so create an item in the preferences dialog, store the preference and ensure everywhere uses this preference". It would take a fair while to find your way around the code which wouldn't be a problem for a programmer already on the team.

That's why it's not a simple answer of "this software's running late, throw another 20 programmers on the job and get it done in schedule".

Re:Why do people buy into this nonsense? (1, Insightful)

Anonymous Coward | more than 7 years ago | (#15674019)

In software increasing manpower doesn't work. You just end up with more people that have to learn the ins and outs of the project. Read "The mythical man month". Small teams working on different componants is a good model, as everyone knows their bit of code inside out.

Re:Why do people buy into this nonsense? (1)

unimacs (597299) | more than 7 years ago | (#15673577)

Because the consequences of a bridge failing, a botched heart surgery, and a collapsed high rise are usually far more serious than Microsoft Word crashing. I agree that if you're working on a Space Shuttle navigation system, you need to follow a process/documentation heavy methodology. On the other hand if you're working on a website for "Joe's Bait shop", you probably can get more than satisfactory results on a budget and schedule that Joe can actually afford and will work for him if you don't go through all the same steps. The fact is that in many cases software that's lacking in some important features is still better than no software at all. Even software that's got some bugs can be better than not having it available for those willing to put up with the quirks. Right now I'm working on a website that needs to be up pronto or a real opportunity will pass. It's painful knowing that we'll have to leave off some things we'd really like on it. It's also painful knowing that some of the code I write today will be likely be thrown out down the road, but that's better than not getting the site up when it needs to be up.

Good On Paper (4, Insightful)

Anonymous Coward | more than 7 years ago | (#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.

Re:Good On Paper (1)

honkycat (249849) | more than 7 years ago | (#15673535)

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 were building and what features it had to have to qualify as meeting spec. After a lot of back and forth early on thinking of all the great things it could do (which is fine), we finally had a meeting where we put together the design spec outline. As we closed the several hour meeting after which we were going to write the spec that would go in the contract, this guy actually really truly said, "Now, I hope you're not going to point to this and refuse a new feature later because it's not in the spec."

Really. It was all I could do not to stand up, throw my notebook at him, shout, "That is exactly what we'll do you moron, that's why we are writing this spec!" and storm out of the room. He did go on to try to add a few features later on in the design process. We probably implemented some of them, too.

Video Games Are Good For Me (1)

Joebert (946227) | more than 7 years ago | (#15673299)

Smart Software Development on Impossible Schedules

It's like playing Final Fantasy & casting Haste on your own team members after they've all been Doomed in an attempt to beat the clock.
Sometimes it works, sometimes it doesn't.

Re:Video Games Are Good For Me (1)

mookie da wookie (919403) | more than 7 years ago | (#15673351)

Joebert? Is that you? You let a guy donkey punch you and you never return a phone call? Look. I know we are both just a couple of fudgepackers, and I know I have packed your fudge on many occasions. Can we talk? I want to kiss you again as only two men can kiss. I promise my mom won't catch us this time. Call me? 314.966.6611 Kisses. XOXOXO

Remember, it's Johnny! Come on, please! Let's hook up again and rekindle the passion that set the night afire! I want to caress your thighs again! Call me tonight!

You are good for me, joebert (1)

mookie da wookie (919403) | more than 7 years ago | (#15673380)

That is my work phone, btw. Ask for John-who-likes-a-poke-from-a-guy. I'll be there tomorrow. We can hook up then. Love ya? Heck yes!

Overcoming impossible schedules.. (0)

Anonymous Coward | more than 7 years ago | (#15673320)

is an oxymoron. That said, when I'm strapped for time I just inject embryonic stem cells down the eye of my penis.

Next time will be worse (2, Insightful)

DreamerFi (78710) | more than 7 years ago | (#15673336)

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?

Re:Next time will be worse (1)

Brandybuck (704397) | more than 7 years ago | (#15673526)

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

Hey, Windows/Linux Refugees! (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#15673338)

The only thing more pathetic than a PC user is a PC user trying to be a Mac user. We have a name for you people: switcheurs.

There's a good reason for your vexation at the Mac's user interface: You don't speak its language. Remember that the Mac was designed by artists [atspace.com], for artists [atspace.com], be they poets [atspace.com], musicians [atspace.com], or avant-garde mathematicians [atspace.com]. A shiny new Mac can introduce your frathouse hovel to a modicum of good taste, but it can't make Mac users out of dweebs [atspace.com] and squares [atspace.com] like you.

So don't force what doesn't come naturally. You'll be much happier if you stick to an OS that matches your personality. And you'll be doing the rest of us a favor, too; you leave Macs to Mac users, and we'll leave beige to you.

Title Is An Oxymoron (0)

Anonymous Coward | more than 7 years ago | (#15673361)

It should read "Stupid Software Development on Impossible Schedules".

head 'em up, turn 'em out, rawhide (1)

grikdog (697841) | more than 7 years ago | (#15673408)

My favorite project karaoke is Rawhide. I never actually sang it on the job, but I had the joyous pleasure (after I left, throwing my mug in the drink and wishing river trolls on the morgul-minded) of watching that management style self-destruct within three months. From "my way or the highway" to chapter eleven in 90 days, wow. No, folks, rawhiding your most creative people is stupid.

fast, cheap, well done (5, Insightful)

davidwr (791652) | more than 7 years ago | (#15673444)

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.

Next in this exciting series of articles.... (1)

vought (160908) | more than 7 years ago | (#15673474)

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 (5, Insightful)

johnBurkey (986647) | more than 7 years ago | (#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.

The EA method... (5, Funny)

abigsmurf (919188) | more than 7 years ago | (#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...

prioritize and make small releases (0)

Anonymous Coward | more than 7 years ago | (#15673547)

When you're in a situation like that you need to prioritize the most critical features and release them immediately.

Drag and drop (2, Funny)

Anonymous Coward | more than 7 years ago | (#15673551)

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

Human Resources Stunt (0)

Anonymous Coward | more than 7 years ago | (#15673567)

How many of us have been under the fire of those impossible schedule? These last years have been coupled with "due yesterday projects" requests. It must be some human resources way to have results against lazyness and such.

too idealistic: it's the same old sw management (2, Insightful)

Uksi (68751) | more than 7 years ago | (#15673570)

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 (2, Interesting)

Tinz (987375) | more than 7 years ago | (#15673586)

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 fact, the Marketing department complained that I had not given them more time to decide what they wanted. I was blamed for holding the project up.

A lot of people out there think that coding is very simple, a bit like waving a magic wand. Oh ... and the amount of times I have been told, "it's just a few buttons, surely you can manage that!"

Now where's my wand gone?

Re:Web-u-like (1)

Lehk228 (705449) | more than 7 years ago | (#15673789)

if they ask for buttons give them buttons

"oh, you wanted the buttons to DO something????? that takes longer

Release early, release often (4, Interesting)

mcrbids (148650) | more than 7 years ago | (#15673632)

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.

Rapid Development: Taming Wild Software Schedules (3, Informative)

frankie_guasch (164676) | more than 7 years ago | (#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.

Quick-Kill Project Management (2, Insightful)

wysiwia (932559) | more than 7 years ago | (#15673728)

[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

Just say no (and more) (5, Insightful)

janolder (536297) | more than 7 years ago | (#15673793)

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.

Use a tool (0)

Anonymous Coward | more than 7 years ago | (#15673973)

Use a project management tool that does most of the work for you like xProcess from http://www.ivis.com/ [ivis.com]
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account