The Kobayashi Maru simulation is from the original Star Trek television series, and later showed up in the movies in Star Trek II: The Wrath of Khan (which is still the best Star Trek film ever). The Kobayashi Maru is a no-win training scenario used at Starfleet Academy to test a starship trainee’s resolve and examine their decision-making process. Do you save the people on a doomed ship or risk intergalactic war and maybe the death of every one of your crew? Either choice you make is a doomed choice, but the choice reveals your character. The only person to ever beat the Kobayashi Maru simulation was James T. Kirk, who went on to command the starship Enterprise. To beat this test, he changed the rules; he hacked into the main program and changed its parameters. The logic was that he didn’t believe in a no-win situation.
When I talk to other programmers and engineers at computer shows, I realize that I am in a unique position of working for a hardware manufacturer and also making software that talks to the same devices. If something comes up and doesn’t quite work within the rules, I can change the rules within the firmware of the box. It gets a little frustrating when I talk to people about interfacing our devices to open source or commercial projects and they dismiss us because we don’t have a certain feature. I do take comfort that most people don’t realize that I can change our boxes’ firmware, the actual API in the box AND the software that talks to it. There is no such thing as a no-win scenario when you have these tools at your disposal.
I first became aware of this power many years ago when the company I worked for made serial/parallel-based printer-sharing boxes. You could change the target printer by sending a string of characters (I believe it was [:]P<cr><lf> for parallel and [:]S<cr><lf> for the serial printer). We made a DOS TSR program to help issue these commands and also a Windows-based program. In the Windows-based program, we used the “generic text” printer driver, which sent exactly the characters you wanted to send without any of the printer’s native page markup language commands. A problem arose when Microsoft went from Windows 2.11 to Windows 3.0; the generic printer driver now ended all output with a <formfeed> character instead of <cr><lf>, so when a customer tried to change printer output on our device an extra sheet of paper came out of the printer. Instead of trying to contact Microsoft and complaining about this change (which we knew would go nowhere), we just changed the rules. We modified the firmware in our printer-sharing box to accept both <cr><lf> AND <ff> characters at the end of any command.
More recently with our “Out of Band” serial console and “Power Distribution” units, controlling them with automation packages was daunting at best—you could use a package’s generic shell control modules to issue cryptic commands to our devices. So, again, we changed the rules: We have added a growing set of APIs to all of our devices, which interacted with our modules we created and have been adding to the Ansible project.
My long-drawn-out point: Try to change how you look at a problem when you encounter a roadblock. Think outside the box. If there is an open source project or a type of a device that doesn’t do what you want it to do, get involved and add the functionality to make it work. For open source, download the source from GitHub, play with it and add the things you need to make your life easier. If a device you are using would be perfect if only there were one more feature, contact the manufacturer; most of the time they will be thrilled to get a phone call from customers who want new features (especially if you reach the engineer who helped make the device).
When you change your way of thinking from a programmer to an engineer, that opens up unlimited combinations of possibilities. Be a Kirk.