The Sooner You Fall Behind The More Time You Will Have To Catch Up

NASA's "on board shuttle group" (CMM level 5) have a motto: (See TheyWriteTheRightStuff)

: "The sooner you fall behind,
: the more time you will have to catch up."

Perhaps... Like many of the most entertaining assertions, it's carefully worded so as to be misinterpreted.

Try "the sooner you know that you're behind, the more time you will have to catch up."

No; that turns the meaning of the phrase on its head. IMAO, what the original quote means is, "ThrowAwayTheProductionSchedule and concentrate on the quality of the code, because you cannot avoid errors if you are under pressure to charge forward at full speed". If you set aside the time constraints and work on doing things correctly, you won't need to waste a lot of effort later fixing your mistakes - and you're less likely to make a mistake that you might miss later.

You must remember that speed is not a priority for the NASA group - writing working code that is absolutely reliable is the one and only goal they have. They can, and will, delay their missions by months or even years in order to DoTheThingRight, because anything else would be criminally irresponsible. Ironically, the result is that they are more likely to be timely with their code than a group which counts every minute of production time and pulls 60-hour work weeks, because they simply don't make the kind of careless errors most do in the first place, and the errors they do make are caught even before the code is compiled. - JayOsako

I can see that this is kind of true, chronologically, but I must be missing something.

You are missing the sardonic expression on the face of the writer :-)

I like PeteMcBreen's comment [below]. I was thinking that if you are looking at a gant chart of your project, when you are at the start of your project you have most of the time left. So if your schedule slips on day two -- well you have a lot of time to catch up. If however your schedule slips one day before its due date, well you don't have much time to catch up. -- ErikMeade

This is the way I see the comment, too. It's related to communication. Don't hide problems! The sooner you find out about them, the easier they are to deal with. --GlennVanderburg (cf BadNewsNeedsToTravelFasterThanGoodNews)

Sort of supports WorstThingsFirst, so if the worst is really bad you may need to ask yourself IsEarlierCancellationFailure ? -- ErikMeade

From the context of the article, I took the quote to a playful paraphrase of "Taking enough time to plan ahead in the beginning will pay off later on". --FalkBruegmann

Would this be equivalent to the old saying AstitchInTimeSavesNine?? --DrewMarsh

IthinkSo, but AstichInTimeSavesNine? also implies MakeSignalNotNoise ( doesn't it? ) which I don't get from TheSoonerYouFallBehindTheMoreTimeYouWillHaveToCatchUp. -- ErikMeade

"God put me on this earth to accomplish a certain number of things. Right now I'm so far behind that I will never die."

That's somewhat odd...: I can't find a definitive source, but this quote appears on page after page of Steven Wright jokes. So it's likely one of his.

I believe that quote is from a one-panel "filler" from the CalvinAndHobbes comic strip if memory serves well. -- AnonymousDonor

The motto could be related to the mechanics of orbital flight. If you have 2 objects in the "same" orbit, to catch up, you need to slow down, drop into a lower (faster) orbit, catch up and then move back up to the original orbit. Initially the relative distance increases, but the sooner you do this, the more time you have to catch up :-) --PeteMcBreen

Why doesn't moving back up to the original orbit cause you to fall behind again?

A: You do fall back to your original speed. ...but you're in a different position.

So, if your shuttle is orbiting at the same distance and speed as a satellite, you can "catch up" by slowing down -- falling to a lower orbit, wait until you get under the satellite, then speed up -- to get up to its orbit.

(...not that I really know anything about this. ;-)

Since orbits are curved, isn't there a deceleration/acceleration pattern that will dip you to a lower orbit then bring you back out, only having traveled something more like a straight line, and therefore a shorter distance? Can that shorter distance actually be covered in a shorter time? Anyone?

This discussion is going off on a tangent (the pun will be apparent shortly). For those unfamiliar with orbits, a bit of a refresher: Planetary orbits are basically elliptical, with the planet's centre being at one of the ellipse's foci. The closer you are to the planet, the faster you're moving (remember the StarTrek slingshot-around-the-sun fiasco?). A circular orbit is a special case of the elliptical orbit where both foci are in the same position.

In a circular orbit, you can change your orbit in two ways: You can accelerate along the tangent of your orbit, or you can accelerate in any other direction. If you accelerate along the tangent, your orbit will remain circular, but will either grow (if you're accelerating in the direction of your motion) or shrink (if you're accelerating backwards). Any other direction will change your orbit so it is no longer circular (it may also grow or shrink your orbit depending on the vector).

The 'slow down to catch up' trick happens when you maintain a circular orbit but shrink it temporarily by accelerating backwards. Because of how orbits work, you end up going faster rather than slower (because you're closer to the planet). If you tried to accelerate along the tangent toward your target (say a shuttle trying to dock with a space station), then you'll end up growing your orbit and moving slower. If you have a big enough engine and pick the right vector, you can probably accelerate toward your target (not along your orbit's tangent) and intercept it. The problem with this approach is that by the time you intercept your target, your orbit will have grown so big and elliptical that you won't be able to dock because you're going too fast. Assuming you don't collide, your orbit will now take you on a long elliptical trip away from the planet, far from where you want to be. So, the most safe/practical way to maneuver in space is to keep your orbit the same shape and accelerate along your tangent to adjust your relative position with other satellites. The cool thing about it is that it requires very little fuel to make these adjustments, and it's true, the earlier you make these adjustments, the less drastic they will have to be, the less fuel you'll use, and the more time you'll have to catch up.

[That's pretty bulky. The short version is: You're in a circular orbit and you want to change to a different one. Do a burn, which puts you in an elliptical orbit that intersects both your old orbit and the desired orbit. Once you get there, do a second burn to convert your elliptical orbit to a circular orbit.]

[You'll know which way to burn by the simple rule that faster circular orbits are smaller orbits; Mercury goes around the sun way faster than Pluto.]

[Orbital mechanics gets arbitrarily more complicated than that, but it's not a bad first approximation to the simplest case, should you ever find yourself at the controls of an orbital rocket with all the qualified pilots dead, as happens so often in the movies.]

SlowDownToSpeedUp

From a project perspective, although it may make sense in orbital relationships, that isn't very applicable/useful information. I agree with PeteMcBreen. Sounds more zen to me than anything - "the wise man knows he knows nothing." If you're understanding that no matter where you think you are in the project there is always the list of unknown issues that you will need to address. The sooner you find the unknowns the more time you have to address them.

I'm not so sure... how often does it happen that when the schedule slips, everyone's ordered to start working harder without much thought in which direction the additional effort should be directed?

I think I am missing the point. I assume the original NASA quote is meant to be taken humorously, but it appears that some are taking it seriously.

If you fall behind on the schedule, there is no magic that suddenly reduces the time to completion. If it was originally predicted to take 10 more weeks to complete, there is no reason to suddenly change that assumption and say that since we are a week behind, it will only take 9 more weeks to complete. If a project slips behind schedule, then an active step must be taken; change the schedule, change the man-power, change the delivery requirements.

My experience with slips is that they are proportional, not additive. If you've slipped one month at three months into a 1 year project, you are likely to deliver 4 months late, not 1 month late. YesterdaysWeather. -- Dave Van Buren

Falling behind on a schedule carries a negative connotation with it that keeps many people from admitting it, hoping they can catch up without anyone noticing, which is rarely true. Usually, thinking about the slippage that way will result in more slippage, or some other adverse effects on the schedules of people depending on your hitting your dates. In its dysfunctional extreme, it results in ScheduleChicken.

A mindset like the one this saying encourages can make it easier for people to admit they're behind, and reduce the consequences of the shortfall. A more accurate statement might be "The sooner you admit you've fallen behind, the more time you will have to catch up" -- but that doesn't scan as well. :) -- PhilGroce

In other words, it is usually an AntiPattern to DelayBadNews

Semesters vs. quarters

Some claim that semesters are better than quarters for college education because a semester is long enough to give you time to catch up when you get behind in your classes. You get behind during a quarter and the quarter is completely ruined.

Whether the story about semesters and quarters is true or not, getting behind does happen in any non-trivial pursuit, so it's important for any kind of schedule to include ways to catch up. Blaming or penalizing people for getting behind is not a way to address the fact that people sometimes get behind.

see SlowDownToSpeedUp, FinishedWhenItIsFinished