Lewis and Clark Railroad (Part 2)

Development and QA work continues on the LINC, and the process for reporting and fixing issues is evolving nicely. What is really supporting this system is that MadMike has experience as a developer and thus we both have an understanding behind the necessity of bug and revision tracking. As I stated in Part 1 I don't want this to feel like work, so Mike and I added new controls to the process as the need for them arose. I'll try and explain the new processs without going too deep, which would be very easy for me to do because I have near six years of Configuration Management experience from my previous employer (from which I suffered from "too man hats syndrome" and left).

So what changes have we made? The first is simple enough. I had to REOPEN a bug. Mike had marked an issue as FIXED. I tested it with the latest route and found that the problem was still there.

REOPENED- 2011-07-13 Couple places near 45.91528/-122.40540 where the hill runs into the track. Still present along this track.

But why mark it REOPENED? Why not just remove the FIXED tag and move along? If I did this Mike or I could lose track if that issue was ever looked at. Its important to have a way to tell the other person 'Yes, I worked on this issue, and this is the status'.

The next change is actually more important and here I will need to keep myself in check. Mike added a Revision History to the notes and a matching revision number to the package (ex: CCCR-0041.rwp). This is a very powerful tool, and sadly we are still under utilizing it (remember play > work).

Revision List (latest will be at the top by number)

0.042 - Area markers, major grade crossing, sidings and siding markers to Battleground. - end of commercial operation currently HS hoppers are parked on the main

0.041 - redid the scenery at the north end of the BN trackage
added area markers for Burnt bridge, Ross, and Minnehaha

OK, so he calls it 'List', but its is a history of all the changes he has made to the route, and it tells me what to expect in the latest package, but there is more power behind this simple addition. For example if Mike or I said "I did this in version: blah" and then four versions later its gone or broken, we have a starting point to begin debugging from. Also, if you haven't guessed already it, it also provides us with backups of the route, which is one of the three cardinal rules of route building.

How is this being underused? In several ways, but I will focus on one. Mike should list on the next to his FIXED tag which version I can verify it in, but more importantly I should list which version CLOSED the issues with. Once again this ties into making our baseline so if we need to we know how far to turn back the clock.

We are trying to keep things simple, and I think MadMike and I are doing a good job. Of course there are tools out in the software development world that do all of this (Jira, Perforce, TestTrack, fill in your favorite tool here..., plus tons more!) for us, and some of those tools are free... but all of this is suppose to be fun. What we are trying to do is mitigate the cost of all the headaches if something does go wrong. There is nothing worse than seeing your work destroyed by something as simple as a bad attribute in your XML hiding inside one of a hundred BIN files.

Oh... how is the LINC coming along? Quite nicely, though the forests may not get in until September 23rd.