[MUD-Dev] Re: Analysis and specification - the dirty words of mud development?

[Mike Sellers]

At 06:46 PM 6/10/98 -0700, Richard Woolcock wrote:
>Greg Munt wrote:
>[snip]
>
>> Many (I'd say 'all', but I can't allow myself to be that pessimistic) mud
>> developers that I know are not that at all, but, instead, are mud
>> implementors. Design is little more than an afterthought, so hopes of any
>> analysis being done are comedic, at best.
>> ...
>
>The importance of specifications and analysis lies in being able to turn=20
>around to the customer and say "well, you didn't ask for *that*... but for
>extra $$$ and a deadline slip we could do it for you".  Believe me - some
>companies depend on this happening to be able to get their software=
 completed
>within what are - initially - impossible deadlines.
>
>As far as a mud goes... The implementor/coder decides what s/he wants in=
 the
>mud and work to that.  They don't have to explain to other people exactly
>what the mud is going to be like, because they are the company AND the
>customer all rolled into one.

I couldn't disagree more.  The importance of analysis and design has much
more to do with managing architectural complexity, robustness, and
extensibility than it does with cloaking impending schedule slips.
Formalizing this process is *critical* on a multi-person team, but even on
a single-person team, you need to have _some_ level of overriding design so
that you don't end up with a patchwork quilt of what you felt like working
on that day.  Designing things in advance lets you see the long view and
then drill down when you need to without worrying that what you implement
today is going to give you a headache tomorrow. =20


In general, the better your analysis (what do we need?) and design (how do
we put it together?) work before you begin coding, the faster your
implementation time will be, the fewer bugs you'll have (especially really
deep, nasty, architectural bugs), and the more things you'll be able to add
later on when you think of them, without having to go retrofit everything
with global variables, spit, and chewing gum.  Not to mention that a strong
analysis and design makes it *much* more likely that the end product is
going to be much more usable if the users' needs were taken into
consideration from the start, as part of the overall analysis. =20

Of course, the analysis and design phase has a bad rap because it _feels_
like you're not getting anything done.  It's sort of a tortoise and hare
situation: you can design without coding for two weeks and get done with
development and major debugging (including adding a couple of unforeseen
but really cool features) in two months, or you can leap right into the
coding and be "almost done" with just a few nasty bugs lurking in there
after three or four months.  This has been shown over and over again in the
past twenty years of software engineering.  In an example from my own past,
in a former consulting life, I actually saw two virtually identical teams
start similar large projects at the same time --given the go-ahead in the
same meeting-- and have radically different results.  One group took the
time to do solid analysis and design work for about 2 months, while the
others said "we know what we're doing" and took off.  The second group got
kudos for having a demo to upper management first, though it turned out
their demo was just mocked-up screen shots that were later reworked several
times.  The first group soon took the lead, had a solid demo for mgmt after
about six months that actually worked, and astonishingly didn't miss a
single one of their dates on a two-year project, despite turnovers,
re-orgs, and all the normal travails of corporate life (kinda like having
finals interfere with getting your mud done :-) ).  The other project was
killed after about 30 months, though they insisted they were "almost done."
 This took place at a large Fortune 50 company that prides itself on its
software engineering methodologies...


>IMO a far more important phase in mud development is the scrutiny/testing=
=20
>phase, which is also very much lacking.  Why?  Because its boring as hell
>and no fun to do, and if its no fun the mud stops becoming a hobby.

Testing is a lot less onerous if you've done solid design work in advance.
:-) =20


--

Mike Sellers=A0=A0=A0=A0=A0=A0 Chief Creative Officer=A0=A0=A0=A0=A0=A0 The=
 Big Network
mike at bignetwork.com=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
<http://www.bignetwork.com/>http://www.bignetwork.com

             =A0=A0=A0=A0=A0=A0=A0=A0=A0 Fun=A0=A0 Is=A0=A0 Good =20