[MUD-Dev] Crunch time

[katie at stickydata.com]

Way too many quotes to keep track of!

An analogy.  I have been the CEO of a software development (loosely
- we have done a lot of things) company.  We had an employee for a
while.  We all liked him very much, and he was extremely smart.  He
was a (theoretically) brilliant developer.

He was also busy.  All the time.  He slept in the office at least a
couple times a week.  We'd constantly find him under his desk,
asleep.

He never, ever, ever finished a goddamned thing.

Every project, he'd swear on his mother's grave about the timeframes
he was giving our poor project manager.  And the work he did manage
to squeeze out was *really* good - good enough to put us in a
serious quandary.  That, combined with the fact that he was really
pretty decent on a sales call - which developers often are not.  He
also had many excellent ideas for software development processes -
UML, extreme programming, QA rounding, prototyping, etc.  Didn't do
much good, though, since we never actually saw a result other than
apparently preventing him from sleeping in his own bed.  Eventually,
we parted on decent terms, but to no one's chagrin.

My point to all of the above is that software development is often
like trying to quantify why a brilliant pianist touches one with his
or her music.

Genius and the end result of genius are not one and the same.  In my
experience, any industry that relies at all upon creativity has a
risk factor that is represented by the creative people.  I have
learned to take my programmers' time estimates and - literally -
quadruple those estimates, which usually gives me, if I'm careful,
about half as much as the initial estimate in extra time.

I've been on both sides of this battle, too.  My background is
primarily creative, albeit in a different area than games.  When
you're trying to create something great, project managers (and
clients) SUCK.  When you're trying to make a deadline as a project
manager, artists SUCK.

The only solution I have ever found to this problem is to
micromanage feature lists (not the developers, the lists),
over-estimate time in every possible area, refuse to allocate
deadlines until specific functionality documentation has been
produced, and make absolutely sure that the problems that are taking
up a lot of time are the problems we WANT to have taking up the
time, not some buggery little stupid thing that's going to waste
three weeks that no one will ever even notice.  Of course, the
latter - and, imho, most important - requires almost prescient
anticipation of the problems that lie ahead, not to mention a
willingness to avoid the temptation to tell investors, bosses,
marketing, and the press that everything is coming up roses, you're
going to triumph over all the evils your (clearly lesser)
predecessors encountered, your developers are eternal sleepless
wellsprings of budget-conscious solutions, and your artists have
been delivered by the hand of God himself and are endowed with not
only boundless creativity but the ability to channel that in a way
that instantly translates into C++.

For whatever reason - and again I think the chief culprit here is
complexity and the esoteric nature of development - very few project
managers or similar want to admit that they really haven't the
faintest idea what the heck is going on.  At some point, some code
will be produced, and hopefully it will be code that does what the
code was supposed to do.  At some point, a level design and
creatures will be delivered, and since those are at least visual we
can pretty much bargain that they'll at a minimum LOOK like we want
them to.  And if we're really, really lucky, marketing won't pop in
on any of those presentation meetings.

Of course, it's impractical to just say "hey, well, whatever happens
happens."  Even though that is often what actually DOES happen, just
not openly.  That said, I am with those who have said making room
for deviations from the original plan is the only way to really come
close to an accurate schedule.  This is a funny industry - as are
most tech-centric industries.  There's not a lot we can do about
that, other than create space for it to develop at least a little
bit organically.

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