I recently posted about a problem I had with the Microsoft CTP DataGrid I was using. I quickly got a response from Odi from Xceed, asking why I wasn’t using theirs. Good question, and deserves it’s own blog post.

The truth is, I’ve been burned by third party controls in the past. In general, third party controls work great when used in the sterile lab environment. The problem is, it seems like every project I work on has some requirements that tend to break them.

For example, a recent website I worked on had a requirement that every page had to have an HTML extension, even though every page was an ASPX page. Depending on how it’s implemented, many third party controls just couldn’t handle it. In fact, it’s hard enough to get the core ASP.NET functionality working properly with some features such as postbacks. Adding poorly written third party components would have made things worse.

Ok, so why is it alright to use Microsoft’s controls instead of something from a third party? In my experience, the code the Microsoft gives you tends to be lacking in real functionality, but is usually very reliable. Even when they’ve had an issue, there was enough support to get a work-around, and probably a fix in the next service pack. Microsoft products tend to get better over time, and without any upgrade fees. They are a well established business with a guaranteed audience.

Let’s take the .NET TextBox as an example. Ever run into a situation where you’ve found it to be unreliable? I haven’t. I have run into a situation where a third party alternative had all the bells and whistles you could think of, but had some major issues. You push the up arrow and the application bombs. Darn. You could only use it in a certain way, or it wouldn’t work at all.

K.I.S.S - Keep it simple, stupid

Is this a rule, or a good practice to follow? Depends what you need. I use third party dependencies all the time. I typically only use them if they’re in widespread use, mature, and under current development so I know fixes will be round the corner. For example, here are a couple of great ones that I recommend:

• Log4net
• NHibernate
• RhinoMocks
• Spring.NET

If you’re curious what criteria I use when looking for a third party control, be sure to check out my post about 10 things to look for when evaluating third party controls.

In general, I think Joel has a good guideline:

If it’s a core business function — do it yourself, no matter what.

I’ve tried desperately to come up with a great example of when his rule doesn’t work. At one of my previous jobs, I wrote a lot of reports using complex charting. We had a great third party charting library, but we always had strange ways of working around its interface. It’s probably the best example that I might have to counter his rule, but it probably wouldn’t have taken any more time if we had written the charting ourselves.

Conclusion

If you need a quick and dirty simple control, and it’s already part of your toolbox in Visual Studio, just use it. If you outgrow it, or have some special requirements, see what is out there. In my case, I think the Xceed grid would have been overkill. Microsoft will fix their bugs, and my application will only get better. If you need a grid that does more than display some simple data, take a look at what Xceed or another vendor offers. Their control has certainly been around the block, and looks like it has a lot more features.

I’m going to describe a methodology that will help you save time by writing better classes, and will help simplify your life by allowing you to solve problems with a top-down approach.

Developers such as myself often have a tendency to just focus on the class we’re currently working on. Of course I believe this is a good thing, because we all know the importance of focus. However, you should never forget the reason you’re actually writing that class. It is because other code will be consuming it.

There have been far too many instances where I would figure out which pieces I needed to build, and then build each one, from the bottom up. The problem is that I would write the class in the most short-sighted and easiest way possible, which is usually not the best way to use it.

Now, when there is a question of what a class interface should look like, I ask myself what it should look like to make the life of the consumer as easy as possible.

Sometimes we can even take code usability to an extreme. For example, Fluent interfaces, which allow you to chain together multiple calls. In many instances, this makes the code much easier to call, potentially at the expense of making the called code more complicated.

I’ve come up with a simple example to help illustrate. Suppose I need to process a list of x,y coordinates. Here are a couple of potential signatures:

• ProcessData(double[] xData, double[] yData);
• ProcessData(PointF[] points);
• ProcessData(IDictionary<double, double> points);

For now, just ignore the performance implications (they’re going to be linear in this case, or close to it anyway). To choose the correct signature, we need to know who the caller is.

Of course there is a good chance that we’ll have a slight intentional leaky abstraction. In the previous example, we may have been able to use the IEnumerable generic to be more flexible. That’s a topic for another day.

Thankfully, this problem is minimized, although not always eliminated when you follow the single responsibility principle. The better you can follow that principle, the simpler each piece will be. That tends to minimize the potential for the consumer to need the interface to look different than it would naturally be.

Another way to look at your classes from the consumers point of view is to practice test-driven development. In fact, I see this as one of the strongest arguments for test driven design. For each layer in your code, you’re creating code by consuming it before writing it. Every layer acts as an API to the layer above it.

In conclusion, I’m simply recommending that you don’t lose sight of why you’re writing that piece of code. You’re not just writing code for the sake of writing code, you’re writing it to be used!

Today’s tip is a hack for getting awesome tech support from a company for a product that you may or may not have purchased. It may not be polite, but it may be a method of last resort.

We all knows what happens if you buy a product and then call for support. If you’re lucky, you get put on hold. If you’re unlucky, you’ve called outside of their business hours of 1am to 3am. When you do talk to someone, you’re treated like an idiot (in their defense, it’s a learned behavior).

If you want great service, call their sales department. Tell them you’re evaluating their product, but ran into an issue. You’ll be talking to someone that actually wants your business. They’re typically very helpful, and remind us of the benefit of good customer service.

Just today a coworker sent me a link (unrelated site) that had a link to a page called "Pre-Sales Questions". They’re openly distinguishing between potential customers, and paying customers. The problem is that they make the pre-sales question form easy to use, but the paying customer form is not. Customer service is in a bad state.

My official recommendation is to to fully try out their product during a trial, so that when do you do talk to their sales team, they can at least earn a sale from it. Like I said, this is a method of last resort.

One of your goals as a developer should be to make your code as readable as possible, both for yourself, and for the other developers you work with.

One great way to determine if your code is well written, is to ask yourself if the code you’re writing is readable by itself. Another developer should be able to jump into a module, and have a fairly easy time seeing what’s going on. They shouldn’t have to sift through thousands of lines of interweaved code to figure out what’s going on.

Of course, what I’m talking about is simply a test for the single responsibility principle. If you’ve written a huge "do it all" class with thousands of lines of code, you’re ensuring that you’re the only one that will be able to maintain it. That that type of code usually suffers from high coupling to the other modules in the program.

I used to organize code into classes based on the type of functionality being provided. I used them more as containers for related functionality. At the time, I didn’t see a reason to split it apart. I was very wrong.

In a recent article by Jimmy Bogard, he walks through creating classes with a separation of concerns. In the conclusion is my favorite part:

Now we have many more classes (4 vs. 1) and interfaces (3 vs. 0).  For those who don’t like more classes, GET OVER IT.

That is an excellent point. Why should you be afraid of creating more classes and interfaces? It’s really not more code to write, in fact, it’s often less. Refactoring tools remove many of the obstacles of maintaining the interface, class, and method structure

When someone looks at your code and you have 4 classes instead of 1, and those classes are very specific and short enough to process by our tiny brains, it will be much easier to maintain and modify (or even better, extend).

As I mentioned before, I’m trying to consolidate the number of websites that I have to maintain. My young-technologies.com domain was badly out of date, and didn’t really have any useful information. I decided to redirect all of it’s pages to this site.

The only page that was getting real traffic on that site was the Subversion virtual machine appliance, which I created a long time ago. I decided to move that page to this domain. That means that I have only one page to manage instead of an entire domain.

If you haven’t seen that virtual appliance, it’s worth checking out. It’s basically a fully functional Subversion install on Ubuntu linux, with WebSVN installed to view it in a web browser. It’s been downloaded over a thousand times, and it’s now being hosted using Amazon’s S3 service.

While the appliance has found a new home, I’m not sure if an when it’s going to be updated. If there are any future announcements about it, they’ll be made on this blog.