Just Barely Too Light

AlistairCockburn, in AgileSoftwareDevelopment, talks about how his favorite methodologies are "JustBarelyTooLight".

Often, aspects of your development cycle develop cruft for legacy reasons (see: OldRulesWithForgottenReasons). Slightly erring on the side of lightness will help keep your processes lean in spite of our tendency towards heavier methods.

You seem to have caught me in an ambiguity... In one section of my book, I describe certain methodology failures from being JustBarelyTooLight... the definition of "Too" is just that - - "too" (as in, past the boundary). Therefore, JustBarelyTooLight is synonymous with "insufficient."

however... also in the book I quote JimHighsmith as differing from me in one regard: I recommend "As light as possible" (which unfortunately means Heavy to some people). Jim recommends, "one step lighter than that". Which is, guess what, Just Barely Too Light. There's the ambiguity.

I'm not sure what to do about this ambiguity. I like to study cases where they really are running JustBarelyTooLight, because there is a lot to be learned from those situations (they really are insufficient in some way). On the other hand, what you say is true - most people's minimally light is really heavier than they need, and they'd be better off running too light for a while and seeing where things really are JustBarelyTooLight and then adjust just that portion. These days I think of that as a FailingUnitTestForaMethodology.

I could probably use some help on dealing with this ambiguity, thanks -- AlistairCockburn

(Todo: Put some Alistairs comments from the book here.)

Examples:

EditText of this page (last edited January 4, 2002) or FindPage with title or text search