Simplicity

A couple of days ago while on my way to work, I was listening to Erno Rubik on an interview on NPR (yeah, I know, leftist media).

At one point the host (Doug Fabrizio, I believe) asked: "Why did you choose a cube? Why 9 squares on each side of the cube?" To which Mr. Rubik answered something to the effect of:

Well, I was trying to come up with the simplest solution possible. And that actually turned out to be very hard; it's always very hard to define something in it's simplest terms... (and a few more minutes of explanation about why reaching simplicity is so hard) Anyhow, I wanted to find the simple form to teach my students how to describe movement in mathematical terms; a cube with nine squares was the simplest way I could do that.

I just loved that answer. I've long had a feeling that when writing software the simplest solution will always be the most maintainable solution. Simplicity is the core principle on which YAGNI, DRY, and so many other software engineering ideas are built. As DaVinci said:

Simplicity is the ultimate sophistication.

So here's this post in honor of writing simple, sophisticated code. Long live simplicity!

Visual Studio 2010 Debugger Not Attaching Problem

Since we moved to Visual Studio 2010, I've had 3 people ask me: "Is there some sort of magic you have to do to get VS2010 to attach to the IIS worker process (w3wp)"?

So, in the interest of (hopefully) saving you some time, I figure I'd write a little bit about what the problem with the VS2010 debugger is. Actually, the debugger is fine, it doesn't have any problems attaching; it's actually VS2010 itself that has a minor bug(?) while attaching.

As you can see in the image below, under normal circumstances Visual Studio automatically detects what type of code the process is running and automatically chooses the correct debugger:

Unfortunately, however, I've found that sometimes VS2010 cannot detect the correct code type in the worker process and attaches to the process using the .NET 4.0 debugger (I don't know why this happens nor do I know if this happens when attaching to other processes).

If you attach using the wrong debugger, you'll attach, but you'll notice that none of your symbols ever load and therefore none of your breakpoints ever hit. It's actually somewhat frustrating because everything looks like it should be working but doesn't.

But enough talk about the problem; here's all you need to do to solve the problem if you notice you're not using the right debugger:

1. Hit the "Select" button the in "Attach to Process" window.
2. Select the "Debug these code types:" radio button
3. Check all the code types you want to debug.

You're shooting for something like this:

I've found that after you choose the code types you want to debug, VS2010 remembers your selection, so you should never have problems attaching in the future.

Now, if I could just get rid of that stupid dialog asking me to confirm if I really want to attach to the "potentially dangerous" w3wp process, I'd be set. :)

3 Simple Rules To Good Object Oriented Code

Mike and I had a long discussion about BDD last night. After he complained about how BDD didn't lead him to the solution he wanted, I said something to the effect of "You know, the only reason we have all these design methodologies is because we don't really know how to think OOP and write OOP".

At this point, before I continue, I need make something clear: I don't know what I'm talking about; all I know about BDD is what Wikipedia says about it. But I do know that writing good OO code doesn't require 3 different methodologies. All it requires if for programmers to think like objects.

I like to think that good OO comes down to 3 simple rules:

1. Objects are all about behavior; not attributes. If attributes defined objects, a cat and a dog would pretty much be the same thing since they both have eyes, noses, legs, etc.
2. Objects are discrete things from which you can build other things. They're a lot like LEGO blocks. Incidentally, code reuse is a byproduct of good OO code, not the purpose of it.
3. Objects like to be autonomous self directed entities. Objects don't like "managers"; if your code has lots of managers, you're probably doing something wrong. Objects like to coordinate their work through events; they don't like managers telling them exactly what to do at every point.

A bonus rule: Composition is usually better than inheritance; it gives you a lot more flexibility when having to change behavior.

To be honest: I'm mostly writing this because I'd like to hear from others what guiding principles you should have in your head when coding. Do we really need a lot of process if we just in our guts know how to write OO code?