?I?m?i?t?a?t?i?o?n? ? Emulation is the sincerest form of flattery.

Opinions expressed are solely my own and do not represent the views or opinions of my employer or clients.

During my time at a previous company, I led a particularly demanding project under tight deadlines, focusing on upgrading the outdoor payment terminals (OPTs) for a client. The primary objective was to replace the antiquated Dione terminals, which, despite their mechanical resilience, had outdated electronics. The batteries and sensors were also beginning to show signs of wear and impending failure.

The project constraints required us to stick with the emulation approach of the current OPTs, as modifying the POS software to accommodate a different OPT protocol and architecture was not feasible within the available time and budget.

Our closest competitor proposed an eight-month timeline to complete a pilot. However, we managed to accomplish it in just three months by adopting an unconventional approach to software development.

How did we achieve this? The key was maintaining a small team—just two people. I focused on core emulation, while a colleague managed the graphics interface and remote management software. We operated without dedicated QA resources, testers, Jira, or standup meetings. Instead, we concentrated on delivering minimal code, aiming to reduce complexity and, consequently, minimize bugs. Much of the project was developed in hotel lobbies.

Emulating a system can be quite engaging; as features begin to work, the desire to add more features grows stronger. However, challenges arise, especially when using a black-box approach, which can introduce subtle discrepancies between the original and emulated systems, potentially exposing bugs in systems interacting with the emulation.

During the project, we encountered several bugs in the POS OPT driver that couldn't be updated or fixed, necessitating extensive differential analysis to identify their root causes. We discovered several issues with the driver's handling of critical sections and locking mechanisms. If the emulated system responded too quickly (since the older system was slower), it created problems within the POS software's OPT driver.

One of the most memorable episodes occurred when the client’s project manager used the emulation system running on a PC to demonstrate an undocumented secret menu. This was a clever way to test the quality of our emulation software, as a simple hardcoded simulation would have failed.

Despite the outdated OPTs' slowness, their communication protocol demanded extremely strict and challenging speed parameters, which were even more challenging to meet with the new hardware.

During the UAT, the same manager who demonstrated the secret menu also showed us how they tested the barcode performance. He tossed a card with a barcode in front of the barcode reader, and it had to successfully scan the barcode while it was in motion.

More than a decade later, I remain astounded by the performance of that barcode reader, a testament to the quality embedded in those old OPTs!