Desperate Measures – A Time To Hack

That is brilliant. I love it. Very well written too!

Some markets and niche areas are just chock of full of arbitrary constraints. Security, legacy, idiocy (hey, that rhymes!), whatever it was before and has been kept around, codified and become part of many existing systems, red tape rules, some meaningful some not so much.

In this case is payment processing. But military and government systems are another example. You can't believe hoops one has to jump through to confirm to a myriad of red tape regulations, mostly security related to be able to sell to the government.

There is no shortage ancient systems or remnants of botched projects by your favorite large contractors (L3, Lockheed, and so on) that cost millions of dollars and put together with paper, glue and duct tape (metaphorically speaking) and then abandoned.

I imagine health record keeping is another (can you say MUMPS). That one word should send shivers down any programmer out there.

Some will say "fuck it, this is all broken, I am out of here", or "let's rewrite your systems in Go and Angular". Sometimes it pays (as in real $) to get your hands dirty and start playing with these systems.

I think my favourite example of a "dirty hack that gets the job done" was by the developers of the DOS game Wing Commander. The game worked fine, but when exited, it output a strange error message to the console, complaining about some virtual memory issue. They couldn't figure out the cause, and it didn't seem to be hurting anything - so they opened the executable in a hex editor and changed that message to "Thank you for playing Wing Commander".

-----------------------------------------------------

An anonymous comment on the Desperate Measures blog. I'm old enough to remember the message and wondered why it was so polite. ;-)

Reminds me of a "hack" I pulled years ago - I was developing desktop software that needed to retrieve information from a Palm OS application called Ultrasoft Brainforest Deluxe. This particular application was a general-purpose outlining/tree-structure data store. Basically I ended up searching for a description of the .PDB file format and using that to decode the tree structure from the synced back-ups. It took a bit of trial and error as well as some bitwise operations (my first experience with those). IIRC, the Palm data was stored as unsigned bytes, and I was using Java...

As someone that started their career installing, maintaining, selling, and writing software for PoS systems, this was immensely entertaining.

This is also a typical example about why it is difficult to get time estimation right on software task. Every so often you get a long tailed problem that takes more than 3 times longer than the original estimation, due to unexpected difficulties...

I actually think that this was a great solution. They wanted receipts and now they are getting them in their purest form. And the POS system won't even notice the difference. Smart, simple. What's really hacky about it?

An excellent post. Very entertaining.