Strategic Primer: Lessons learned from the past months

Over the past several months, the current campaign of Strategic Primer has essentially stalled, and the development of my suite of assistive programs has made little real progress despite a great deal of (albeit intermittent) effort. Today I’d like to describe some lessons I’ve (hopefully) learned from this.

The first lesson is to, if possible, test whether a dubious feature is workable before starting on it. As I mentioned in May in my announcement of/request-for-comment on “yet another resolution change“, quadrupling the resolution had led to unreasonable performance problems. But I would have been able to see that before I went to all the trouble of the first resolution change (and the associated additions to the code) if I’d bothered to test—I could easily have created a map of the size I proposed and run both my existing performance tests and the map viewer itself on that test data, which would quickly have exposed the problem, instead of waiting until the problems became too annoying with “real” data.

The second lesson is to work first on features that are actually needed or wanted, when I know of some, rather than going in totally new directions. There are several features that have been on my “roadmap” for months, since well before the resolution-increase debacle began, that I’ve essentially ignored. Some of them are items I can’t think how to begin, but some are merely waiting for me to buckle down and do them.

A third lesson—which I should have learned from the first turn—is to focus more on the campaign than the tools. We’d be better off if I’d just run the next turn using existing tools, instead of going through all the wheel-spinning in the map viewer—though a few quick, real improvements to the tools that would improve the players’ experience before hastening to the turn would have been even better.

One last lesson, though not from this period, is to (at least in Java …) avoid “suites” of programs in favor of one multifaceted program. Originally, the map viewer was to be the first in a group of separate but related programs to help me and the players, but the few times I’ve started working on a separate program using its own separate data structures, development has stalled almost immediately, while I’ve seen more significant (though still limited) success adding orthogonal features to the map viewer and extending the map file format. Furthermore, since I’m developing in Java and distributing the code of the “suite” as a Java archive (and platform-specific executables wrapping it) it’s somewhat difficult for an “end user” to run programs other than the one I designated as the “main” one. (Though that’d be simple enough to work around with a program-chooser program, at the cost of yet more complexity.) Adding new functionality as features of the existing “main” program neatly avoids this issue.

Comments or questions? Is there something else I should have learned?

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s