Doron's .NET Space

Random

(Just had to share this amusing comic from xkcd.  And please ignore the camel casing, they're probably Java people)

Wish it Away

I am currently reading Steve McConnell's great Rapid Development book, in which the author marks "wishful thinking" as one of the greatest mistakes one can make in software development. McConnell managed to express in two words the root of most problems in this field, and probably the main cause of most of my own mistakes.

You know how it is. Sometimes you wish yourself to succeed. "Sure I can make it in a week". "So what if we have two weeks to complete a two months work. It will work out". That's you wishing it away. I consider myself a rational person, and still I can look back and see quite a few times in which I behaved very irrationally, thinking everything will be just "be OK". So you ignore that nasty looking bug, only for it to rear its ugly head at the final testing phase, and by then you don't have the time to fix it. Or you agree to add those extra features, thinking they will be rather easy to implement. Or should I say, wishing them to be so. They won't, not because you wished it so, that is.

Ever since I became the team's lead (only a few months ago) I've started forcing myself to do reality checks. Are we really going to make the schedule? What exactly is it going to take for us to succeed? I find it useful, for example, to picture in my mind the week in which we have to install the new version of the software we're developing. What will happen, exactly, during that week? Who will have to do what, what kind of hardware, software licenses, or people we're going to need during that week? What can happen that will prevent one of these things or people to not be there for that week? What will we do in that case? I also became quite paranoid about difficult looking bugs. I've learned that ignoring them, or thinking that "It's because we're using IIS 5, it will be OK when we install it on IIS 6" tend to not solve bugs.

Then I translate all this paranoia into a risk-list, in which I list everything that could possibly go wrong, and ask myself what am I going to do to stop them from going wrong. At first I thought risk management was boring and useless. Now my paranoia-list control my schedule. It's what I base most of my actions on.

The best advice I can give you, and especially to myself, is to never look the other way when you smell a problem. If it smells like a fish then it's probably a fish. You can't wish it into a steak. Plan ahead, manage your risks, be paranoid. When things go wrong, you'll be ready, or at least you'll feel you did everything you could.

More on Fusion

ReSharper + Orcas = Bad

A small warning: Do not install the pre-release of ReSharper 3.0 on Visual Studio Orcas. Although the installation works, ReSharper does not handle the C# 3.0 syntax correctly (it really doesn't like x => x+1 syntax), and the intellisense gets all screwed up. Trying to uninstall ReSharper 3.0 resulted in my VS Orcas having an empty "ReSharper" menu, and with the intellisense gone, which I had to fix manually (by scanning the options menu for about an hour for the right option). To add to the fun, my installed ReSharper 2.5, which is installed on VS2005, has lost its highlighting features in the process, so I had to reinstall the 2.5 version. Fun.

Study List

You know that feeling that you have too much to learn and too little time? Well, I'm currently attempting to learn the following things:

• Unit Testing and TDD (using NUnit and RhinoMocks mocking)
• Castle Stuff
• ActiveRecord (and through it, a little bit of NHibernate)
• MonoRail (MVC framework for ASP.NET)
• Windsor (IoC container)
• Boo (python-like language for .NET)
• C# 3.0 and LINQ
• SQL Server (but just a bit)
• Working with Resharper (especially template authoring)

I am now trying to a simple web project in which I will incorporate all of this, and it is turning up to be quite fun and challenging.

My strategy is this: Learn almost nothing up front. Try to do something. Get stuck. Learn what I need to solve the problem. So I would learn only the most basic ActiveRecord stuff to start working, but as soon as I hit a road-block (changing the naming strategy for my property-column mapping) I dig in the documentation. This works quite well and prevents me from reading long articles/documentation sections up front. I just take what I need and move on.

Still, this is very time consuming. It also makes me glad I haven't begun doing my masters degree. What I'm studying at home just seems a lot more interesting and useful, and I know that going back to the university will leave me little time, if any, to really learn new technologies.

DLL Hell v2.0

I'll be the first to admit that I was never a COM programmer, so I had never experienced COM's original DLL hell. From what I hear, it was really gruesome. No standard in DLL versioning, programs overwriting each other's DLLs, and generally the kind of chaos in which stuff don't work and you have no idea what's wrong.

.NET's assemblies, with their standardized naming and versioning, have definitely made our lives easier. Once we have a DLL, we know exactly what version it, and what version of other DLLs it's using. But I feel, that even in .NET, it is still too hard. I have spent hours trying to figure out TypeLoadExceptions/MissingMethodExceptions/'Expected version 1.0.2.32 found something else' exceptions, caused by weird versioning issues.

Not to mention exceptions similar to "InvalidCastException: Cannot implicitly convert type Geometry.Circle to Geometry.Circle. An explicit conversion exits (are you missing a cast?)". No, I'm not missing a cast, it's the same bloody type! Once you've spent a while looking at assemblies' manifest in ILDASM, verifying the versions of their dependencies, you know something is wrong.

And the new Stock project model of ASP.NET has made it even worse. Man, the time we burnt on weird compilation errors, claiming there are different versions of DLLs in the GAC and in the temporary ASP.NET directory... (Side note: together with long compilation times, missing project file, and extremely annoying assembly referencing issues, I would think hard before I would use this kind of project for a new web site. The good old .NET 1.1-like WebApplication project is looking pretty attractive right now).

My point is this: yes, I guess a .NET developer's life, versioning-wise, is not as hard as what a COM developer's used to be. But they're still not peachy at all.

Update: My friend Idan (a link to his hebrew speaking gaming blog) has sent me a link to this interesting post which talks about assembly loading and binding. It also alerted my attention to the fuslogvw.exe tool, which can assist you with the mysterious exceptions I mentioned in this post.