Other People's Problems

One of the nice things about being a developer, the core thing if you will, is the problem solving aspect. Problem is there's classes of problems.

1. Technical problems. Trying to get bandwidth usage or load times down, fitting more polygons on screen, other non-optimisation technical problems too. These problems are fun to solve because, unless you aren't familiar with Google, they haven't been solved before.
   
2. Domain problems. Whatever it is you're trying to implement. This could be corporate business rules, streamlined email interface, shooting aliens in the face in a satisfying manner. These problems are fun to solve primarily because they are the goal of the software. Solved correctly they should make users happy, which is always nice.
   
3. Other people's problems. External interfaces that don't conform to the documentation, invalid HTML, malformed data from legacy systems. Perfectly robust, usable, elegant code gets filled with exceptions and conditional branches that are only necessary on Feb 29 every third leap year. They are other people's problems because if the original author had done his job properly, it wouldn't be my problem now.
   

I thoroughly dislike other people's problems. They routinely put me off from hobby code projects. I'm more than happy to spend dozens of hours working on odd little projects in my spare time. What I'm not willing to do is spend dozens of hours dealing with the fact that 90% of people can't get their websites to be valid SGML, let alone valid HTML. Sadly other people's problems fill an inordinate amount of the project time in corporate land. They call it "systems integration" because it sounds better than "fiddly annoying crap." I think a lot of other people's problems would go away if web standards were more like other industry standards and you could get sent to prison or at least sued for ignoring them. I guess if the standards actually made sense and didn't change every eighteen months, they might be easier to conform to as well.