Roy 07 Apr 06

Interesting. Do you have any examples of recent big decisions that you’ve made easier by breaking them into tiny ones? I’m curious to see how it works at 37S.

Of course, sometimes big decisions can’t be made small. Read this fascinating article over at Design Observer to see what I mean.

Douglas 07 Apr 06

Roy: about that article. It doesn’t apply here, because LeMessurier didn’t really have a choice. He had to fix it. Quoting: “I got a problem, I made the problem, let’s fix the problem.” Some problems are big, but you can often eat away at them by making tiny decisions.

Douglas

Mark Gallagher 07 Apr 06

I think you are really talking about centralized and decentralized decision making.

There is tendency for management at big companies to force everyone into a single technology solution (the big decision) to prevent “one-off” and redundant efforts in the lines of business. They think this saves money.

But these centralized solutions are very expensive and inflexible compared to the new approaches made available by the rapid change and improvement in the technology.

One big company I worked for forced all internal web development into a single “do-everything” portal product. That big decision in effect eliminated most small decisions on all the projects. Over time that big decision increasingly looked expensive and noticeably slowed down innovation.

So if you choose flexible tools and allow decentralized decision making, you enable a lot of small and smart decisions.

Good discussion.

Roy 07 Apr 06

JF - surely less features doesn’t mean smaller decisions - just less of them. I’m still not sure how your big into tiny decisions voodoo applies there.

Douglas - I used the article to make the point that sometimes you just have to bite the bullet and make the call, rather than delegate, delay or divvy the problem up into micro decisions. As mentioned, LeMessurier had other options - he didn’t have to fix it. He only did because the problem couldn’t be broken down.

I’m all for making life easier, and agree that there are situations when big problems can be broken up. I just wanted to present the counter view that in many cases it’s experience, strength of character and following your heart that prevents the paralysis brought about by big decisions.

Anyway, thanks for the tip Jason.

Don Schenck 07 Apr 06

And keep things in perspective: the decision you are making will mostly likely NOT matter in, say, 100 years.

Luis 07 Apr 06

Is there really such thing as a wrong decision? There are so many constantly changing variables in life that a good decision today would possibly result in bad decision next week or next month. Or so that is what we might think.

Whatever happened to gut instinct? The good old days of “feeling good” about something and just going with it.

Douglas 07 Apr 06

“I mean, sixteen years to failure � that was very simple, very clear-cut. I almost said, thank you, dear Lord, for making this problem so sharply defined that there’s no choice to make.”

Remember when software came on disks, there had to always be a decision: “When do we ship?” It’s nice to see that as the software medium changes, even that decision can be split into smaller decisions: When do we launch the public beta? When do we publicize? When do we remove the beta sticker?

Douglas

Roy 07 Apr 06

[i]When do we launch the public beta? When do we publicize? When do we remove the beta sticker?[/i]

No changes here - just different questions. Physical software still has the same development phases as web-based software. The only difference with web-based projects is that it’s no longer as hard or expensive to change something once you’ve launched. (As 37s touch upon frequently in Getting Real.)

I think it’s misleading to say that breaking up a big problem into smaller ones negates the possibility of blame when things go wrong, or that each decision becomes less costly. After all, a lot of tiny mistakes are no different from one big one -LeMessurier’s problem arose from making mistakes at small levels because they became seemingly isolated tiny decisions - it wasn’t due to one giant cock-up.

This discussion has both surprised and delighted me today - it finally puts a welcome spin on the well-troden “less is more” approach. In the case of problem solving, it suddenly seems that more is better. I’m not sure this is the case.

An interesting discussion - it’s fun exploring it with you all.

Bill Tait 07 Apr 06

Whatever happened to gut instinct? The good old days of �feeling good� about something and just going with it.

This reminds me a bit of the thin slicing concept that Malcolm Gladwell talks about in “Blink.” You may not be able to fully articulate it, but your immediate intuition is often better than exhaustive research.

Kyle Cooney 07 Apr 06

Good point, Jason. Break your problem up into a bunch of small, manageable problems and attack the highest risk items first. Makes it a lot easier down the line and minimizes risk.

Chunk, chunk, chunk is my motto.

James Knight-Smith 09 Apr 06

Same as what Kyle said.

This concept is called chunking, and it helps stop overwhelm. Thats basically all there is to it.

Peter Eschenbrenner 10 Apr 06

the decision you are making will mostly likely NOT matter in, say, 100 years

Unless, of course, you are working at a big corporate entity where COBOL is still an actively developed language.