Home‎ > ‎

Trapped, Blind and Confused: The three major programming headaches


 When you're nested deep within the call-stack, a dozen function calls and dereferences away from home, and you discover the API now needs a gxCultureInvariant object. A what? Why the hell does it need one of those? Oh, but there it is: right at the bottom of the call stack in a class that's four levels of abstraction away from you. It's as unreachable as the soap dispenser from a bathroom in a neighboring skyscraper, and yet there you stand with wet and dirty hands. 

 This first headache is the cause of ghetto plumbing in programs. I've personally committed such atrocities as:
  • "Drilling holes through the drywall": adding an unused parameter to each of a chain of functions so I could "feed a cable" through them with the value I need at the top of the stack
  • Using global variables, or worse, the singleton pattern
  • Creating redundant instances of resources so I can pick the cherry that I need and throw the rest away


 I've said that ".Net" is Microsoft's way of hiding their best tools from reasonably phrased search queries. Some might say the same about programming languages with unhelpfully generic names like J, D, and Factor. (At least "G" changed its name to "Deesel"--wouldn't it be fun to search Google for "G string class" when your boss is watching?)

 Programmers encounter blindness when they intuit that a function must be available in their tool-chain, but it's difficult and laborious to hunt down the documentation for it. How many times have you:
  • Searched for a concept, only to find out the vendor called it by another name
  • Known what you wanted, but didn't know what the concept was called ("the thingy that puts the binary stuff in the blob column")
  • Tried to guess which namespace a class was in
  • Tried to figure out what Microsoft thinks System.ComponentModel is supposed to be for today
 This blindness results in needless programming and duplication of functionality that already existed. It even leads to projects abandoned in frustration.


 The third headache belongs to programmers who know what they want but don't know how to do it, nor do they know how to find out. They have some sense of what should be done, but the problem itself is tricky, complicated, and hard to solve in general. Sometimes the problem has been solved by computer scientists, but the programmer isn't aware of it or hasn't got the education to understand it. Sometimes the problem just isn't solvable at all and both the programmer and his customer are unaware. In the last category we find the unhappy and unwitting pursuers of problems that are NP complete. 

 These problems are infuriating because it seems like it should be simple. In fact, your boss is standing over your shoulder, waving his arms and saying "well, this is easy, you just... I don't know... do it!". Problems like:
  • Plotting a circle (and you don't know trigonometry)
  • Figuring out how many boxes can fit in a carton (backpack problem, NP complete)
  • Comparing two street addresses to see if they're the same location (harder than you think)