On Oct 16, 2007, at 2:51 PM, Adam Heath wrote:

The driving factor behind that priority is that in most large software it is complexity that kills projects and causes budgets to spiral out of control. As complexity increases the time and cost tends to increase in
a non-linear way, ie something like exponentially or logarithmically
instead of linearly. When I say complexity I mean general solution
complexity across hundreds of entities and services and screens, and not the complexity of a single service. The point of defining the scope and
purpose of a service is to limit the complexity of that one piece to
make it possible to write and maintain it with a reasonable volume of
requirements.

Exactly the point I'm trying to make.

If every CRUD implementation on every entity has it's own
implementation, then there are that many *more* things that have to be
learned.

Um, but that's NOT the point I was making. You're talking about sacrificing flexibility and ease of customization for ease of initial implementation. As for understanding and reading, once you've seen one of each pattern you've seen them all so there isn't anything more to keep a handle on, until you find an exception to the pattern you are used to and then it's important to look and understand why it is different, and yada yada yada.

-David

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to