What's taking so long?? (a.k.a. Where is my software release?)

  • <Full disclosure: I am not an employee of MA Lighting International or MA Lighting Technology. However, I am an employee of a distributor of MA Lighting products, and also a Beta Tester.>


    As a new version of grandMA3 software approaches and everyone gets antsy for its release, some common refrains I hear include the likes of "What's taking so long?", and "Is there a scheduled release date?", and "Can I see the release notes?", among others. And inevitably these choruses get louder in the echo chamber of social media. So I thought maybe a brief explainer of what goes into / leads up to a software release might be interesting for people to know.


    Without any further ado, here is a rough outline of the life cycle of a grandMA3 software release:


    Step 1: Feature Development Happens

    The amount of time spent at this step varies. Suffice it to say that a shorter amount of time here generally means fewer features are added, and the ones that are added are likely to be less "major". A longer amount of time means more work on bigger features (but of course a longer time between actual releases).


    Step 2: Beta Testing Happens

    "Feature Development" has finished. The software is shared with a pool of beta testers outside the factory to test the new features, their interaction with existing features, migrating show files forward, etc. More bug reports and feature requests are generated than there is time to fix or implement if the software is to be released in any reasonable amount of time! So of course prioritizing happens (crashes, freezes, and booby traps first, and so forth).


    Step 3: Getting Closer

    After the heavy beta testing period, there are a few weeks of bug-fixing as the highest-priority items are addressed, and more clean-up happens. At some point in this step, MA International gives a presentation to their Distributors showing what's new in the upcoming software. Distributors may also get a version of software and release notes to prepare their technical support and education teams (this version is not allowed to be shared of course).


    If a big trade show (e.g. ProLight&Sound, PLASA, LDI, etc.) happens to line up with this period, the current software will be shown on the booth. This serves dual purposes. One, of course, is to generate interest in the upcoming features. Another is to have an additional good period of people banging on the software who aren't already familiar with how everything new is supposed to work, which can reveal previously-unknown crashes, freezes, or booby traps.


    Step 4: Release Candidate (a.k.a. "We're juuust about there!")

    Step 4-A: The developers say "We think we're done," and send a version to MA International that could theoretically be released.

    Step 4-B: MA International (and the testers at the factory) do a little more last-minute testing to try and see if anything obvious was missed. Depending on the calendar, the trade show reveal may line up with this step instead.

    Step 4-C: Sometimes, a release-blocking issue is found, which goes back to the developers. Then loop back to Step 4-A. This looping may end up happening several times.


    The A→B→C→A loop in Step 4 is what really causes the antsy-ness I mentioned at the start (<Edit> and as I write this post this is where we are right now</Edit>). Everyone knows a software version is about to be released. And everyone pretty much knows the big features that are going to be in it. But MA International can't say for sure when it will happen, because they don't know how many times through the loop they will have to go before reaching a version they feel comfortable releasing.


    Now you might be asking, "Well why not at least publish the release notes while we're waiting?" And the answer is quite simple: Until the software is actually released, pretty much anything can be taken back out. If a last-minute issue with some feature is found whose fixing would take too long or have too many potential side effects, the feature might just be removed from this version and postponed until the next version (and yes, this has happened in the past, even within the last couple weeks before that software was released). If MA published "release notes" before the release, there's a good chance that the actual released version would not match the previously-published notes. Which then leads to complaints about the missing feature (not that there aren't complaints anyway :P). But worse, someone who read the initial notes might not re-read the actual notes, or might not catch the difference, and then in a show-critical moment could run into an issue because they try to do something based on their outdated information.


    Step 5: Release!

    The software is finally released! HUZZAH! Everyone is happy, and no one finds any new bugs that were missed. Shows use the new software, and much merriment is had.

    ...Meanwhile, back at the factory, the developers are already back at Step 1.



    So there you have it! That's a(n, okay, not so) brief outline of the process that leads up to a new software version getting released!

  • Well, as I said, the beta testers already provide more feedback than can be addressed in a single cycle anyway. :) And the more people that have access the more risk there is of it getting leaked. But all that being said, every so often the factory adds a couple beta testers to the pool. Your best bet would be to make sure your local distributor (Hi! 8o) knows that you're potentially interested, so that if and when the factory asks distributors for possible candidates yours is in their mind.

  • More bug reports and feature requests are generated than there is time to fix or implement if the software is to be released in any reasonable amount of time!

    So...when users start to report issues after the release there is a fair chance those issues are already known.
    Still the 'Known limitations' part of the release notes are almost none existent...
    How come??


    In the 6 months before next release user after user encounters, researches and reports these issues.
    Imagine the amount of wasted time that could have been easily avoided....

  • The bugs that are reported during beta testing it seems to me generally have a higher priority for fixing than feature requests (because, again, the "Feature Development" portion of the cycle has passed). Off the top of my head, I would guess that the majority of user-reported bugs post-release were not previously known. Feature requests, maybe a little more likely.

  • I still think any known, unresolved issue should be listed in the release notes.
    Maybe they are not considered limitations - but a new section with another name would do just fine for me..

    We already know the software is constantly developed.
    What would be the downside on such list??

  • I can't say I know the internal arguments against, so I'm just speculating here with my "distributor tech support" hat on. Just because a single tester found a issue in the lab doesn't necessarily mean that it is going to be a problem for most users in real-world shows. So it's helpful to know which issues people are actually running into, for prioritization. If someone runs into an issue and sees it in a list already, there isn't the incentive to report it to their distributor because "it's a known issue", so then the feedback is lost about who and how many are running into an issue and under what circumstances. Additionally, the process of reporting also enables the conversation about temporary / intermediate solutions (which the distributor might already have worked out) rather than the programmer having to try to piece it together on their own.


    There are potential solutions to that, of course. For example, a dedicated forum section for reports (both bugs and wishes) that allows voting or something, would be one approach.


    Again, I don't know for sure all the arguments, the above is just speculation. A dedicated forum or something like that would certainly make some things easier. But, again, speaking as a distributor, I think I would miss many of the connections and conversations with customers that arise while discussing the bugs and requests they report.