As many others, I started off as a Fan of the original Blue Planet. I never really did think of ever joining that most glorious of teams, but as it happened, I managed to acquire some skills that were mildly useful. After dealing with Darius, Fury, General Battuta and the others for some time, I came to admire the way they worked as a team. The dynamics were just perfect. We all knew that we were working for Darius, and not once was it in doubt that this is his baby. We also are incredibly motivated to give this mod our best.
Anyway, after I managed to make a kick-ass set of interface art for WiH (using Flaming Sword's awesome Interface Templates app), I got invited to the BP beta test group. Soon after that, General B and Rian had to temporarily step away from the VA effort, I volunteered to help them with that, which brought me my BP badge.
Lessons learned
As I took a greater part in development, several things became clear to me, which I think are valuable pieces of information that other teams may profit from.
One thing that helped us is that the BP team is a small group of very dedicated, passionate people who not only give their best, but expect the same from others, and are not afraid to tell the others when they think that the work submitted does not meet the quality standards we have set for ourselves. This, of course, means that each of us has to deal with sometimes harsh criticism delivered in no uncertain terms. Stereotypical Primadonnas wouldn't last very long here, I imagine.
Another thing is that there is no question about who is in charge. If something doesn't meet the Darius test, it's out. While discussion is certainly encouraged, in the end, what Darius says goes.
Development tools
1. Debug builds
During our development, we use debug builds very, very often. We take great care to squash every warning, assertion and crash we encounter, and the result is an incredibly stable mod.
2. Immediate Feedback to the SCP
WiH was developed for 3.6.11/12. We literally couldn't make this work on .10, the performance increases we've seen in .11 and, of course, the added features which make our live so much easier. Just having debug builds that can perform on the same level as the regular .10 build was a great boon for development.
The other side of the medal is that, if you are using builds from the bleeding edge, you need to stay in contact with the coders. Provide feedback on what does and what doesn't work, and report any and all bugs you find that can not be traced back to your assets.
One added bonus to using dev builds was the improved error checking. .11/12 will report things that .10 cannot pick up, and fixing those improves the stability of the game on .10.
3. SVN
In October 2009, we made an arrangement with Zacam and rev_posix to get our data hosted on a SVN server. Before that, versions of the modpack were regularly compiled by Fury, and sent out to everyone. This of course meant that, occasionally, not everyone could be counted upon to have the latest version of it. Darius and Dilmah G are Australian, and subject to the horrible ISPs there. They have to be somewhat conscious about their monthly bandwidth usage, as their Internet will get throttled down to dialup speeds once they go over their quota.
SVN allows us to keep the download volume relatively small, as only the new and improved data needs to be downloaded. It also gives us the opportunity to go back and retrieve older versions of files, as all revisions are stored on the server.
The end result is that it's incredibly easy for us to get the data distributed, and tested out by the team, which makes our feedback cycle extremely short.
4. Play early, play often
A maxim I first heard in a video on the development of Civilization, uttered by the awesome Sid Meier, certainly proved its worth here. SVN allows us to put up early versions of missions, and test them to death. Again, short feedback cycles FTW. We can quickly throw out what doesn't work, and get the best possible version of the mission.
Especially FREDers should play their missions as often as possible, after every major change in fact. Just to make sure that the brilliant idea you just had actually does work.
5. Beta testers
Due to the extensive internal testing we did on the AoA DC, we figured we could get away with a very short beta phase. The original beta team that was hired (Snail and NGTM-1R) were unavailable for feedback (Snails Comp died literally a few days before we wanted to start the Beta, and NGTM-1R had RL duties to attend to). Fortunately, we were saved by the last-minute addition of blowfish (who you may know) and ubiquitous (who you may have heard in the DC), who both noted a variety of issues we simply overlooked. Again, using the power of SVN made implementing those fixes easy, and as a result, we could wrap up the Beta in two weeks, and release the product.
PS: Sorry for calling our awesome Testers "tools". I certainly do not mean to belittle their involvement in this.