Those of you who have followed the developments of the Network Addon Mod (NAM) in recent times have likely noticed that the pace at which new versions have been released has increased dramatically in the past 18 months. Indeed, after NAM 37 took nearly 3 years, finally making it to an official public release in July 2020, in a little bit more than half that time, we’ve released 7 more versions, including the new NAM 44 release. We’ve also dramatically increased the size of the development team, which went from being a skeleton crew, with a mere three active developers, to one with over 30 members contributing in various capacities, approaching a size it hasn’t been since nearly a decade ago.
The fact that a computer game mod that has been continually developed since 2004–for a game released on 2003–has had this much going on nearly two decades later would likely be a surprise to many. Indeed, it’s a surprise to me, too, and as someone who has been involved for 15 years as of this past February, a very pleasant one. And I thought I would share my experiences as to what has changed in the past 2 years in order to make this sudden snowballing of activity with the NAM possible.
Those of you who have followed the NAM project over the past 5 years know at least some of the story of the infamous NAM 37, some of which I’ve shared here at SimTarkus. Long story short, that whole development cycle was cursed. Development on content intended for NAM 37 had already started before NAM 36 was released in September 2017. However, many of those projects we started encountered significant roadblocks (including the “Tidal Flow” issues that stymied the RealExpressway, the originally-intended flagship project for the cycle), causing them to get shelved and forcing us back to the drawing board constantly. And our very small development team, even with some slight expansion (including the key additions of our Bridge Department Lead, Kitsune, and SC4 Renaissance man Tyberius06), was often waylaid with heavy cases of Real Life (RL).
Once we finally did get things on track again, assembling the first complete internal build for the cycle, the aptly named NAM 37 Alpha Build 01 (NAM 37 A01 for short, also since referred to as “the nuclear artifact”), our installer system–which had already become a bit shaky with NAM 36–completely blew apart at the seams, the product of trying to corral the increasingly dense array of crosslinks between optional components, and the complexities of its interactions with the NAM Controller Compiler utility. It was routinely completely skipping the compilation of the NAM Controller, and also the failsafe of installing a full, pre-compiled one–and given that the NAM Controller contains all the RUL code required for the NAM’s network additions to be built in-game, this was a fatal issue.
This situation resulted in a yearlong period of trying to completely re-engineer the mod’s file architecture, in order to reduce the internal complexity, and allow for it to be compatible with a different installer system. And given the fact that both eggman121 and myself worked in “essential” industries, the pandemic did not really slow RL down for us. The whole cycle was one, long struggle for survival for the NAM–and somehow, we did survive. But in order to keep surviving, it was clear we needed to do something different. The development hell of NAM 37 could not happen again.
On April 18th, less than a week before we finally issued a public release candidate for NAM 37 (prior to the official release in July 2020), I made a lengthy and rather frank post in our private development boards at SC4 Devotion, entitled “Guidance on NAM Development and Build Cycles – NAM 38 and Beyond”, or as it could be jokingly called, “the NAMifesto”. The NAMifesto basically addressed some of the long-standing elephants in the room (which had arguably been there since Tropod retired as team lead back in late 2005), and laid out a plan for how we could keep NAM 37 from happening again, which we’ve successfully implemented since then. My colleague Lucario Boricua put together this annotated version of our GitHub code commit graph, which illustrates how things have gone since the beginning of the “Monolithic Era” of the NAM (starting in 2013 with the release of the infamous NAM 31–our GitHub depository was started shortly before that version’s debut). As you can see, the “Agile Era” section, corresponding to our activities after the release of NAM 37, has a consistent flurry of activity, with much higher peaks than were seen at any point during the “Monolithic Era” that preceded it.
One of the curious things with NAM development, which has been consistent throughout my 15 years on the team, is that it’s a largely freewheeling endeavor, and rather improvisatory in nature, especially during early phases of a release cycle. There’s no premeditated, centralized planning of releases or feature sets, and developers are generally not told what to do. Instead, they tend to work on what projects interest them, often in line with a sort of mutually-agreed-upon roadmap of where the NAM is headed, either solo or in collaboration with other developers, and there’s a sense of shared responsibility for seeing things through to a releasable state. Allowing developers with a mutual sense of purpose that level of autonomy is really the key to what has made our development processes and our working environment tick.
One of the structural issues we had often faced, however, was the fact that as the scale and difficulty of projects increased as the NAM evolved, and as RL had varying impact on developers throughout the release cycles, this could sometimes cause already-long cycles to be prolonged even further. We worked until we felt a given feature set was “complete enough”, however long that took, and that often spiraled into development hell, as developers got used to the long cycles and would give into the temptation to make more stuff. We’d pencil in rough target dates, and often consistently blow past them–NAM 28, for instance, was initially discussed among the team as a November 2009 release. It ended up being a May 2010 release–and despite also coming alongside the long-awaited debut of the Network Widening Mod (NWM, which was then a “separate-download plugin”), had a number of really ugly bugs that made it one of the worst releases the NAM Team ever made.
The early NAM releases were usually quick affairs–in fact, during the first two years of the NAM, 2004 and 2005, the average length of a release cycle was about 3 weeks. But after Tropod’s retirement from team lead duties, following the release of NAM 19 in late 2005, the average length ballooned to 9 months, and was trending toward cycles exceeding one year in length, beginning with NAM 30 in 2011, the last of the “Modular Era” releases. The length of the development cycles did not lead to a better product, either, as developers and testers became bored and frustrated (myself included), and lost focus. The thought among developers was “if I don’t get this into this next NAM, I’ll have to wait another year, maybe longer.”
The goal of the NAMifesto was to put a stop to this. The solution was to ultimately go back to something that more resembled the Tropod-Era NAM–back when the team was still called “Modd Squad Transport”. I proposed:
- A hard cap on release cycle length, with enforcement of that cap.
- Avoiding the sorts of major respecification projects that had become ubiquitous in NAM development during the 2010s, unless there was a very clear benefit to them.
- Not being afraid to cut content that wasn’t going to be ready in time for meeting the hard cap.
- Re-framing larger-scale projects as being things that could span over multiple releases (either by being broken into phases, or developed in the background), while drawing attention to the fact that being “three versions out” under this paradigm would still be sooner than “next version” under the old way.
The other members of the team, having some of the same frustrations I did after the joyless experience of NAM 37’s cycle, were willing to give it a shot, and entrusted me to help establish this plan as an official team lead (the first time we’ve really had one since smoncrie’s short post-Tropod tenure as team lead in 2005-2006, before RL forced him to take what ended up being a two-year hiatus). In many ways, what we ultimately built is an “Agile-like” development process. While some in the software community may bristle at “the a-word”, and conjure up mental images of rapid-but-buggy releases, and heavy-handed project managers demanding constant status updates, the NAM Team’s particular “Agile-like” approach has avoided establishing the bureaucracy of formal scrums, sprints, and the like. Instead, it has been about achieving results, doing so through a sustainable, repeatable process, and maintaining the “chaotic good” that characterizes NAM development at its best.
While the NAM Team policy has long been to avoid discussing release dates and timelines with the public (the one time we did was the disastrous NAM 31 cycle), it is worth noting that we have successfully met our “cap” with every release cycle since, with the average development cycle length for an Agile-Era NAM release being 3 months.
(Version 1 cycle length technically unknown)
The increased focus has allowed us to more rapidly deal with bug reports and technical issues, and remain focused on our developmental tasks, resulting in more cohesive releases that have often ended up with larger feature sets than our previous marathon cycles, and, in contrast to the stereotypes about Agile development (and pre-Agile NAM releases with much longer cycles), fewer bugs. If a feature is not ready, we’ll simply cut it, and revisit it in a near future release cycle, thereby allowing it to reach a stable, mature state that’s ready for public consumption when it does finally debut. The shortened release cadence has helped tremendously in curbing the problematic, artificial sense of urgency that the old way of doing things pushed on our developers.
The way in which these changes have reinvigorated NAM development efforts has also gotten quite a number of new NAMites interested in learning some necessary skills to contribute. We’ve been readily upskilling the newer team members in various developmental tasks, thereby increasing our throughput that much more. Based on Lucario Boricua’s calculations from our GitHub activities, the NAM Team in this “Agile Era” is currently 4.4 times more productive than in the previous “Monolithic Era” (from NAM 31 in 2013, up to the eventual release of NAM 37 in 2020).
We’ve also been very careful with our efforts to grow the team, by bringing on those whose aptitudes, personalities, and maturity levels will be a good fit for the NAM ecosystem. Some past issues with personality conflicts have nearly derailed the entire NAM effort (we lost most our development team as the result of one that occurred during the NAM 33 cycle in 2015), so we’ve refined our recruitment methods (which are still invitation-only) with the goal of bringing in people who will be able to work respectfully with other NAMites. In fact, we’re more prone to focus on that aspect, as there’s many ways NAMites can contribute meaningfully to the overall effort.
The one other big difference that has come about during these more recent release cycles is the move toward using private Discord channels as a communication tool, rather than focusing on the forums (which we still utilize in some capacity). The live, active nature of Discord has helped create a more collaborative, responsive team environment, which has accelerated development and helped foster team unity. While we might not have the formalized scrums and stand-ups that a proper “Agile” development team might have, this does allow us regular, natural communication, without artifice.
There are still some areas where we are refining the process, but all in all, the changes brought about by the NAMifesto have probably produced the most productive and harmonious iteration of the NAM Team that I’ve seen in my 15 years involved with the project. Here’s to hoping we can continue it for many more.
-Tarkus