I don't know where your statement comes from, but Complexity does kill.
Applications that attempt to control more details of interaction are more
complex to write and debug. They are harder to update and replace. They
are more expensive to integrate with. Just observe the complexity of a
human resources application in large organizations and you will usually find
a large group of individuals who do nothing but implement systems like
Peoplesoft and Oracle, for years on end. These organizations are the
victims of the failure of our industry to correctly partition accounting,
Human Resources, document and records management, and workflow systems in a
standardized manner. This makes integration into a nightmare that never
ends.
Much better, in current thinking, is to have smaller applications that
communicate asynchronously using a managed message-passing structure (MSMQ,
UDDI/SOAP, MQ Series, Sonic ESB, Santeon XIP, WebLogic, etc). This is
called Service Oriented Architecture. Each application can be seperately
measured, developed, managed, and replaced, without affecting others. This
creates more of an "ecosystem" of applications, not just a heaping pile of
spaghetti.
Formal measurements for application size include Function Point Analysis
(
www.ifpug.org) and measurements based on lines of code (called KLOC). See
discussions of COCOMO to get more information on turning these measurements
into cost estimates.
I am working on a way to make use of Function Point Analysis in an Agile
Model. Stay tuned.
--- Nick
Brett said:
This statement mentions that complexity kills but can it be avoided?
"The kind of scalability I'm talking about is styem scale and compliexity.
Anyone who has written large scale systems knows that compliexity kills
(hint: if you don't count lines of code or use other formal metrics then
you're porbably not writing a big system)."
