The great .NET productivity killer

This post is more than 13 years old.

Posted at 07:00 on 28 March 2011

A couple of blog posts caught my attention over the weekend. The first was from Robert Scoble, attributing MySpace’s woes, at least in part, to their choice of technology stack. The second was from David Barrett, the CEO of Expensify, explaining why he doesn’t hire .NET programmers.

Now there is the saying that a bad workman blames his tools, but there is such a thing as a bad tool (would you want to use a hammer whose head keeps flying off?) and having had fairly extensive experience of both .NET and other technologies, I could say that they both have a point, and it's a point that I've personally found increasingly frustrating over the years. Specifically, I’ve noticed the following:

  1. I find it significantly easier to be productive with Python or PHP than with .NET.
  2. When I’m working with .NET, I find it significantly easier to be productive with client-side JavaScript and HTML than with C#.
  3. By far the biggest productivity killer in .NET is the edit/compile/test loop.

Here’s the difference. When you’re working in an interpreted scripting language such as PHP, Python or JavaScript, making changes is simple and fluent. You edit some code. You run your tests, or hit F5 in your browser. You see the results of your change almost immediately. Lather, rinse, repeat.

On the other hand, in .NET, once you edit your code, you have to re-compile your project. If your change is to the front end of your code, such as a tweak in your .aspx page, this might not take long. But if you are making changes in the back end, it can take a sizeable fraction of a minute. Then you have to re-load your project, with all its dependencies, into memory. For a large project, with a lot of dependencies, this can take a minute or more. And of course, that’s assuming that Visual Studio doesn’t freeze altogether in the process, which it very often does.

Now here’s the killer. Increasing the feedback time from ten seconds to over a minute knocks you right out of the zone. When you get quick feedback, you remain fully engaged, and fully focused on the task at hand. On the other hand, when you have to sit and twiddle your thumbs, it becomes increasingly difficult to resist the temptation to go and get yet another cup of tea, or switch to something else and get distracted. Even if you don’t, you still have to pick up the threads of what you were thinking about before you started. It can easily make a difference of an order of magnitude in productivity if you’re not careful, and even if you are, it’s still pretty wearying.

Incidentally, Joel Spolsky makes exactly this point in the Joel Test when advocating quiet working conditions and the best tools that money can buy.

However, it isn’t always possible to avoid .NET altogether: to do so would be to cut yourself off from a lot of opportunities, and I’m certainly not ready to throw in the towel yet and switch completely to Ruby on Rails, as some people do -- noisily. So, that being the case, what can you do to alleviate the situation?

Here are some suggestions worth considering:

  • Use a lightweight text editor such as Notepad++ or vim alongside, or perhaps even instead of, Visual Studio. Yes, you lose IntelliSense and integrated debugging, but this forces you to rely more on test-driven development, commit the APIs that you use to memory, and get into the habit of paying more attention to detail, and that only benefits you in the long run. Besides, that’s how we code in other languages, and we’re none the worse for it. As long-time Windows programming expert Charles Petzold will tell you, IntelliSense and integrated debugging dumb you down.
  • Have as few projects in your solution as possible. Lots of projects mean lots more dependencies have to be loaded, and that can dramatically increase compilation times. Also, keep your layers of abstraction to a minimum.
  • Alternatively, if you genuinely need a lot of projects, use more than one solution. That way, you reduce the risk of accidentally triggering an unnecessary “Rebuild all.”
  • Resharper is great, but I’ve found it uses a lot of IDE resources and increases the risk of freezes. Unless you have plenty of memory (like, 8GB or more) at your disposal, consider turning it off.
  • Disconnect from the Internet when you need to focus on what you’re doing.