TL;DR
Ok as a coder working for a large National bank, and as a programmer since 1977, this phrase- “code complete” and it’s cousin- “get the code completed”, are a concept that is lost on me. Ok, I can hear the keyboards clicking right now as you start gearing up to mansplain it to me so let me be a little more forthcoming...

How do people on here and others throughout the hobby keep using this phrase and not know that it makes them sound, well, a little foolish to a actual programmer? Has everyone suddenly become real time OS coders lately without me knowing it, or just how do people “know” when the code is complete? Is it because the software guy at the manufacturer said “I am still working on the code,” or does everyone just know when a game is finished, all the bugs are gone, and it plays like, what?, every other pinball machine you have ever played? That can’t be right either, because all pinball machines play a bit different due to rules and hardware.

So I guess what I am after here is if you are playing lets say the new Munsters machine, and you get all the way to the ultimate wizard mode, finish it and complete the last mode it has to offer and its back to the beginning again for rinse and repeat time, is this where you make your decision that the code is complete and finished? Or just what does finished code and game play actually mean?

And I am asking for people’s real thoughts on this, this is not a troll or a bait.

So what are peoples benchmarks of “completed code”?

Ok, so gameplay not matching artwork/inserts is one tell tale, and by that logic, rule cards, game flyers, and pre-production or post production press releases all could contribute to a sense of incompletion.

@rai, thanks. So watching the machine make errors you think could be caught with code, or that you have seen other code address, ok this makes sense from a player standpoint.

TL;DR
But as a coder, the truth table to handle errant balls that get missed or shots that are made but not registered are some of the most infuriating code to write and debug. A code base can only handle so many “what if” situations during game play modes, and sometimes the state of the machine gets confused when illogical switch hits enter the game control loop. Lets say like you get switch B being made before switch A, but switch B is only exposed to ball interaction if switch A is made, so when the B before A comes into the game loop logic, it may disregard or handle differntly (in this case) the B hit because A is not been made yet, however the reason this happened in the first place is an airball jumped over the drop bank and hit the target located behind it while the drop bank “down” switch was not made (or the “up” switch is made). You may recognize this as “Dirty Pool” in AFM, which is the code branch we see when this actually occurs during the game.

Error handling can get complex realy quickly, and actually, in real time programming, you do not have the luxury of having all the time in the world to try and figure out what physically is happening on the table while looking at a simple switch matrix and with no real time info on ball location, direction, speed, etc... Lyman is a great coder, he does a lot of error checking and a lot of state sensing, but there is another factor at work here, how much error checking is required in an amusement device? We are not talking life or death cercumstances when it comes to pin coding, so I would expect some shortcuts to be taken. But then again, KozMckPinball , this may just be your definition of “code complete”, in that ALL errors are handled, no matter how often they may occur or wether they can be detected by the player or not, so a viable and defendable position on being “code complete” but not sure it is economically obtainable by a single coder within a reasonable delivery timeframe. And it is also why some code updates take forever IMO.

Not so much that but why people throw the term around like there is a magical way of “knowing” when code is “complete” which as a programmer, for us, code is never “complete” because there is always some facet of it that you know you could code better if given enough time and resources. We like terms like rev level 0 or 1.0 or 0.95 or 2.01, all very open ended. You only ever get to “Final Revision” when the money runs out and the project is closed. It would be interesting to see a time priority breakdown sheet from Stern’s coders... latest released game 25%, latest unreleased game 74%, all previously released games 1%... or what ever their mix is right now. (These numbers given here are for comedic purpose, not a dig...)