1. Writing code in a way that Windows Operating System couldn’t mess it up. Having an application run on 95, 98 Developer Beta and several hot fixes in between
2. Avoiding clashes with other Windows applications. This is funny, 90% of the time the issues were related to end-users installing/uninstalling other related/unrelated applications
3. Finally, writing code so that hardware changes don’t mess the application up–Installed a new iomega Zip drive? The D:\ drive stops working. Changed Network properties to make Banyan Vines work? The whole TCP/IP stack stops responding!

Fast forward to Social Media applicaion development today. In my short tryst with WordPress Plugin development, I found that I have to take care of similar things (though in a much easier way compared to writing C++ code).

1. When writing a WordPress Plugin, you have to make sure that it serves at least 3-4 major revisions of WordPress installations. Few people bother to upgrade (although, WordPress does a good job alerting users in the admin panel).
2. Make sure that your Plugin plays nice with other plugins and themes. Due to increased flexibility (love them WordPress!) zealous features may sometimes may not work with themes and such; say a theme which has two sidebars on the left and none on the right. 
3. Most of the times WordPress Plugin code (written in PHP) and underlying operating environment (PHP, MySQL) mix each other well. However, at times end-users may have different settings, database permissions and security sandboxing rules. Watch out for these as they’re hard to detect and the end-user may not have any idea about the configurations.

There are specific examples to the above WP issues which I’ll rant on in future posts.

All in all, these are happy problems and shows the maturity/popularity of the platform amongst the developer community. Neither these are hard problems–requires diligent coding and testing and a generous feedback from the ‘beta-user’ community