Pits of Success

The latest Herding Code podcast was a rehash of some of the issues with Visual Studio discussed over Twitter. One of the main issues discussed was drag and drop coding. Why do people use it? Why do we see it in so many demos? Why aren't there more warning about using it with caution?

The responses from Alan Stevens lead me to believe that Microsoft doesn't recognize how damaging drag and drop coding can be (and how most developers have disdain for it). Alan's justification was that it you're aware that it incurs technical debt, you're ok. In other words, while it generally produces sub-optimal code, as long as the amount of time savings can be justified now for a refactoring later, it's acceptable. There are a few good reasons why it isn't:

• It teaches a lot of developers bad practices, and those practices never get improved
• Developers are either forced to search find an alternate means to learn a technology or reboot their current methodology to do it right
• It creates really bad code that is hard to maintain
• Most projects don't have the time budget for refactoring; besides, who wants to write their code poorly from the start?

What Microsoft has inadvertantly done (and continues to promote) is a method of coding that leads to failure. Instead, what they should be doing is providing a set of sensible defaults and conventios that lead to success. These practices are quite common outside of the Microsoft community; you'll find frameworks like Rails or Grails impelmented in such a way that they create a pit of success. The conventions and defaults are engineered in such a way that its easy to fall into the "trap" of doing things the right way by default.

Don't get me wrong, Microsoft makes some great products, and continues to improve their offerings (the new MVC framework is a great example). However, by continuing to teach developers bad practices, they're creating a pit of failure.