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.

Comment on this »

Posted at 08:00 on 28 March 2011.
Tagged: .NET, productivity

I came across this article today when I was googling for a link for another blog entry. I was flabbergasted to see that it was written by someone with a PhD, appears in a professional engineering journal, and is currently linked from their home page:

Over time, there have been many attempts to define metrics that effectively measure software development productivity. Most of the ones that I have seen are amazingly complicated and very difficult to apply.

I think there is a simpler productivity metric which should be used across the industry: the total number lines of code in the organization divided by the number of people who are working on that code (including QA as well as development). For short, I will call this metric the LOC per head.

I propose that this measurement is an excellent representation of the development organization’s true productivity. If the number rises, it means that the development organization is more productive. If it decreases, it means that the organization is less productive

Ah, the old lines of code chestnut again. For some reason, managers seem to love it. The only problem is, it’s totally brain-dead. Like government targets, any formal productivity metric can and will be gamed — usually with disastrous results, as Joel Spolsky points out.

You want lines of code? Be prepared for your code base to be poisoned with endless copy and paste code and needless repetition, which, as any competent developer will tell you, is a nightmare to maintain. Or you may even end up with a joker on your team who decides to script the process and produce a million lines of code a second without even turning up at the office.

Besides, some frameworks such as Ruby on Rails or jQuery allow you to accomplish much more with far fewer lines of code. The first release of 37 Signals’ Ta-Da List — a full-blown commercial product — contained less than 600 lines of Ruby code. So does that make DHH and colleagues unproductive? Of course not! On the contrary — it makes them brilliant.

You want lots of check-ins to source control? Fine, you’ll end up with dozens of them just to correct a single spelling mistake — and as a side effect, a version history that leaves everyone totally confused as to exactly what’s been going on.

You want lots of bug fixes in the issue tracker? Expect your developers to deliberately write bugs into their code so that they can “fix” them.

You want to compensate for this by penalising bug reports? You’re asking your developers to mislead your testers about what functionality is actually in the code base so they’ll pick up on fewer bugs.

And so on, and so on.

As the old computing adage goes, garbage in, garbage out.

Comments closed »

Posted at 23:25 on 31 May 2008.
Tagged: human nature, idiocy, metrics, productivity