Or How I Learned to Stop Worrying About the Concept of Done And Let It Go
If I could have a 3rd heading that is in-between the size above and the text below, I’d use that here to show that the article hasn’t started yet. This first part is a bit of a prologue to describe why I’m writing this. I also really-really wanted to put a picture of Elsa from Frozen up top, but Disney’s litigation team scares me.
In one of my earlier posts (Jurassic Park Review), I mentioned wanting to write this up because there is not only confusion on how versioning in software goes, but a complete lack of interest/knowledge on how software in general is written that has led to people getting really twitchy about pinball games purchased from manufacturers with game code that doesn’t seem finished. And that’s likely because it isn’t.
I heard someone from a prominent pinball manufacturer’s stream of a recently released pinball machine (super vague right?) comment on the fact that they weren’t going to release new software with the version on it anymore because it was creating too much confusion.
They’re opting to put new software on a stick someplace and let people figure out if it’s different than the version currently running on their pinball machine than display versioning that “creates confusion”…
Ok, time to write this article and enlighten the masses.
Note: That space between “creates confusion” and the “ok, time to…” represents the small explosion that occurred in my brain as I tried to comprehend the lunacy of my own statement, stating the lunacy of others being forced into lunacy. Yeah, like 16 asylum walls were broken and an internet troll got it’s wings…
A Brief History of Software Development
Software has come a long way.
In the days of yore (through the 90s), software was imagined, then designed, and a team of superhuman dorks who eschewed silly things like sunlight in favor of blue-light worked diligently for some time (a month, a year, 5 years) to turn that vision into a reality.
These were the days of real development. When a developer wore pocket protectors, and glasses that often had something wrong with them. When a programmer didn’t have to worry about body odor because they worked in a basement, NAY… a dungeon, and wrote archaic unreadable code that only THEY could comprehend and update alone. When nerds were nerds who got $#!7 done!
A Second Brief History of Software Development From a Time With Less Michael Jackson
Fast-forward about 30 years and it turns out that code written like that by teams of people like that… kind of sucked. Who knew that some nerd’s code written to perform bank transactions in the 15 minutes they had available so they had time to make it home and record the latest episode of Murder She Wrote would be utilized for decades and ultimately cost more to rebuild than hire someone at exorbitant prices to maintain.
Who knew how short-sighted programmers from back in the day would be. How many shortcuts they would take. You guffaw because you know some old guy in suspenders and a cool beard who knows their stuff!? Look at the Y2K bug. That crappy software wasn’t written by millennials.
And what about the customers? What customer who doesn’t write software really knows how to solve the problem they hire developers to fix? Shoot, what customer that does write software can do that? Maybe that’s confusing: The people who hire developers to write software, don’t actually know what they want that software to do. Let that sink in for a minute because those same old school businesses that hired programmers to build an app for 5 years… yep, a large percentage of them were unsatisfied with the final product. Nothing quite like a couple of million spent to write a chunk of software that does exactly what you wanted only you didn’t really know what you wanted and now the software you paid millions to have built doesn’t really do what you need it to do.
Don’t believe me? Don’t think that happens ALL the time? Guess again. I could fill a library with books that talk about and address that issue. In fact, every SCRUM/Agile/SAFe book written discusses exactly this. Granted, it would be a small library. But “technically” a library.
Ok, so now we’re in the year 2001 when a bunch of nerds got together and whined for days on end about how often the software they wrote did what they were told to do, but the customers didn’t like it. They came up with the Agile Manifesto. And check it out, because these ideals have become the foundation for software development going forward:
- Working software
- Customer collaboration
- Respond to Change
- Individuals and Interactions
Did someone say “Forward”? Moving forward, when building software using Agile principals the goal is to get something in front of the customer as soon as possible. Something functional so they can get their hands on it and check: Does this do what I want? Does it solve the problem?
If yes, the developers keep going. If not, they have a conversation and determine how best to change what’s being developed to best solve the customer’s problem.
This results in software ACTUALLY solving the problem it was written in the first place to do. Ding ding ding, big winner, big winner.
A Few Negatives of Agile
It can’t all be unicorns and cupcakes, what are the downsides to Agile development? Wow, great intuitive question! The two biggest issues with agile style development are:
- It’s difficult to accurately predict when a project will be complete
- Projects are often over-time and over-budget
There are others but those are the two biggest offenders. There are ways to mitigate these downsides with tools, scrums, and diligence on the part of the team-planners but those really are the major issues with scrum that we see every day in the real world. Heck of a trade off though to get software that actually solves your problem 🙂
Ok, then what does all of this have to do with the version numbers on a pinball machine’s software? You know what’s funny is how often I imagine someone reading this and half-way through they realize they don’t have time for my tangential ramblings. You may be the most patient reader I’ve met or you may be skimming and totally miss this part. But I always feel rushed when writing these, like I’m a reporter for some newspaper and the editor is breathing down my neck as I try and finish some article that needs to go out by 3:30PM.
Maybe I should write these articles during the day instead of at 1:13AM? There would probably be a lot less memes and spelling/grammar mistakes.
Anyways… HOLD ON A SECOND! There’s more you need to know about software development before we can dive into the deep-end of version control and software versioning. Sheesh, some people’s kids…
Continuous Integration/Continuous Development (CI/CD)
No, this isn’t some weird iteration of Obsessive Compulsive Disorder (OCD), CI/CD is the process by which a development team automates delivering their software into environments for testing. When someone checks in updates to their code, a build gets triggered and so many times a day or week or even immediately upon check-in, the newest code is deployed to an environment (or multiple environments) so people can actually use the software product.
Here’s a pretty simple/standard example of what most software companies do to get their code in front of the customer as soon as possible. Make sense?
Of course not. Unless you’re in the software biz, I imagine a bunch of that doesn’t make a “lick” of sense. What are “upload artifacts” or what did you mean by “Check in Code”? And you’re right. There is more to this story. Feel free to skip this next section if you don’t want to follow the white rabbit even deeper:
Quick Digression Into Repository/Build Management
Wow, there is so much more to software development than you thought, right? Well, we haven’t touched on the difficult parts yet. Muahahaha (maniacal laughter)!
Imagine you’re on a team of developers, like maybe 10 different devs all working on one section of code in a large project. Let’s say the entire project is trying to automate the purchase of thingamobobs from an internet site called Acme. And your team has been assigned to work on the section of code that actually calls out to credit card company’s to confirm the funds are available. Now that is just one tiny section of a large project that probably has another 50 – 100 developers working on it.
Now because you follow Agile design principles, you’ve got a release to go out to the customer in a week and your team is trying to finish up the code updates needed to call Mastercard and confirm funds, initiate a payment, and confirm payment was successful. Bear with me.
There are other teams working on Visa and American Express. The process by which you do things actually has some cross-over with the other teams. Meaning there is code that all three teams use because the process by which credit card payments are made regardless of vendor is similar. This is good coding practices!
But you discover a bug in the code that all three teams share.
How do you fix the bug and get your changes out to the other teams in a way that doesn’t create problems for the code as a whole?
And what if at the same time, someone else discovers another bug that is related but different in the same code?
Oh. My. Gosh. This is not something that happens once in a blue moon. It happens daily in the software world. And I’m not exaggerating even a little. And no, you don’t just call the one person working on the code and have them make all of the fixes then walk it over to the other team. This is where code repositories and conflict mitigation comes in with software like Git and methodologies for reducing conflicts/collisions like Git Flow come in.
Yep, we’re definitely not in Kansas anymore. But don’t let the above graphic confuse you. Think of it as a distraction like the lighting in the pinball machine Game of Thrones but maybe a little less seizure inducing.
So working in teams on the same code can be difficult. And managing how you change that code in a collaborative way is even more difficult. But there is software to assist and methodologies to follow that help simplify it and if you adhere to a standard versioning system like Semantic Versioning… it all comes together quite nicely.
Alright, back to CI/CD
But here’s the interesting part. If you’ve automated the release process and customers are testing the releases and you know that people are NOT going to be prompt about getting back to you with request to make changes or bugs found… how do the people testing the software know what deployment of code they’re testing? With all the weird spaghetti style check-in procedures from Git and Git Flow, how do you know what version of the code the code is even at!? And even better, how do they compare what’s changed that needs to be tested in a particular deployment from another? Or what about when one software component depends on another and needs it to be developed along to a certain point?
Geez, is software REALLY this complicated!? How in the world do you keep it all in-line and make sense of the whole thing?
Software Versioning
Boom. We’ve gone full circle. Ludicrous speed. Plaid. We’re here and it only took us several thousand words. Software versioning is now important not only for the customer to differentiate between versions they have installed, in the Git software repository used to allow teams to collaborate on development, and in testing to keep track of what was changed and what version you’re using to test on. And we’ll stay focused on the customer facing aspect of versioning going forward. I think we’re done with the super technical stuff.
How does versioning work? We’re going to stick with a really common form of software versioning called Semantic Versioning. This is the most prolific in the software world.
I’m going to quickly summarize what semantic versioning means: Major.Minor.Patch. Meaning the first patch on the first major release with 2 minors already would be 1.2.1.
There is a guideline in this that says until you are in-production (fully released) you should keep your version with a 0 as the first number (Major). So that same example but not yet in-production would be 0.2.1.
But doesn’t that mean the developers could switch the code to 1.00.0 when the first game is sold? Yes. That doesn’t seem to be the norm in the pinball industry as both Stern and JJP seem to adhere to 1.00.0 meaning released (which is still consistent with Semantic Versioning). But a company could update their numbers to 1.00.0 when launching and then continue updating major/minor/patch numbers with each software update.
Now on the semantic versioning site, they are obviously sticklers for their own rules. But I have yet to come across a shop that takes the semantic versioning system half as seriously as the semantic versioning people. They’re great guidelines but people do make minor changes occasionally. One I’ve seen often is to put the build number at the end. So you’d see something like 0.2.1.23 for the 23rd build under that minor. I’ve worked with a company that has been developing software for 8 years and have yet to exceed 1.00.0. That’s a long time to be in beta 🙂
We’re getting into the weeds a bit but I think that’s good because at the end of the day, the numbers aren’t there to make a bunch of sense contextually. It’s used to track changes and the significance of each change by where the number has incremented. Was it a major, minor, or patch that incremented?
Note: A patch is typically just a bug fix that needs to get out before the next release.
Early Access, Alpha, Beta Testing, Release Candidates, etc…
Ok, now you understand a little about the history of software development, how teams of developers work together to collaborate and write software in a way that gets it to the testers quickly and respond to feedback.
Why o’ why does a company like Stern put out a pinball machine with software that is so obviously unfinished? Oh my, we’re here. We’re answering the question! But we have a problem with how that question is worded because we all know too much about software development now.
Let’s re-frame that question a bit more accurately: Why does a company like Stern begin selling pinball machines before their software has reached production status? That’s better but maybe we can try one more time to bring in our vast knowledge to better ask the question.
I think I can try that again: Why do people buy pinball machines from Stern (or their distributors) with software that has not reached production status and then complain when they experience bugs or encounter missing content?
Ok, maybe that last iteration was a tad sarcastic but… that’s me.
Jurassic Park just released version 1.00.0… that looks like semantic versioning to me. And they seem to be following it. They probably have teams of developers working on different sections of the code. Notice how in each release there is often code related to how the game plays but also updates to the underlying systems that target the node boards for Stern or accepting cash vs. coins or displaying text in different languages. While that “may” be the same developer, it seems unlikely knowing that each manufacturer has teams of software devs. They’ve probably got something similar to what I described above and often need to collaborate on code, perform testing, etc…
Why Release A Pinball Machine Before 1.00.0?
The answer is actually the heading to the previous section: Early Access, Alpha, Beta Testing, Release Candidates, etc…
Companies giving customers access to code or their production products before the code is complete is pretty standard in the industry. Think about all the games that you’ve probably played online in beta testing: Magic the Gathering: Arena? If you played that prior to December of 2019, you were accessing their beta. How about Heroes of the Storm from Blizzard for the first 2 years? That was also Beta access. Fortnite was in beta through some of 2018!
And it’s not just Stern. Jersey Jack still hasn’t released the final code for Pirates of the Caribbean! It is common across all industries to provide customers access to products before the software is complete.
And that’s the trade-off. Jump in early and enjoy playing the game with the understanding that you may run into issues or unfinished code or wait until the software hits 1.00.0 and buy your game then.
If you’ve been on Steam at all in the past decade and purchased a game with early access, you’ve just done what Stern and JJP do all the time, which is to buy a product and play it before the software is released.
You may be thinking… “What is up with all these weird pictures of keyboards and what-not”? Well, that was me playing around with my juicy new camera this morning and not knowing what to do with all of the images so I threw them into this article in random places because “reasons”.
Is There No Reason to Be Upset With Bugs or Unfinished Code Then?
That’s a good question. Was I frustrated by how early the code was on GOTG when it was released. Absolutely.
Was I frustrated by how slowly updates came out for Batman ’66? No. I didn’t buy Batman ’66 until it was almost fully released. Because of the feedback from other early adopters, I waited with the understanding that Lyman Sheets would eventually get it done and it would be a masterpiece.
What about Jurassic Park? Nope. No frustration. I knew going in that the code wasn’t complete. It was kind of fun to hit parts of code that were stubbed out but not complete. It felt like hitting the end of the road in The 13th Floor. But what I like more than other early releases was the intention in code.
What do I mean by intention in code? In Deadpool, the game changed quite drastically between versions. New wizard modes, mechsuit multiball (which may be one of my favorite multiballs period), and a few other changes that seemed to come out of nowhere. But Jurassic Park built placeholders for where the code was going. I knew ahead of time what Jurassic Park would become and each release only fleshed things out more fully. With one exception: The Smart Missile. That was a pleasant surprise.
But I knew with each of these pinball machines going in that I was going to buy a game with early access code and accepted that I might run into issues or unfinished spots. Sometimes I was happy with the end product like Jurassic Park and Deadpool, and sometimes I sold it quickly like with Guardians of the Galaxy.
I urge each of you to make buying decisions on pinball games with this new found knowledge in place so you’re not surprised when the code seems unfinished with your NIB delivered days after the pinball manufacturer announces it because it probably shipped with unfinished code. And do so with the understanding that selling pinball machines before the code is released is fine as long as the manufacturer isn’t hiding the fact that the code is unfinished.
Who Am I?
I finished this article and realized that I spoke a ton about software but never mentioned what I do or have done in software to justify such a long post about software development.
I have worked alone on software for years (meaning I was the smelly dork in the dungeon), in small teams of 2-6 developers, and larger teams of 10-15. Currently I’m working in an environment where we have over 250 developers working together. That makes for a lot of code.
What’s Next?
If you were struggling with versioning before now, then wait until you get a load of the next article that is likely to incite riots: Why DLC May Not be Awful for Pinball
Don't Panic Flip 