> Ann wrote:
>
> >>Granted - but I'd need to hear from somebody with a real application
> >>that could be improved by quotas.
>
> David Johnson wrote:
> >>
>
> > In a typical (for me) system: You have about 150 developers writing
> > code to interface with legacy back-end systems.
>
> From context, I gather that your developers are working on the
> production databases. Is that true?
>

It requires an act of God and the signature of three VP's for developers
to touch the production database. I wasn't clear.

> > You need sub-second
> > responsiveness for 8,000 users whose work lives rotate around system
> > capabilities, plus automated processes tracking some 50,000 pieces of
> > equipment and a similar number of current business transactions in real
> > time in a multi-terabyte database.
> >
> > Weekly spike loading is roughly 2.8 million transactions per hour.
> > Yearly spike is almost double that. System responsiveness during
> > spikes is not permitted to degrade noticeably, because it translates
> > directly to noticeable numbers of dollars per minute in lost
> > business.
>
> In short, a major and mission critical application,

Yes

> and if the
> assumption is correct, one that mixes real-time processing and
> software development. Exciting.

My fault. I was not clear. Separate development, QA, and production
environments.

> >
> > It is much better to have the query break in development than to hang
> > the users up for a minute in production. A "hard" break must be fixed
> > in development (the governor killed it, it's too long, figure out what's
> > wrong and make it work) - a long running query can be ignored and cause
> > delays in transacting business.
>
> Perhaps I'm being obtuse, but I don't see exactly where quotas would
> help. The ability for a developer to kill a query - absolutely, but
> what quota would you choose to limit?
>

Quotas help because, in a larger shop, personality politics often
overrides common sense. A quota is a hard, system measured rule that
cannot be "spun" in a meeting, and that can (must) be dealt with before
submitting work for pre-production peer reviews.

Developers sometimes get a bit slack or have different ideas about
testing. For people new to the systems, quotas act as automatic
enforcement of critical performance standards. Quotas enforce standards
anonymously and without bias, since the machine has no personal stake in
the outcome. The rule is simple and impersonal - if the application
breaks in the test environment, it isn't ready for production.

Quotas should not substitute for performance testing. But sadly, the
real world of enterprise development is that most developers do not
perform adequate performance testing. A quota on the development system
helps to minimize the damage that can be done when code is moved to the
production system.

What it amounts to is a quota on the development system is a form of the
"break it early" philosophy.

Another form that is sometimes seen is to give the developers under-
powered equipment, and save the high powered equipment for production.
The problem with the latter form is that you can't gain a realistic
understanding of the real performance bottlenecks unless your
development hardware and software are very close in their performance
characteristics to your production environment.