Predictability is a key feature

You can run a rally car on ice. You can travel under water. You can create a fast program based on slow components.

This is all due to predictability. While racing on ice you know more or less what friction you will get and what it will take to change direction. You will know how far you need to see ahead to be able to stay on track. If that criteria is met you can go as fast as possible.

On the oter hand, if you are racing on a mixed surface, you have to go slower. While you have traction you have to drive with a big margin to be able to control your skid if you suddently loose traction. While you lack traction you have to drive slower because if you skid around the corners and reach a high friction area you will end up in the ditch. Given the choice I would definately choose the high predictablity over max traction.

If you know all the parameters of a software project up front you are pretty safe. If you know all the parameters up front, you will also be the first in history to do so. Are you so sure of your requiremetns that you can choose components that fulfill your requirements but are not flexible enought to handle requirement changes? Are you so sure of your performance demands that you  can choose components that perform well but don't scale if your demands change?

Flexibility is often a an underrated feature. Its hard to put in sales brochures. Its hard to tell customers that the extra cost is to support their requirements in the future that they are not aware of yet. Often it has to do with how mature an IT project organisation you are dealing with. The more mature it is, the greater the chance of it expecting changes in the future and the more flexibility it wants from its IT systems. My experience is that these changes will amerge before the end of the project and the flexibility will end up saving them money before the project has ended.

Consuming generic types as a generic parameter

What is he talking about? Well, I have a hard time expressing myself when it comes to generics. I'm trying to make a library I can use across projects

This is what I want to do:

interface BusinessEntity<T>{...}
class EntityList<T> where T : BusinessEntity<TT>{...}

That way I can let my domain objects implement the BusinessEntity interface and they can be consumed by my EntityList. In the following I have a domain class called Document.

//defining Document
class Document : BusinessEntity<int>{...}
//creating instance
EntityList<Document> list = new EntityList<Document>();

To me this all makes sense. Sadly it doesn't compile :( The problem is that TT in the EntityList is not defined. As far as I know I have to define both T and TT on EntityList even though TT is given once I have defined T. Now it loks like this:

//definition
class EntityList<T,TT> where T : BusinessEntity<TT>{...}
//creating instance
EntityList<Document,int> list = new EntityList<Document,int>();

I'm not to happy about the extra generic parameter on the EntityList. Once T is defined, there can be only one valid type of TT. But because of the way you have to define it, the compiler will not complain about the TT, but actually about the fact that T doesn't implement BusinessEntity<TT>. This means that if TT is defined as string for instance, the error message from the compiler will be: Error, Document does not implement the interface BusinessEntity<string>. This will make no sense to the programmer trying to use the class.

If you have any solution to this, please let me know :)

3rd party software

I'm a bit swamped by 3rd party software at the moment.

3rd party components are good in that they provide a lot of functionality that is already implemented and hopefully also tested. Sometimes I don't think using 3rd party components is the best solution. Sometimes the dependencies are large, and the problems created by these dependencies are greater than the benefits gained from using this 3rd party functionality.

I don't avoid using 3rd party components, but I do have some general issues that I address while deciding whether to use a component.

• Transparent
  Although I select a 3rd party component to reuse allot of its functionality, I like to understand what it does. If i understands its functionality on an abstract level, I'm less dependant on the component in the future.
• Few dependencies
  When I choose a component, I choose it for its features and behavior. I don't want to be handcuffed to other products that I don't intend to use. Even if I want to use the other product, I want be the person making that choice.
  
• Expandable
  I want to be able to plug in my own functionality where ever it makes sense. This could mean an event based approach or something based on contracts