> Raymond's posts are always fun to read, but it sometimes he focuses more on the "proper" methods, and does not even acknowledge that there are hacky workarounds.
Nor should he, IMO. Hacky workarounds are almost always a terrible idea that will bite you in the ass someday.
As a hacker, I'm sorry, reverse engineer hacky workarounds is what I do. When I want to read stdout of a malware process I'm not going to ask a developer nicely, in going to grab my trusty debugger or API monitor.
But yeah, for production quality software hacks are the very last resort. It's still fun and enlightening to know them, though.
Hacky workarounds aren't rare exceptions; they're the plumbing of modern software. Anti-cheat and antivirus tools only work because they lean on strange kernel behaviors. Cloud platforms ship fixes that rely on undefined-but-stable quirks. Hardware drivers poke at the system in ways no official API ever planned for.
Yeah, they're ugly, but in practice the choice isn't between clean and hacky; it's between shipping and not shipping. Real-world software runs on constraints, not ideals.
On the other hand, everything you ship outside of a clearly established golden path is a maintenance burden that piles and piles and piles. And these maintenance burdens tend to gradually slow the org down until they cause rather catastrophic failures, usually out of security or hardware (read: fire) incidents. Or HR reasons because people figure there are better places to fight fires.
Had a WPF touch interface application that would latch on when a person; presses, holds, and slides their finger off the screen. Highly unacceptable when it controls a machine that could remove a limb.
Only fix was to write a custom touch screen event handler that overrides the built in one by Microsoft.
I would love to have a _proper method_ and pull out my _hacky_ method that prevents the removal of a person's limb.
Nor should he, IMO. Hacky workarounds are almost always a terrible idea that will bite you in the ass someday.