[MUD-Dev] Jeff's Rant: A World Full of Wheel-Makers

[John Buehler]

Bruce writes:

> An old list member, Jeff Kesselman wrote:

> http://www.javagaming.org/WeeklyRant/weeklyrant.html

> Jeff's Rant: A World Full of Wheel-Makers

> Nothing frustrates me more then the amount of duplication of effort
> going on the in games industry.

This is true regardless of the software domain.  Reinventing what has
gone before is simply the standard technique for software
'engineering'.

> The answer has been known for a long time, reuse of code and
> component-ware. Unfortunately the cards are all stacked against such
> approaches today. You would think that at least within a shop there
> would be code reuse. However my experiences in the industry suggest
> that this almost never happens.  Why?  Ironically the reason I've
> seen has nothing to do with engineering.  It has to do with
> bookkeeping.

> The typical accounting model for game projects looks at each game
> project individually as a profit/loss center.  A given producer is
> responsible for tracking the costs of producing the game and seeing
> that it ultimately earns more then it cost to produce and market.  A
> producer who consistently generates profit will do very well in the
> industry. A producer who produces a string of losses will soon be
> looking for a new job. As such it behooves the producer to keep his
> costs down.

At Microsoft, there is certainly a push towards building utilities and
tools, such as forms packages, database access layers, graphics
hardware abstraction packages and the like.  These things typically
only happen when management gets wind of the fact that there are too
many duplicate projects building the exact same code.  So Jeff is
right on target.  Most all engineers that I encounter are very much
interested in getting past the pathetic techniques that we have today.
I gave up on my software engineering career after 17 years largely for
this very reason.  I was writing the same danged code at the end of my
career as I was at the beginning.  That time working with components
kept my career alive for an extra couple years.

> You might think that reusable code would reduce costs, and it would,
> but that code has to come from somewhere.  Reusable code initially
> costs more to produce then one-off problem-specific hacks.  There is
> no incentive in the system for the producer to spend a penny on
> future games, and every reason not too if it will impact his current
> game's budget. As a result, game engineers are directed and
> scheduled to produce only what is needed for the current project and
> not a line of code more. The reason is that there is no global
> accounting that credits people for doing work that helps the company
> produce multiple products.

There is also no push back from consumers to get companies to stop
producing the crap that they do.  I believe that this is true due to
the lack of competition - nobody is cranking out high quality software
that can compete at the feature level with the buggy stuff.  Microsoft
is very good at walking the line between features and quality.  Where
the quality lacks, there are features to make sure that it's not too
painful.

> Some game companies attempt to solve this be creating separate "R&D"
> or "Tool" engineering groups.  The role of these groups is to think
> further ahead then just the next game and produce technologies that
> will benefit many game projects. Unfortunately these groups still
> often fall prey to the balance sheet.

So true.

> So what are the solutions? If I had a 100% sure fire fix this would
> be an MBA thesis, not a rant.  I do have some suggestions though:
> Stop thinking in terms of individual products and start thinking in
> terms of suites of products built on top of generic engines.  I
> don't mean very game specific engines like the Quake engine, but
> rather game genre and or functional engines, such as Sierra Online
> used.  (Very successfully, I might add, until they were bought out
> by someone who didn't understand their business model.)

I certainly agree with this attitude shift, but I suspect that the
first war that needs to be won is that of the most primitive
components and the infrastructure needed in the software industry as a
whole for ensuring that components become practical.  I don't know
about you folks, but I don't want to write another balanced binary
tree, or a quad-tree or the thirty or so other algorithmics that we
carry around in our heads and in old code.  Surely these can be nailed
down.  They are known quantities.

The more domain specific we go, the less the stability in algorithms
and data and the less willing companies are to sell their components
at anything approaching a reasonable cost.  The wider the appeal, the
higher the volume of sales, and the more domain specific, the less
broad the appeal.  This is part of the infrastructure I was referring
to in the prior paragraph.

> Fight the NIH complex. There are specialists out there who want to
> write components for us. Lets try to encourage that by looking for
> external solutions first and only engineering either the core unique
> parts of our games or places where the externally available
> components can't be reasonably made to fit. At times this may mean
> diverging slightly from our original game designs but the payoffs
> are well worth it.

While NIH makes me want to beat my head against walls sometimes, I
find myself doing it myself.  I do it because I love the creative
aspects of my job.  I don't think that encouraging NIH to vanish is
necessarily a good thing.  What we might want to do instead is to let
NIH run rampant, but at a higher level.  Let's not reinvent *every*
wheel, but let's also not give up on coming up with new solutions to
problems.

I firmly believe that once quality (i.e. no-brainer) components are
available, engineers will snap them up and start building new packages
that they couldn't build before because of the resources needed to
build them from scratch.  Engineers want to build new things that have
never been done before.  If they could devote their creative energies
to new solutions, we'd be making some amazing progress.  I desperately
look forward to the days when I go to the web to search through
libraries of components for the ones that I need on my project and
then, after figuring out the licensing fees for the ones I want to
use, decide how much I can afford to charge for my product and how
much additional time I want to spend on writing new components.  And
further considering how I might turn them into a revenue stream.

> Industry Standards!  The best way to encourage both the development
> and sue of component ware is through the development of industry
> standard APIs and data formats.  These allow code to be easily
> separated while still communicating closely in the final
> application.  Furthermore they reduce the risk of using third party
> components by providing the possibility of plug-replacing those that
> might not live up to our hopes or needs.

Agreed.  One way that this may come into being is when a software
powerhouse simply starts doing it, producing a de facto standard that
the rest of the world will follow.  Not a standard like CORBA, that
isn't in widespread use, but a standard that every Tom, Dick and
Harriet is coding to because it's in their face and it works.

> Number One above is a change that has to happen in game production
> management.  I'd call on those in such management positions to
> consider this and discuss it with your technical experts.

I'd be very surprised if the game industry took the lead in such a
thing.  I'd certainly be in the front row of those cheering the
attempt, however.

I've often wondered what would happen to the software world if CPU
speeds, data capacities and communication speeds levelled off.  Would
the loss of a moving target permit more in-depth examinations of how
to build software that satisfies certain interactivity and data
capacity requirements?  I almost yearn for the day when the computer
itself becomes more of a standard.

> By contrast Two and Three are things engineers can directly address
> and make happen.  We ARE the technical experts and these are choices
> we can make or at least strongly encourage our management to make. A
> focus on Java API's for gaming seeks to address these very problems.

Be careful what you wish for.  You might get it.

It's pretty scary to think of getting all this stuff standardized, but
done in some heinous way that we're stuck with for 20 years until it
becomes so unweildy that somebody decides it has to change.  Not
unlike where we are today.

Good thoughts from Jeff.

JB

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev