What started all this thinking off, was XSLT. In essence, it's a simple technology for transforming one XML document into a different one. In practice, this is nearly always about transforming an abstract document into an XHTML document for web display. On the surface, it sounds reasonable. Yet I can see almost no reason whatsoever why I would ever need to use XSL/XSLT again. For starters, this processing is likely to be done by an ASP/PHP/Python/whatever page, based on information from a database. Why generate an abstract XML document from that data and then transform it when you can just transform the data directly? The general argument is that of abstraction, yet the web script already forms a layer between the data and the presentation, so what's the issue? People talk about separating the presentation from the logic that generates the page, but that's what CSS is for. All examples of XSL I've seen could have been replaced with 1/3 the typing if a traditional language had been used to output the XHTML instead. This just seems like a classic example of overengineering, where extra layers of abstraction are added to meet some theoretical utopian design specification at the expense of developer time and the amount of code that needs to be understood and maintained.
A similar thing exists with my complaint about Python web development in the previous entry. Nobody is interested in simple answers to the problems that face most developers; instead, they want a framework that can do absolutely anything, with so much flexibility and abstraction that it provides virtually no benefit to anybody. Instead of simple APIs that only work in one or two places, the result will be a complex API that works everywhere. No-one's a winner. Yet these developers seem very keen on it.
It struck me that the same thing happens here on Gamedev.net. Although attitudes are slowly changing, people still instinctively overengineer things. They write engines instead of games because they want to make sure the engine can accommodate anything their eventual game will throw at it. Often they spend so long on this that they never even get around to writing a game. They worry about low-level optimisation no matter how often we tell them to wait until they've found a problem and profiled it, because they want to be sure that they've got as much performance out of the program as possible, in case they need those CPU cycles later.
About eight years ago, I became more familiar with commercial computing as opposed to the purely game-related computing I had grown up with. One thing that caught my attention was the painful overuse of the term 'solution'. You didn't write programs, they were 'solutions'. Money package? No, 'Personal Finance Solution'. External disk drives? No, 'Portable Storage Solutions'. File-sharing server? No, 'Local Network Collaboration Solution'. 3D shooter? No, 'Alien Elimination Solution'. It drove me crazy. But that's the way of businessmen; to sell a product usually means that you have to promote it as being necessary. And something is only necessary when it provides a solution to a certain problem. Hence calling something a 'solution' is a nice vacuous phrase to make you think that the product they're selling is a complete and working answer to whatever issue is on the customer's mind.
Now, the critical thing here, is that programmers generally hate solutions. A solved problem is not interesting. We enjoy solving the problems - it's the businessmen who enjoy sitting there twiddling their thumbs idly while their 'implemented solution' brings the cash rolling in. That's why the big rich companies have their software 'solutions', but are boring as hell. I can go to Electronics Boutique and buy an off-the-shelf Strategy Game Solution but as a programmer I'm not interested in the end solution, just the act of solving the problem.
As a result we often spend too much developer time on solving problems that we don't really have, whether that's forcing an extra abstraction layer into a web application on the off-chance that we might one day want to display the same data in 2 different ways, or trying to work out a faster alternative to that division in an inner loop just in case it actually is too slow, or trying to develop a standard web development API that is portable across several different servers even though the end user will almost always only use one such server.
Maybe that's just the way of the programmer, more akin to a researcher than an engineer, learning and experimenting rather than building and completing. I'm happy with that, although I often stop to wonder how much could have been achieved if we could change every 100 half-completed projects into 50 completed ones. How much work is wasted? I guess I'll never know.