My Prefered Developer Profile

My preferred coworker has the following qualities:

• Lazy: I want the person to avoid repetitive work. Some might say that repetitive work is part of the job. I think repetitive work is a sign of bad architecture. Repetitive work should be avoided at all costs.
• Rebellious: Don't accept everything I say. I'm just human and might be mistaken. I get suspicious if no one challenges my ideas.
• Geeky: I want developers to be enthusiastic about the work they do. All the time they should be striving for better solutions to the problems we have.
• Have a hobby: Software development is not everything, and a lot of software ideas spring from problems outside this business.

And probably some more :)

Comma Separated Values

Or csv file extensions for tabular data.
I thought the name described the format, and that it was as simple as that. It was only when I tried to read such file in MS Excel I found out it is not the case. Apparently my regional settings requires csv files to be semicolon separated. So much for international documents :)

When to use the GAC

I've been using the .Net framework for a few years now. I still haven't really found a use for it...

One of the good things about .Net is the xcopy deployment strategi. It is kind of lost when the gac is used. With the gac your solutions suddently start to depend upon each other a lot more.

Thanks, but no thanks: No more GAC!

If anyone out there has a good use for the gac, please let me know :)

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 :)

Platform as a religion

I don't like job titles like "evangelist". I instantly think of religion and that they believe they have found the one true answer they are going to preach to me. I believe solutions only can be measured against real problems, and if the problem is complex and abstract, the outcome can be hard to conclude anything upon.

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
  
  

Open Source

Open source is not very popular in the MS community. Here is my list of why I think Open Source is so great.

• It gives credability to the product being open sourced. It doen't make the product better, but as I can read the source the producer will be more willing to write robust and transparent code. The maker lets you check if the product is any good or not behind the scenes, and if the makers lets you see that, its probably not too bad.
• It makes me less dependant of a product. If the maker goes out of buisness, I can still get errors fixed.
• The producer can benefit from others reviewing the code.

Following Orders

Is it a problem that people don't know how to follow orders any more? Everything has to be discussed. I have met people who beleave it is, but I don't.

I think this human behavior is the main reason that we have evolved like we do and we all the time discover new things. I generally don't like to work with people that don't question what I say or do. Likewise I generally don't accept orders from my boss without a reason.

This doesn't mean that I can't do thing people tell me without asking question. If they have proven to ask reasonable things of me, I will do it right away.

Its all a matter of motivation. There is no such thing as a boring task. So far I haven't found a task in this business that I somehow couldn't turn interesting. If my project manager knows and understand my preferences he will be able to motivate me.

I once had a project manager who's standard motivation line would be: I know this a crappy task, but you just have to do it. That didn't motivate me and in the end I quit that job. He could instead have said: I have screwed up... you will really make my day if you can fix this for me.
To me project management is mostly about motivating project members to do the right thing. If they are motivated, following order will be easier, and productivity will be much higher.

What is SOA all about?

Do you think SOA is about software development? Do you think SOA is about making two systems communicate?

I don't!

I think SOA is about abstraction. I think SOA is about specifying needs and capabilities. SOA is about dividing your domain into smaller parts and being able to outsource it.

This can be applied to software or any other domain where you have parts communicating. I think it is great for structuring organisations. SOA is great for figuring out who needs to talk to who and why.

What I'm trying to say is that I don't think SOA is limited to software. Every time I hear people specifying resources they need and afterward seeking resources matching their needs, I think SOA..

Sometimes I hear about SOA as being bad for performance or that it doesn't scale well. I don't think SOA is about performance, it is about specifying needs and secondly fulfilling them.

Language preferences in domain model design

Every time I start on a new project I face the same dilemma: What language my domain model will be written in.
Generally I prefer English because it fits nicely into most programming languages, and foreigners will be able to understand it. I have done a lot of government law based applications, and sometimes English adds quite some complexity to the model. When there is no exact translation of the terms, you end up with a lot of nonsense of approximated terms or made-up words in the model and you need a great deal of commenting for anybody to understand it. Its not a domain model your domain experts understand.

Working with multiple languages is a pain, and I don't recommend it. I have seen lots of projects where the domain model was a mix , and it just adds complexity to the project.

I would very much like to hear your thoughts on this.. How do you handle developing for non English domains. At the moment I feel like going all the way and develop the domain model all in non English if needed.
On top of that I want to try out using letters like æøå in the domain model. The problem with this is that although the programming language supports it I can't count on all systems supporting it:(

Planing the next year

I have recently taken the MCPD in windows development, and now I have the time to think about what I want to take on next. I have a whole list of things I want to accomplish during the next year or so. Chances are that I will do something completely different. :)

• Take at least one more MCP certification.
  
• Ruby on Rails. I have been briefly introduced to this.. I want to know more!!!
  
• JAOO.
  
• Workflow. This is a new way of thinking, programming across requests. It's programming closer to the domain model.
  
• Consolidate my design preferences in a framework or tool. I generally go for the big picture and I don't want to be too constrained by a given technology on a project. However I think I need to settle a bit (just a little :))
  
• Take a class in enterprise architecture. Why not just read books and blogs and figure it out myself? The advantage of taking classes is that I use dedicated time on it a and I will hopefully be in a study group that will force a bit of commitment from me.
  
• Make a small program, package it as a Debian package and deploy it to my own repository. This is just something I need to do because I think it is cool. :)

The C5 Generic Collection Framework

I have recently come across the C5 Generic Collection Library. This is something worth investigating. The .Net Framework collection namespace is a bit limited, and to me not abstract enough. The C5 enables you to

code to an interface, not an implementation

which is is what I have always wanted.

Caracteristicts of enums

Some time ago I had to map some enums to and from a database. The database would store the integer value and I would cast the enum to and from the database. Suddenly I got unsuspected results even though I had unit testet the functionality with all valid values of the enum. I realized the enum contained an integer value not maped in the enum. No runtime exception was thrown.

I was a bit puzzled by this and I more or less considered this to be some sort of bug in the .Net framework
This is not a bug, and although I sometimes would like it to behave differently, it does give enums a new use.

Consider the following:

Accesories{
  SpareTire = 1,
  ElectricWindows=2,
  Heater=4,
  AirCon=8,

  Standard= SpareTire,
  Family = Standard | ElectricWindows | Heater,
  Luxury = Family | AirCon
}

As shown above it is posible to define your vehicle just by adding the single components. I think MS calls it flags, and the keys issue is that your primitive enum values must map to different bits.

(var & Accesories.Family) == Accesories.Family

will determine whether the level is at least Family. You can use other binary operators to anlyse the value of your enums.

I have succesfully collected data by just adding the simple values together and in the end just validated that it was actually a valid enum value. the validation and decission of the application is build into the structure of the enum instead of written in code.

In the example it is possible to add all primitive values together, but it is also very usefull when you have to select one or the other. Male or female for instance.

I'm looking very much forward to using kanaugh maps together with my enums :D

The Inter - face

Interfaces in object oriented programming have been around for a few years now. I still run into people who do not use interfaces while programming.
For .net developers this might be because VS.NET does not have a menu for adding interfaces, and VS.Net allows you to be more or less ignorant towards the structure of the program you are making (Drag'n'Drop coding I think I would call it :)).

To me structure is the most important thing in software development. Interfaces is a cornerstone in building this structure.

Interfaces are great when you need to consume objects, and you are more conserned with its use than what it is.
Interfaces come into play when you want to create reusable code. Directly copying source code is not a good solution and I prefer structuring my way out of it. Making a component or a framework if you like.
If you can avoid it keep your reusable components working without the user having to extend a series of classes of yours. The user might have reasons not to extend your classes, such as the need to extend other classes. Maybe the objects need to be serialized in between calls or some thing else. If you force the user to extend your classes, you must be sure the user can do anything to it in another context.

There is of course nothing wrong with providing a default implementation for your interfaces. Please don't give these default implementation the name that fits the use of the interface. IList and List is a bad example of naming a default implementation, or maybe it's more that IList should not have a default implementation. Because of these bad names, I dislike prefixing interfaces with I. The interface is the main thing and should be given the real name. Normally there is no need for a default implementation, but if needed I like giving the default implementation a Impl postfix far better.

When you design your system, you must think interfaces to begin with. There is little benefit from designing a system using classes, adding interfaces to all classes afterwards. Interfaces are only relevant if they actually respresent some decoupling in your system.

As a class can implement as many interfaces as you like, interfaces can be very small. This means that by using interfaces you code will only require the functionality it actually uses.. and the people using your product will only have to implement what is needed. They do not have to extend an existing class and thereby enherit a lot of useless functionality.

Less is more!
Interface > Class

Unit test addicted

I have become addicted to unit testing. So far I haven't noticed any side effects :)

Enough small talk... This is why I like unit testing so much:

• It forces me to initially focus on functionality.
• It lets me refactor central code bits and see if any dependant projects break because of it.
  I have worked on projects where nobody wanted to change stored procedures on the database. Instead new stored procedures were created. Thereby not breaking existing code.
• It lets me open up old projects that i don't remember anything about and experiment when fixing an error. It more or less functions as a description and validation of what the application does.
• It feels good when delivering a product knowing that it actually does what you expect of it.

A use for operator overloading.

Generally I think the main purpose of operator overloading is to conceal what your program does (unless dealing with types similar to primitive types), and this is the first time I have really found it very useful. My adwise is therefore: Don't try this at home, kids ! :)

For the last year I have been working on and off on a framework that should interface an existing product. The interface should be abstract so that it was possible to change the product without the interface of the framework changing. It should of course also be very easy to use.

One of the things I did to make this happen was to make a class structure so that criterias for searching data could be nested (composite pattern) in a tree structure. In this way users can make complex searches and easily combine them into many levels in the tree.



Consider the following example:

FirstName = "Rune" and (LastName != "Petersen" or LastName != "Knudsen") and Age < 32

I want someone called Rune, but not Petersen or Knudsen. The person should be below 32.


This shows the object structure you need to create to be able to perform the search. Although everything is nicely separated from the actual implementation the drawback of this structure is that it takes many lines of code to construct the criteria, and it being multiple levels of objects makes it hard to instantly comprehend when you look at it.

Another not so appealing thing is that small logical changes might course the structure to be very different. For instance if you don't want to and the Age criteria, but or it. Now suddenly there must be 3 levels in the object structure.

FirstName = "Rune" and (LastName != "Petersen" or LastName != "Knudsen") or Age < 32

Results in the following object structure.

This has troubled me, since I generally like the object structure for its extendibility. But then I rediscovered operator overloading.

First I changed the criteria interface to be an abstract class. Although operator overload are static, and explicitly define what classes they act on, in C# they have to be implemented as part of the most general type used. In this case criteria. So therefore no more interface.

I implemented the & and | operator on criteria. This made wonders to usability. When I have defined my simple criterias, I can now define my whole object structure on one single line.

FirstNameCriteria & (LastNameCriteria1 | LastNameCriteria2) & AgeCriteria

Not only is it easier to overlook the whole structure, it is also much easier to change it. All it takes to generate the second structure is changing a character.

FirstNameCriteria & (LastNameCriteria1 | LastNameCriteria2) | AgeCriteria

To make it even easier to read I also overloaded the compare operators on the Fields. This only deals with the simple criterias, but the rest will have to be dealt with later. having overloaded operators on the Field, the criterias can be created like this:

FirstName == "Rune" & ( LastName != "Petersen" | LastName != "Knudsen" ) & Age < 32

What remains for me is to find a way to document this functionality. As intellisense and documentation written for each overload doesn't show, my concern is that nobody will ever use this (and thereby not save a lot of time).

Success is relative.

I have found out that the success of a project is relative to expectations. Some might say that success can be measured in money. This is also true for long term measurements... For short term money is a bad unit for measuring success. Some sales people think that money is the way to create success, which leads to over selling instead of thinking long term success.

I have always thought that sales is the tool, not the goal.. The goal is to deliver something our customers like and would like to have more of. Or put in another way: deliver what the customer expects. The only way to be able to do this is by knowing the customers expectation, and at an early stage adjust them if we can't deliver what they expect.

VS.Net is for Mort

I have read the blog of Scott Bellware about the issue of MS targeting development applications towards the Mort personallity of their user stereotype. (Mort is the: don't think, just implement type). I came up with some thoughts.

It doesn't come as a surprise to me that this is what they are doing with their development tools. To me dotnet has always been the point and shoot version of Java. They have added some syntaxes that don't add any functionality, and they have removed some so that the developer is not bothered by the compiler when using exceptions (for me personally I would rather have exceptions syntax errors caught compile time than runtime).

VS.Net is not a bad tool, but it is not directed towards my needs. I like to focus on structure and maintainability. I like to be in control because thats the only way I can be creative.

VS.Net is like a DSL for programmers that are not too sure of them selfes. In 10 minuttes you can create a brand new application using technologies you never heard of before. You probably won't know what is going on in the program, and you will have a hard time maintaining it. Perfect for the Mort type :)

I have been concerned with making a standard product extendable, and to this VS.Net could be great. I though of creating a DSL so that the programmer doesn't actually have to focus on what is happening, but just drag a few boxes together and thereby extending the product. But if functionality is served like this, is there any need for a developer? Wouldn't a Mort like sales person be sufficient?

For me there is no real alternatives for programming .Net. I have only tried CSharpdeveloper which seems great. But it doesn't support ASP.Net :( Until ASP.Net and Windows.Forms is opened up like the CLR and C#, the open source community will have a hard time keeping up with MS changes in technologies (I still haven't found any technical reason to why they changed asp.net compilation completely in asp.net 2.0).

What I like about Eclipse is that it helps me do what I need. Refactoring is a essensial part of working in eclipse. I'm never suprised while working in eclipse... It doesn't copy things around. I'm always aware of what classes I'm using.

Using tools that are too complex

For the last couple of days I have become very frustrated by using VS.Net on a project. Because of this I have developed a new strategy for what tools I use. If the tool I'm using does stuff I don't understand or control I need a simpler system to fall back on.

My problem was related to using some com components. Everything worked fine until I published the project. Then some of my dll's were exchanged with other versions that did not work. I hadn't tried MSBuild yet and NAnt didn't support .Net 2.0 (well, without getting a nightly build). I was stuck with VS.Net :( I finally got it working, but without understanding why...

I will have to try and see if Sharpdevelop is anything worth for.Net 2.0 and I will have to update my version of NAnt.

If a program does "magic" stuff, it's to complex and will probably do stuff you don't want from time to time.

The kind of software I would like to develop.

Some time ago I visited my brother in law. He had just started playing a game on the internet, and in fact he wanted to play this game every day and every night.

When I decided that I wanted to develop software for a living, it was because I realized that only my imagination would limit my creativity. I have realized that customers also limit my creativity.
It seems that the number one feature of a computer game is that it has to bee cool, which means anything goes as long as its cool(and doesn't cost money). This is less contraining limitation than I'm used to by the business rules that normally define the boundaries of my work.
The computer game has another great feature. The users are only entertained and some use most of their spare time playing the game. Life is short, and to have people waste their spare time on a program I'm part of, is to me the greatest acknowledgement.

Actually... Mostly I was just inspired by the gratitude of the users of games. Enterprise application development is not bad either :)