[NCLUG] programming question

Charles Clarke clarke at clarkecomputer.com
Sun Jul 1 13:28:14 MDT 2001


I agree that you can grow too fast, especially for a legacy app, and that
you do reach a point where someone who can fix your bottleneck area is
cheaper than throwing hardware at it.  Someone who understand concurrency
and can design for it is well worth it.  A good design will scale up
better than a bad one.

I disagree that just web-enabling a system will generate you a thousand
fold increase in sales(unless your sales sucked before!).  The whole rest
of your business won't be able to handle it if it does, so the app isn't
your bottleneck anymore anyway.  And hopefully your business model is
designed so that the more sales you have, the more money you make so you
can afford to throw $$$ at hardware and programmers.  If it isn't, you've
got an inherent flaw.  And yes, a bad initial design may need to be
scrapped for the real thing.

charles

On Sun, 1 Jul 2001, Gary Rogers wrote:

> Date: Sun, 1 Jul 2001 10:14:47 -0600
> From: Gary Rogers <garyr at dmin.net>
> Reply-To: nclug at nclug.org
> To: nclug at nclug.org
> Subject: Re: [NCLUG] programming question
> 
> Not when you're dealing with systems that are (or percieved to be) mission
> critical. Take a hypothetical situation:
> 
> You decide to replace your current legacy order fullfilment solution with a
> new Web-Based application. You roll it out to your company of 3000 and
> everything is fine, order fullfillment is faster, things are going out the
> door faster, more efficiently, you don't require as much training of your
> warehouse and sales staff, and thus can afford to get 'cheaper' workers.
> Now, management decides to web-enanable this system, re-using code that was
> designed for the Intranet. Now instead of haveing a peak load of 3000 users
> you have a peak load of potentially MILLIONS of users. Granted it will
> probably never be that, but then you never really saw a peak of 3000 users
> either. True you CAN throw more resources at the problem, but they have just
> taken a larger cost than a day or two of programming time. In fact this
> situation isn't too far off from e-bay in the early days. Trying to run
> in-efficient code at Internet scales can bite you directly in the posterior
> (Mine is growing back slowly ;)
> 
> Now all that said, in my experience on the Web a good PL/SQL guy is worth
> his weight in gold, as that's where I've seen the bottlenecks in the systems
> I've administered. Of course milage will vary (on & off?) with systems that
> are now geered to massive numbers of concurrent users. Personally I'd say
> you're better off documenting than adding functionality, but then that's
> another holy war ;)
> 
> g:wq
> 
> ----- Original Message -----
> From: "Charles Clarke" <clarke at clarkecomputer.com>
> To: <nclug at nclug.org>
> Sent: Sunday, July 01, 2001 9:42 AM
> Subject: Re: [NCLUG] programming question
> 
> 
> > On Sun, 1 Jul 2001, Evelyn Mitchell wrote:
> >
> > > It's really important to remember that programmer attention is the
> > > one thing in short supply anymore. CPU speed, Disk space, network
> > > speed.. all have improved so much that optimizing for them is probably
> > > a waste of your time. Yes, there are corner cases where an app is
> > > just too slow, and needs to be fixed. But in all other cases, you're
> > > probably better off adding new functionality than to be optimizing.
> >
> > And a faster machine/more memory/larger disk probably costs less than a
> > day or two of programming time.
> >
> >
> > _______________________________________________
> > NCLUG mailing list
> > NCLUG at nclug.org
> > http://www.nclug.org/mailman/listinfo/nclug
> >
> 
> _______________________________________________
> NCLUG mailing list
> NCLUG at nclug.org
> http://www.nclug.org/mailman/listinfo/nclug
> 


--------------------------------------------------------------------------
 Domain hosting from $15/month with error log analysis and link checking.
 http://www.clarkecomputer.com/sig.html       domains at clarkecomputer.com




More information about the NCLUG mailing list