[
Lists Home |
Date Index |
Thread Index
]
On Mon, 2004-01-05 at 14:57, Simon St.Laurent wrote:
> igraham@ic-unix.ic.utoronto.ca (Ian Graham) writes:
> >This reminds me of the "limits to software estimation"[1] article,
> >which relates the software estimation problem to the algorithmic
> >complexity of the problem, particularly in the large problem
> >size/complexity limit [I thought this was discussed on this list
> >before, but can't find any reference to it].
> >
> >Funny how everything seems to end up at complexity, one way or another
> >;-)
>
> >From my perspective, much of the problem comes from the way we try to
> design software: as coherent systems.
>
> Most complex human systems originated organically; no one designed
> Paris. Even in the most planned of communities, it's unusual for the
> color of the bathroom paint to be strictly specified.
>
> I'd hoped that XML's extreme openness would be an opportunity for this
> kind of openness to appear in the computing world, a chance for
> developers to accept the chaos that often produces fine results in the
> real world, even in the business world.
>
> For the most part, though, I continue to hear "XML is an okay syntax,
> but still we must all agree on semantics precisely for anything to
> work", the same dispiriting story that's kept complexity as a barrier to
> sophisticated computing.
>
> Software developers are happy to design bathrooms and buildings for
> other people, but let them choose the paint color? Their preferred
> lighting? Perhaps most important, the pathways in and out?
>
> Nope. We have "design patterns" all over the place, but no notion of
> the common pattern "ENTRANCE TRANSITION". No wonder we have such
> trouble estimating and completing work.
this is part of the stuff of extreme programming - setting up systems
that can grow organically - that's what i'm trying to do and that's why
i think xml is part of the solution
if you recast your economics you get a much better solution....
traditionally we try to get a pre-implementation cost/benefit and then
put walls around what we are doing so that the costs are contained -
after all we already know the benefits/cost savings - or do we?
most of my systems involve hundreds of tables, thousands of programs,
and who knows how many business rules (all explicitly stated in the data
dictionary by the way). but you can't plan these systems very well
because as already noted, the users don't even know the potential for
the system in advance. perhaps more importantly, the development of the
system and interaction between the programmers and users opens up new
ideas and possibilities for both groups. fixed specs pretty much
destroys that opportunity.
so if we go back to one of the more intriguing results of number theory
- probability of hitting a rational number when picking a random spot on
the number line - 0. i tend to regard user specs a bit like rational
numbers - easy to see, but there's an infinite number of possibilities
unexplored between each user's idea of what the system should be.
my economics is simple - the cost of implementation should never be more
than the anticipated 6 month saving - ie you're ahead after 12 months.
arbitrary but it's simple and satisfying for the customers. then it
doesn't matter how big or how long it takes to put a system in place
because the savings keep accumulating.
the simpler, more primitive parts of xml are excellent in this scenario.
the more complex parts start to break down the savings because of
implementation costs and times.
rick
|
