Dotmad.net

Recently I had to spend some time to fix a crash in the application I’m working on: I kept getting an OutOfMemoryException with no relation to the amount of free memory on the computer.

Eventually I found the bug: turns out the DrawArc method doesn’t like to be called with a very small angle, so it goes BOOM.

Another tidbit I found while searching for the cause was the fact this behavior is not unique to this method:

“The thing I can add about this is that GDI+ tends to throw OutOfMemoryException when something else is going on. I’ve seen people complaining about this in the newsgroups and elsewhere on the internet.

So we have here a framework with the habit to fail very un-responsibly.

Hmm, why does that sounds familiar?

Somehow I get the feeling that while Microsoft employ 50 people to handle a single feature, no one is left to take care of exceptions and errors in their products.

(in the photo: Windows Vista security exception)

After going this week to the Microsoft performance open house, here are few things to consider:

• Create performance counters of your own to measure various statistics.
• Try to avoid using interfaces and virtual methods to supports inlining.
• If you use a “Contains” method of a collection on structs, be sure to override the “Equals” method, since the default Object.Eqauls method used boxing twice - once for the parameter and the once for “this“.
• Similarly, you should override the GetHashCode methods for structs, since the default implementation for a struct is very inefficient.
• Use Perfmon.exe to monitor the “% time in GC” - a high value may indicate mid-life crisis.

Coffee is good for you, as long as you don’t drink too much.
But how many of you can’t pass the day without drinking too many cups?
How many of you are addicted to coffee?

In the recent bloggers meeting in Microsoft Israel I complained about the pain it is to add a picture to a blog post using the Community server.
The reply?
“Why don’t you use Live Writer to publish posts instead of the online control panel?”

In a recent post Doron wrote about his love for ReSharper:
“I honestly can’t work without it anymore. It has changed the way I code, and I will never attempt a serious refactoring without it“

There are many great tools out there that can make you more productive. No argument about that. The problem starts when you become dependant of those tools.

That’s the problem with crutches - if you ever lose them, you become handicapped.

I went to a lecture by David Platt on the subject of “Why software sucks”, which discusses what is wrong with software today (hint: it’s mostly designed by programmers) and how we can improve it.
From listening to a previous ARcast with him I already knew he is a very entertaining speaker, and he proved me right (in fact, I kept thinking I could bring my wife to one of his lectures and she would have enjoyed it as well).

David began his presentation with a screenshot from the Better Business Bureau in the US, listing complaints by industry, and the amazing thing about it - people dislike software more than they dislike used-cars salesmen!

The main idea of the presentation (backup up with all sorts of amusing anecdotes):

• People don’t buy software for the sake of the software itself - they buy software to get something done. They are not interested in using the software, they want to have used it.
• Programmers tend to design software for people like them, while most users are very different.

Platt’s solution resolved around 5 key points:

1. Add a virgin to the team - add someone to the team with zero knowledge about the inner workings of your software.
2. Break convention if needed - don’t behave in a certain way just because all every application behaves the same way.
3. Do not let edge cases complicate the main stream - extra features aimed at edge cases complicate your software and make it counter productive.
4. Instrument (Carefully) - Try to gather information about the way users use your software without harassing them.
5. Question each decision - ask if each decision is taking your project closer to the result or further away from it.

The lecture itself was followed with a Q&A session, in which I asked him a question (which landed me a signed copy of his book - thank again, David!):
If programmers are so bad at designing UI, why not bring in a specialist to do it?
His response (after correcting me for saying “Graphics designer” instead of “User interface designer”) was it’s actually a good idea, since most of the industry is already headed for specialization in various subjects.

I found another podcast on ITConversions network, and here are two short videos from the presentation:

Did some blog reading today, and found out several assumptions I had which were wrong:

• Assumption: “Protected Internal” means both protected and internal
  Wrong: It means Protected OR Internal.
• Assumption: 32bit Windows is limited to 2/4gb ram
  Wrong: It’s limited to 2gb of ram per application.
• Assumption: OpenFileDialog is harmless
  Wrong: It loads a mini-explorer, including all the extensions you have installed.

When you study computer science and you start learning algorithms, you are introduces to the O(n) concept, meaning there is a different between an algorithm that takes linear time (1 second for 1000 items, 2 seconds for 2000 items and so on) and an algorithm that takes exponential (2 to the power of n) time, meaning it’s a very inefficient algorithm.

Although this lesson is important, there is a darker side to this kind of thinking - you tend to ignore efficiencies with the same order of magnitude, meaning an algorithm with 10n efficiency and 80n efficiency are the same to you, even the first is 8 time faster than the second. This means that if you choose the first a certain procedure may cause the user to wait 250 milliseconds, while the second will delay the user for 2 whole seconds - big difference.

So don’t consider to n values to be similar just because they are within the same order of magnitude.