Hi,
Phillip J. Eby wrote:
To a certain extent, these approaches *appear* riskier because there
is a definite up-front cost, and the human brain is biased towards
options that lead to a sure short-term gain and a possible later loss,
over options with a sure up-front cost, for a possible later gain --
even if the two options are mathematically indistinguishable in terms
of net gain or loss!
Well, it's worth knowing then which mathematical function you're trying
to optimize: is it long term life of the project? is it how useful it is
to users? Note that in all scenarios, if the function (a) crosses the
death threshold (no more funding whatsoever) in the process, it doesn't
really matter if, asymptotically (a) and (b) are indistinguishable... So
even if the long term is important, trying not to die on the way is
important too (remind me of this interesting reading:
http://paulgraham.com/die.html).
So it tends to come down to the question of what kind of delays we'd
prefer: relatively predictable up-front delays, or release-time delays
of unpredictable duration?
I like predictable, the question is: how long? and how much effort?
If the issue is adequate test coverage (and having a test-driven
development culture), then I think we *can* have a considerably more
predictable release cycle. In a test-driven model, the architecture
is forced to be modular (and acyclic!) in ways that we currently aren't.
Ultimately, this is a "bet the farm" decision, and all choices are
equally risky in the sense that the wrong one will sink the project.
The major advantage of option #1 is that its failure mode doesn't
carry any *personal* risk to the individuals involved.
That is, in the "nobody got fired for buying IBM" sense, it makes
sense for *everybody* involved (me included) to CYA by recommending
option #1. If it fails, nobody can point a finger at any of us --
especially since the most likely form of failure is just that the
project just fades slowly into obscurity.
To choose option #2 or #3 is to open one's self to possible ridicule;
every setback, however minor, may be used by the ignorant as an excuse
to attack the decision.
No one will argue and say that a test-driven culture is a bad thing or
that adequate test coverage is preposterous. The element of decision
you're keeping out of your reasoning is time and amount of efforts. This
is however the yardstick that'll get the project funded or not
eventually. I can only guess how much work what you're proposing (i.e.
rewrite the whole architecture so to ensure full testability) will cost.
One thing though gets me worry: the way you frame things, it seems that
you assume that embarking on #2 or #3 will basically stall the current
project (Chandler Desktop 0.7.x), meaning consuming all resources and
leaving existing would be users in the cold, or, IOW, we may as well
renounce recruiting users with what we have. Do I decode you correctly?
If it is, frankly, I think that those options are non-starters.
On the other hand, I can imagine that doing #2 or #3 doesn't mean we
have to stall 0.7.x though it will certainly split the team. Doing so
however depends heavily on the cost of #2 or #3.
Cheers,
- Philippe
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
