Author Topic: High Level Design Series: Infrastructure & Proj Mgmt (2)  (Read 1887 times)

Offline Shem (aka MadScientist)

  • Pottymouth
  • *
  • Posts: 33
  • Are We not MUD?
    • View Profile
    • MUD(R): Are We Not MUD?!? (D.R.A&.G.O.N) Project:
High Level Design Series: Infrastructure & Proj Mgmt (2)
« on: August 02, 2012, 06:36:11 PM »
As I iterate through a semblance of a LEAN/Agile process, I've been doing some thinking about ProjMgmt/Iteration Planning.  In the context of a development environment with 99+% uptime; little build/release management structure needed from the outside, and a shared sandbox/integration/production environment (typically) ... it sets a lot of the normal Product Release LifeCycle assumptions on their head.
 
Given that, is this even a useful question?  I think so.  Being able to jump in and "code something", at "any time" as the oppurtunity strikes; is perfect from the traditional Dev/Mgmt wishlist.  However, the processes and infrastructure allow more "Look Before You Leap" opportunities; which I believe result in better quality products in more efficient iterations.   For example, I could point at the 10/10 Rule as a reference to why Product Planning (and therefore, Process) is worth it.  "Quality is Free" is a oft misquoted phrase, especially in ProjMgmt.  My paraphrase would be:  "Quality is an EXPENSIVE Investment in your Product(s); however it pays for itself in the end.  Customer Loyalty, that comes with it, is Free."
 
So, what about MUDs?  I mean, MUD Admins are almost always Small (Volunteer?) Teams, working on Non Commercial Projects; in our spare time as personal Hobbies.  Shouldn't we jump in and do whatever is most interesting, ignoring all that process crap that we have to do in our professional lives?  Yes! (&& No)
 
If you just want to tinker, then obviously do whatever amuses you.  If you are planning to support Players, at some point you will have to fix whatever defects they found that are blocking them from having fun in your MUD.  Defects live in Colonies; finding one is often the tip of an Iceburg.  Getting pestered by players to fix a bug when I want to code something else makes me grumpy.  Spending hours tracking down small typos because I've never seen a MUD with a good debug framework/regression test harness makes me grumpier.  Realizing that I made bad decisions and have to go back and rewrite a whole platform layer to fix the root of the problem just (#$#$!) ... upsets me more.
 
I prefer to defend my coding time proactively by trying to Avoid Writing As Many Defects As Possible in the first place.  Plus, I like the feeling of knowing I produced the best quality work I possibly could, within the limits of my resources.  Medieval Guilds had Master's Marks as a way of Competing (/advertising) by Quality, instead of Price. I want my name, on my work, to be it's own Master's Mark.  (i.e. Quality Inside)
 
So, back to specifics ...
 
Here is a rough Template of an Iteration (work hours, 1 person).  Do you folks have any thoughts on implimenting these in the context of MUD development?  Since I'm currently the only person on the project, I have to plan for wearing ALL of these hats simultaneously.:
 
Iteration Planning (Template):
  • (20%) ==== < < < Project Management > > > ====
  • (5%)   Retrospective (Iteration n-1)
  • (5%)   Demo/Show&Tell (Iteration n-1)
  • (10%) Iteration Planning: Stories & Features (Iteration n)
  • (60%) ==== < < < Development & QA > > > ====
  • (45%) Product Development (New Features, Unit Testing)
  • (15%) QA & Test (New Features, Regression/Load/etc Testing)
  • (20%) ==== < < < Product Support / BETA Testing > > > ====
  • (5%)   UAT/Beta Testing Triage (Player Feedback:  Iteration n--)
  • (10%) Defect Fixes & Patches (UAT Support)
  • (5%)   Documentation & Training (Features for Iteration n)
  • ==================================================== 100%

Does anyone use a similar process?  I linked (below) an interesting high level article that discusses the Planning vs Support Time Management idea further.  Comments?  Ideas?

External Links:
http://www.superwebdeveloper.com/2009/11/25/the-incredible-rate-of-diminishing-returns-of-fixing-software-bugs/
« Last Edit: August 02, 2012, 06:54:35 PM by Shem (aka MadScientist) »
Shem R-MUD-1 & 2
X-Admin Rhovania (1993-1995)
D.R.A&.G.O.N. Writer

Offline Shem (aka MadScientist)

  • Pottymouth
  • *
  • Posts: 33
  • Are We not MUD?
    • View Profile
    • MUD(R): Are We Not MUD?!? (D.R.A&.G.O.N) Project:
Re: High Level Design Series: Infrastructure & Proj Mgmt (2)
« Reply #1 on: August 02, 2012, 07:17:43 PM »
Does Anyone have any good ideas for how to solve that "Test/Debug" problem within LP MUDs I mentioned above?  I've been pondering it; but haven't come up with any great ideas so far.
 
Ideally, I could impliment some sort of Unit/Integration/Regression/etc Test (or DEBUG) infrastructure into the MUDLib Object Model.  Even a simple "Smoke Test" (does it load without blowing up & creating smoke) is a start; however I'd like to extend it to all of the normal QA functions such as:
 
Common QA Test (by Type):
  • Smoke Test (Build/Integration Process Sanity Spot Check)
  • Functional (Verification & Validation; "Good, Bad, & Ugly")
  • Installation / Setup / Config / Compatibility
  • Regression (Previous Bugs Still Fixed?)  /* Goal is always to Automate all most of this */
  • Security / Game Cheating / Balance
  • Load / Stress / Performance
  • Usability / *UI
  • Localization (EFIGS-JK, etc)
  • Accessibility
  • UAT / BETA / 3rd Party
Again, I'm more interested in PREVENTING (QA) defects than FINDING/FIXING (TESTing) them; however this Yin-Yang picture (below) describes that balance well.
 
External Links:
http://issinfotech.com/quality-assurance-and-testing/
Shem R-MUD-1 & 2
X-Admin Rhovania (1993-1995)
D.R.A&.G.O.N. Writer