[Sigia-l] tenets, principles, standards, etc ...

[Eric Scheid]

On 25/12/03 2:37 PM, "Listera" <listera at rcn.com> wrote:
>> When the project manager comes in with a list of 20
>> specifications he doesn't want to spend 20 * five minutes explaining
>> himself. That's almost two hours for something which should take just 5
>> minutes in total.
> 
> I'd much rather listen to a project manager (or anybody else for that
> matter) explaining *in their own words* what they want, even if it takes
> longer. That's infinitely better and ultimately more efficient than the PM
> referring to some phrase whose meaning in any *specific* context may differ
> in reality, perception or interpretation. It's easier to listen and ask
> *before* you start than to correct later. You can learn a lot by listening,
> try it.

What is this word "listening"? Could you perhaps explain what it means in
your own, how you say, "words". All this jargon you are using!

Seriously though ... "some phrase whose meaning in any *specific* context
may differ in reality, perception or interpretation" ... you'd think that
within a context of "information architecture practice" that information
architecture *specific* terms could be relied on to have some predictable
meaning. Industry specific jargon is common and useful.

Any employee or contractor that demands to take up 500% extra time just to
have *everything* explained to them in words of one syllable won't last long
in most places.

Can you imagine a plumber asking his assistant:

"Hey you, the one wearing grey overalls decorated with the letters
r,o,b,e,r,t via a process of needlework. Go to the large vehicle for
transporting things by road and carry back to this place right here the hand
tool with moveable jaws used to seize, turn, or twist objects such as nuts
and bolts."

"Hey Rob, fetch me a wrench from the truck, pronto."

>> Or, to be really efficient, you could have said all that with just one word:
>> "typically"
> 
> And I'd be wrong. If you had been paying any attention, you'd realize that
> I'm not a fan of "typical" solutions. We're in the customization business:
> specific solutions to specific problems.

We all want solutions that fit the need. Don't be so arrogant as to think
you are the only one that does.

As it happens, it's common that among the great many solutions that do fit
their needs that there are patterns of commonality, and these serve quite
well as starting points. You pick something which is a close fit, then you
see if it does fit, and when it doesn't you make adjustments and
customisations to suit. If you want to be efficient, you start with the
probabilities, and pick a "typical" starting point. The gains you make in
the majority of cases give you the margins to start over when you hit some
edge case.

Sometimes you might be met with a disquietude, in which case you start from
scratch, first principles, go native, drag a stick in the mud, bang the
drums, splatter paint across the canvas. Hugely inefficient when it's not
called for, invaluable when it is.

> Generic solutions to generic problems are best procured via the Turing-bots at
> the License & Standards Authority's automated Downloads section.

Again with the straw men arguments. Please, try to be original in your
trolling.

e.