james mckay dot net

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.

Comments closed »

Posted at 08:00 on 28 March 2011.
Tagged: .net

The repository pattern is popular in a lot of .NET applications. In most cases, it is implemented as an abstraction layer around NHibernate “just in case” you want to replace it with Entity Framework.

Why on earth would you want to replace NHibernate with Entity Framework?

If you suggested something like that to a Java developer, or a Python developer, or a Ruby developer, they would think you were completely out to lunch. People simply do not abstract out the Django ORM “just in case” they might want to replace it with SQLAlchemy. Or Rails’ ActiveRecord to replace it with DataMapper. Or Hibernate to replace it with iBatis. They pick one or the other and stick with it.

There are four reasons why it’s a bad idea to code for this eventuality.

1. YAGNI.
2. It just adds an extra layer of indirection into your application, which complicates the changes you need to make on a day-to-day basis, and makes your code harder to understand and debug.
3. Changes this fundamental generally require a lot of work and a large rewrite anyway.
4. Due to differences in the way NHibernate and Entity Framework work, you will either (a) have to restrict your code to the lowest common denominator between them, making it all but impossible to carry out any form of performance optimisation, or (b) implement something so complicated that it’s not worth the effort.

So why do we do something like this in .NET land? I think a lot of it reflects a malaise in the whole Microsoft ecosystem. It’s a fear that Microsoft will replace the solution we’ve picked with their own version, make it the standard, and in three or four years’ time, our library will no longer be supported.

Unfortunately, that’s the way things seem to work on the Microsoft side of the fence. The whole ecosystem is littered with the corpses of dead third-party libraries: ASP.NET charting components, Ajax toolkits, and so on, that were once sold by thriving commercial vendors that have now gone out of business. They’re .NET 1.1 only, and don’t work with .NET 3.5 or 4.0. And because they were commercial products, and were obfuscated using Dotfuscator or whatever, there’s no way of getting the source code.

But NHibernate is open source. It’s widely deployed all over the place. It’s still in active development. It’s a direct port of the de facto standard Java ORM, so you can put Java guys to work on your .NET project with minimal training. For that reason, it’s not likely to disappear into the great unknown any time soon.

Comments closed »

Posted at 08:00 on 3 March 2011.
Tagged: antipatterns, design patterns