In my experience new developers are very bad at adapting to new ways of doing things and very good at blaming the system for their own problems. They'll do something that is not the right way to do it on this system, hasn't been for a long time, is documented on how to do it, and then blame the system.
Two of my favourite examples of developer laziness:
1) Lack of 64-bit apps for Windows. While I realize most apps don't need to be 64-bit, and 64-bit Windows provides flawless 32-bit support, you should still have 64-bit version available. They do run a tiny bit faster and it is just the right way of doing things. Let's start getting rid of the legacy stuff. What's more, it isn't hard to do, at least according to the developers I hang out with. You set the compile target for 64-bit and go. Maybe a couple things to correct but all in all the compiler takes care of the details. However most don't. The reason is they were doing shit in the code they never should have, like casting pointers in to 4 byte integers and so on. They write bad code, and it makes 32/64-bit porting a problem.
Your assumptions are based on assumptions of assumptions. As a developer of a Windows app that is 20 years old, it’s not as easy as “setting the compile target”. You have to continually port over the years, and that takes time, resources and money, which for almost all companies is limited. Time is often spent on continual improvements and not on moving up to 64-bit. Touting a product as 64-bit is not a selling point for 99% of the customers out there – they either don’t understand, don’t care, or both. So, in summary, I reject the notion that it is laziness. Time is better spent elsewhere, until the Facebook/Apple gobs of money start pouring in.
As long as we're going to reinvent the wheel again, we might as well try making it round this time. - Mike Dennison