Software Engineering - The Chess Model (aka Iterative Model, Tactical Model)

Author

The Chess Model (aka Iterative Model, Tactical Model)

Uenal Mutlu

2005-05-01, 9:07 pm

Chess is IMO the best model for describing nearly everything
in life, even the life itself: if there can be at least one reaction
to an action, and this is usually always true, then one has to
re-evaluate the plan after every action.
Applied to SW engineering, or any other project in life: a strict
pre-planning is impossible (much like in chess), a project must
be seen and practiced only as an iterative process where each
action and the response to it must lead to a re-evaluation of the
overall goals (global strategy), and then for refining the goals
and the strategy for the next turn (milestone/phase).
The consequence is: everything in life, incl. a project, must be
seen as a dynamic process, and there must always be the
possibility given for refining the next steps of the process .
Is this extreme?

Phlip

2005-05-01, 9:07 pm

Uenal Mutlu wrote:

> Chess is IMO the best model for describing nearly everything
> in life, even the life itself: if there can be at least one reaction
> to an action, and this is usually always true, then one has to
> re-evaluate the plan after every action.

I'm partial to Carcasonne, myself. More random, and you are not sure who's
really winning until the final tally.

> Applied to SW engineering, or any other project in life: a strict
> pre-planning is impossible (much like in chess), a project must
> be seen and practiced only as an iterative process where each
> action and the response to it must lead to a re-evaluation of the
> overall goals (global strategy), and then for refining the goals
> and the strategy for the next turn (milestone/phase).

Well, chess works with a couple hundred "standard openings". Because it's
not random, the iterations require deep planning to stay ahead.

You are saying that a process must use feedback in its planning. This is
totally correct - the deep planning must adapt after each move, so the deep
planning must plan to be ready to completely change.

> The consequence is: everything in life, incl. a project, must be
> seen as a dynamic process, and there must always be the
> possibility given for refining the next steps of the process .
> Is this extreme?

Yes. But let's try Monopoly. It plans based on odds and risks, not on strict
determinism.

As you iterate around the board, the odds favor you lose money until you own
property. So your primary goal should be to buy the first plot you land on.
In software, this means your project is still on the runway until you ship a
live version to real users, so they can add value to their business, and
return that as profit. Software projects should deliver early and often.
This represents as soon as you have property you have odds of collecting
rent on it.

As the odds start to favor gaining money, you have the choice to diversify,
or develop. (You also snap up utilities. They don't need developing, just
more utilities.) Diversification represents reaching out to new kinds of
features, and development represents extending the existing code with the
features it is designed for. So the design process should depend on the
sequence of requirements found to have the highest priorities.

If you have recently profited, diversify. If you recently lost, develop.
This represents the person who selects requirements for a project should
increase the business value of existing features until they demonstrate
profitability.

Now try not to let your liquid assets go below the average risk from the
other rents on the board. This is "risk management", where you control your
acquisitiveness until you have enough of a reserve for hard times. The
parallel in software engineering is to let your workers go home at 5:00 pm,
every day. Repeatedly depleting their neurotransmitters will increase risks,
and decrease the response time to risks that bite.

You can't develop a plot until you hold all plots of a color. This
represents programmers should work out of one codebase. Forking the
codebase, even as a convenience, generates the risk of building two
competing buildings at the same time, instead of just one. Risk management
requires narrowing your exposure to risk. So don't buy new plots of other
colors until you have a unified tract to develop.

As you pass Go and collect salary, if you have properties, you can start a
rhythm of development. For each new income, you put some into new real
estate and some into the cash reserve. This represents your dynamic
iterations should have static time boxes. Some teams iterate w

ly. What's
more important is iterations are strictly regular. If a feature is
unfinished, or a property undeveloped, you leave it undeveloped until the
next iteration starts and you are more prepared to advance.

(Contrarily, I once kept missing Go, and ran out of the cash reserves. I
turned the game around by voluntarily remaining in jail while my properties
collected rent. They were already more valuable than Go anyway. The parallel
here is to get thrown in jail for no apparent reason like Martha Stewart,
but keep your cell phone with you;)

--
Phlip
[url]http://www.c2.com/cgi/wiki?Z

Land[/url]

Bradley K. Sherman

2005-05-01, 9:07 pm

In article <d4vojf$2bk$02$1@news.t-online.com>,
Uenal Mutlu <520001085531-0001@t-online.de> wrote:
>Chess is IMO the best model for describing nearly everything
>in life, even the life itself:

And not even the whole game, just the one term: Zugzwang.

--bks

Martin Brown

2005-05-03, 9:03 am

Uenal Mutlu wrote:
> Chess is IMO the best model for describing nearly everything
> in life, even the life itself: if there can be at least one reaction
> to an action, and this is usually always true, then one has to
> re-evaluate the plan after every action.

Chess is only a useful model system for the very limited class of zero
sum games with perfect information. There are only two players and there
must always be a winner or a draw. Everything relevant to the statement
of the problem is unambiguous and precisely known to both sides. This is
very unlike most real world problems.

Chess also requires considerable strategic planning ability as well as
tactical finesse to acheive any useful standard of play beyond patzer.

If you treat software developing as a zero sum game who is the opponent?
a) the customer.
b) his problem you are trying to solve.

It is completely useless and irrelevant for all other classes of problem
where there is imperfect information, multiple players or win-win and
lose-lose are also outcomes. Software specification is often bedevilled
by unknown or unstated assumptions made by either the customer or the
developers. The various parties on the customer side of the requirements
specification often have unresolved and mutually incompatible aims and
hidden agendas.

If you must use a game analogy then contract bridge with the developers
and customer working together to beat the original specified problem and
the as yet unknown gotchas to an agreed contract might be a bit closer.
It even incorporates some hidden variables in the unseen opponent hands
of cards.

> Applied to SW engineering, or any other project in life: a strict
> pre-planning is impossible (much like in chess), a project must
> be seen and practiced only as an iterative process where each
> action and the response to it must lead to a re-evaluation of the
> overall goals (global strategy), and then for refining the goals
> and the strategy for the next turn (milestone/phase).

No argument at all that you have to work to keep a project alligned with
reality. And that requirements evolve as time progresses.

Equally you have to beware of excessive feature creep or otherwise
projects will never get finished as salemen promise ever more spurious
features to new customers just to close the sale.

> The consequence is: everything in life, incl. a project, must be
> seen as a dynamic process, and there must always be the
> possibility given for refining the next steps of the process .
> Is this extreme?

You aim to improve both the project in hand and the methods of
delivering projects in software engineering. You never stop learning.

Regards,
Martin Brown

Sponsored Links