Jon Kruger’s Blog

Third-party tools can be very useful, if not essential, when developing applications. But what I find really interesting is the way people talk about and criticize third-party products. Here are some observations that I’ve noticed over time:

Most developers think that if they had the time, they could do a better job of developing a third party product than the people who actually wrote it. OK, I’ve been guilty of this one too. This probably the same reason that most developers, when given an application or module that they didn’t write, will usually recommended that it be completely refactored and rewritten. We don’t always understand code that we didn’t write. This, however, doesn’t make the code bad.

Have you ever tried and develop a base control for your team to use? It’s hard! You create it and people start using it, but then you find something that you could’ve done better, but going back and changing it is really hard because now all of these other people are using it and you might break their code. So I have lots of respect for people who try and write controls that 10,000 people are going to use.

Also, most developers are much quicker to point out the fault of a third party package than they are to point out the good aspects of it. Case in point: CSLA (the business object framework). I worked on a project recently that used CSLA and I liked it. There are a few quirky things about it, but nothing that I couldn’t live with. But almost every time that I have brought up CSLA in a conversation, the person I’m talking to spouts off numerous things that they don’t like about it (usually stylistic things, never “I won’t be able to do what I need to do if I use CSLA.”). So if they don’t like CSLA, what’s their alternative? Almost always you hear, “Oh, I’m just going to write my own business object framework.”

Let’s think about this for a second. Granted, a simple business object framework isn’t that hard to implement; you can get by with just providing ways to do validation, loading, saving, deleting, and dirty state and be OK in some situations. But let’s say you want more complex stuff, like a rules engine. Do you seriously have that much spare time on your project that you have time to develop your own complex business object framework? Man, I need to come work on that project!

My point is not to champion CSLA and tell you that you should always use it in all situations. (I will say this about CSLA though — the project that I worked on that used CSLA was the most well-structured and organized code base I’ve ever worked with, the code was really easy to read, and new people could join the project and figure things out pretty quickly. The developers deserve a lot of the credit for this, but CSLA helped everyone use good coding practices and patterns.) The point is that, in my opinion, just because you have issues with someone’s coding style, their overuse of reflection or generics, or whatever it may be doesn’t mean that you should completely ignore a third party product and go off and write your own! The real question you need to ask is whether or not the software is going to provide business value and help you accomplish your task better, faster, and cheaper.

So next time you have to evaluate third party software, ask yourself these questions:
- Is this software going to provide business value and help me accomplish my task?
- Is something in this software package going to prohibit me from doing what I need to do?

• Leave a comment... (0)

The patterns & practices group at Microsoft just announced the Policy Injection Application Block. The basic idea is that you can define a set of policies and handlers that will execute before and after certain policy-enabled methods. This will allow you to perform such tasks as validation, exception handling, authorization, etc. without having to write the same sections of code over and over in every method.

The main benefit (as I see it) is the separation of concerns. How many times have you worked on a project where someone told you, “Make sure you call this method at the beginning of every method that does _____.” or, “Make sure you put this specific code around your code to handle exceptions.”? It’s hard for everyone on a team to remember all of these little tricks, and you also run the risk that people on the team won’t always do everything correctly. My boss always says that we as developers need to “get out of the plumbing business” and write code that actually does something meaningful from a business perspective, and this will definitely help accomplish that goal.

But in reality, the first thing I thought of when I first heard about this was that many people will probably find many ways to misuse and abuse this application block. By giving the people more power, you’re also giving them more power to screw things up. I’m sure there will be some interesting anti-patterns with this application block.

• Leave a comment... (1)