[
Lists Home |
Date Index |
Thread Index
]
On Jan 2, 2004, at 7:08 PM, Rick Marshall wrote:
> how can you build business rules if you don't understand algebra at
> least and a fair competence at calculus, not to mention linear
> programming? come to think of it, how can you use a spreadsheet for
> more
> than adding columns?
>
> how can you build a large multi processor, multi-location processing
> system if you can't work with black boxes and predicate calculus.
There's been an on-and-off thread about complex systems, emergence,
etc. The lesson I get from it is that (at least arguably) you can't
understand the higher order, long-term, multi-party implications of
simple business rules even *with* predicate logic, linear programming,
etc.
It's hard to argue with the proposition that logic, set theory, and a
deep understanding of RDBMS dogma (or OO dogma, for that matter)
*should* help one build successful complex software systems.
Unfortunately, I don't know of much evidence that it really *does*
help.
This is not to suggest that hackery is as good as competent
engineering, but I will put forth the hypothesis that competent
software engineering is more dependent on an understanding of the human
factors of requirements gathering, project estimation and management,
and especially testing ... and less so on formalisms such as predicate
logic or the Rational Unified Process, etc.
Again, this is a hypothesis not an assertion of Truth; if there is
evidence against it, I'd be very pleased to hear about it.
>
>
> couple of simple rules: if 90% effort goes into the user interface
> chances are you won't recognise failure until it's way too late. if the
> depth of a tree is more than 5, most people (programmers included) will
> not manipulate it correctly - this applies as much to databases as
> documents.
I would tend to agree ...
>
> unfortunately xml will go the same way - it's not for end users, but
> it's a great tool for trained professional programmers and analysts.
> and
> it's a great place for silver bullet promises and to make money from
> those promises.
>
Yeah, but remember Al Snell's original point -- apparently even the
professional programmers at the huge companies that build the dominant
RDBMS systems apparently can't build query optimizers that actually
work with a high degree of confidence, forcing end users to re-write
the SQL to work around the limitations of the optimizer. (That was
certainly true the last time I did serious RDBMS work about 10 years
ago, I have no idea if it is still true ... but let's assume for the
sake of argument that it is). Is this because the professional
programmers are poorly trained? Because they don't use the formalisms
of RDBMS theory properly? [Bzzzt -- AFAIK SQL has no *formal*
relationship to RM theory and the current SQL standard never mentions
the relational model, but I may have read too many of of the anti-SQL
relational zealots' rants on the subject ;-) ] I doubt it --I suggest
that SQL is too complex to be fully understood by humans WITH OR
WITHOUT the assistance of set theory, predicate logic, RDBMS theory,
etc. Obviously we can do better than we currently do, but this will
take spec cleanups (which means POLITICS!), control of expectations,
and lots of time, along with more rigorous engineering.
I see only two ways forward, if we want more reliable software
(especially in the XML world):
- Simplify the specs to the point where formal methods and
state-of-the-art software engineering can really and truly "work".
- Just Deal With It by extensive testing, compilation and evaluation
of best practices, and other rigorous, but informal methods.
They're not mutually exclusive; the second would be greatly aided by
simplification and formal rigor, and the first would be more feasible
if there were a solid basis of codified experience with which to guide
the refactoring / formalization.
|
