[MUD-Dev] DAoC dev team (was: MMORPG Comparison (UO, EQ, AC, AO, DAoC))

[Daniel.Harman at barclayscapital.com]

From: Robin Lee Powell [mailto:rlpowell at digitalkingdom.org]
> On Tue, Oct 16, 2001 at 04:24:27PM +0200, Ola Fosheim Gr?stad wrote:
>> Dave Rickey wrote:
>>> From: Eli Stevens <listsub at wickedgrey.com>
  
>>>> What you describe sounds a lot like Extreme Programming (XP).
>>>> I
  
>>> I haven't heard the term before, and don't recall seeing those
>>> books on any shelves around here, but I can't say with any
>>> certainty
  
>> Extreme Programming is a methodology based on the idea that "what
>> is worth doing" should be done to the extreme, and what is not
>> all that useful should not be done at all. Thus no case tools, no
>> documentation (except comments),
 
> Now _that_ part I'm not happy with.  Everything else I mostly by,
> although I like design documentation.
 
> Of course, my memory is absolutely pathetic, so that may have
> something to do with it.  Also, I've had to take over large pieces
> of undocumented code from others.  It's a nightmare.

I was going to comment on XP earlier, but deleted my post - oh
well. With regard to taking over undocumented code, thats not
*meant* to happen. All coding is supposed to happen in pairs, so
that there is no such thing as someone elses section of code. The
team is meant to rotate pair programming desk and partners so that
everyone knows all the code base.

My previous team of about 15 developers + 3-5 Business Analysts/QA
tried XP on a project which was mostly in its maintenance phase. The
results were mixed.

  - Pair programming - This definitely lowered productivity and
  although the code may have been better quality, thats very hard to
  measure so never loved by management. It also gives a sweat shop
  feel to the place as you are having to concentrate non-stop all
  day. Personally, I like a bit of time to tend emails/see whats
  happening in the world. In theory it would be a nice way of
  improving everyones coding skills as you will see new patterns
  etc.  That requires egoless programming though. Here thats a
  contradiction in terms...

  - Automated Test Harness - This was a lot of work to
  create/maintain both the harness and the test cases. We only did
  it at a unit testing level as we had real people to do the front
  end stuff. Getting buy in from the team to write their test cases
  was painful at times. Also the unit tests were only really useful
  when major refactoring had occured as they allowed you to check
  you hadn't made any fundamental changes to function.

  - Merciless Refactoring - We did a little bit of this, but its
  hard and scarey. Also the users have zero tolerance for
  introducing bugs in components that haven't visually changed. Part
  of the problem for us was that we were having to do a LOT of
  enhancements and spending a month refactoring would probably have
  got people in deep trouble.

  - Index card use case type things - Definitely didn't work here,
  the users were never really interested in refining requirements,
  they just complain when you aren't psychic.

Anyway, I'm not sure it worked for us although some aspects could be
taken away.

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