Labour is not just labour

I am doing some consulting for an international company. Seeing how departments in different countries of the company tries to solve the same problem has been a great experience.

I work and live in Denmark, and with high salaries you would think that here it would be very popular to outsource IT tasks to low budget countries. Well it isn't. It's not that companies haven't realized that labour is cheaper elsewhere, it just doesn't fit the way we work.

For one thing there is the language barrier. Although most people in Denmark speak english, this is not the language of choice for defining business rules. If business rules were to be implemented in another country all the business rules would have to be translated, loosing a few in the process. Thats quite an overhead to manage.

Another thing is that we are used to having people as the most expensive resource in anything we do. This means that we are used to working smart. Saving time is one of the most valuable features of your work. We are used to having very flat organisation structures with 'Agile' processes and rapid feedback. Offshoring just doesn't fit into this way of working. It would require much more strict project organisations.

The kind of work we could outsource would be the repetitive work but I think we are used to ulitize the computer for repetitive work which is what it is good at.

Some places converting data would be a manual task, but that is not common in Denmark. As labour is expensive, it's much cheaper to let a computer do the conversion.

Although I see the potential of offshoring IT development for the right assigments, I'm not seeing it being much of a success anytime soon in Denmark.

Going to Jaoo

I'm going to the jaoo conference this year http://jaoo.dk/aarhus-2009/

If its going to be anything like the last two times I've been there my head will be exploding with new ideas when I get back.

Defining knowledge

Years ago I had a discussion with some coworkers about how the company we were working in could improve it's technical capacity. This discussion made me aware of how differently people look at this. Most of all it is the difference in what people think is important, beeing a knowledge driven company. The sales people don't really care other than they want us to be able to deliver what our customers demand. They way they want us to evolve is in measurable terms that can directly be used in sales talks with our customers. This could be certifications of our employees, adopting new platforms etc.

I don't think knowledge is something you can measure as such. You can take a lot of courses but if you are not able to put it in context you cannot use it for much. To me knowledge comes from exact facts combined with experience. In our line of business we sell our creativity which is based on our knowledge... Measuring creativity is a bit hard.

Learning to read

My daugther is learning to read. At the moment she has learned all the letters and can slowly spell her way through easy word. If words wore just spelled the way they are pronounced she would be an excellent reader already.

These days there is a lot of difference between the written language and the spoken language of danish. This has to do with the fact that the written language was defined a long time ago and the spoken language has changed a lot since.

This is just too inefficient for me. There are more exceptions to the rules than cases that follow the rules. Is this was some business process I had to analyse I would recommend refactoring the whole thing. Today, writing danish is not as much about knowing the sounds of the letters as it is to remember the exact spelling of each word.

Norwegian is similar to danish but in Norway they have refactored the whole spelling thing.I don't have any exact figures but I guess a lot could be saved in education by making things a bit less complex.

Is EF an ORM

I just read the "vote of no confidence" agains the Entity Framework (EF).

I have previously discarded the framework for the fact that it didn't support POCO. They have tried to recover by implementing IPOCO but its a workaround that doesn't really fit the issue of not supporting POCO. Not supporting POCO means that Entity Framework introduces dependencies to your domain model of Entity Framework that are not necessary and forces you to use your domain model in a certain way.

So why is this bad? A few extra lines of code in an entire application isn't too bad. It really isn't, but the purpose of the ORM is to create a persistent ignorant model. If we take plain as an example plain would have to be changed to support EF. Suddenly the nice layering would be broken because persistance logic would have to be applied directly in the domain logic or the UI layer.

As far as I understand version 4.0 of Entity Framework supports persistent ignorance better.

Software Factories are Evil

I started this post a loooong time ago.

A resent pod cast on .net Rocks and an article in version2.dk reminded me of what I wanted to write.

I think code generation is a sign of bad design. Code generation is a sign of a need for repetitive code. Repeating code is the certain path to errors.

The worst kind is the one where you are supposed to edit some of the resulting code. The purpose of the process is to let you specify something in an abstract manner and have the details of the system taken care of by the generator. Once you edit the code you brake the abstraction and you will no longer be able to make changes to your application using the high abstraction. Examples of this could be the Windows Forms editor in visual studio. When you drag components on to your form, a lot of code is generated behind the scene. If you have to change anything in the generated code you might loose it later if some components are moved around on the design surface.

Another way of generating code is to generate static code that doesn't need to be changed by the user. This can be done to create a structure that the user can utilize in his/her program. I'm suggesting that you avoid this as well if possible. The bad impact on your program is not as big as on the previous method though. The reason for applying this could be to work as a shortcut to make something compile together.
An example of this could be the designer file for aspx files in visual studio. When visual studio parses an aspx file an C# file is created so it can be compiled as part of a C# project. The problem with this file is that it adds no new information to the project, but adds complexity in terms of extra files. Once in a while this file will be out of sync and you have to restart visual studio.

Initializing an object migth be so compex that you need a sniplet to assist you every time. If this is the case you should create a simpler way to initialize your object rather than create a sniplet for it.

My recomendation is therefore that if you are in need of code generation in your project you should reconsider your application design.

World domination: Google vs. Microsoft

Both Microsoft and Google are large wordwide companies. I'm very dependant on both companies everyday.

The two companies have different market strategies. As for google product I use them because they are cheap and good. With MS its much more that there are no alternatives. This makes me reluctant every time I get a new product to use by MS. Its not that the products are not great. Its the question of what other products I will be forced to use. I think that if MS products were not so sticky and so dependant on other MS products I would probably still be using them because some of them are quite good. I would do so even more happily than today. I would be able to use other vendors for just those part where MS products didn't fit.

Documents versus contextual information

Well.. Let me start by asking for your needs. If you say that its for legal purposes and is to be used for documentation together with a digital signature or strictly for printing I would tend to suggest the document approach. I any other case I would recommend storing you information in a contextual manner.

A document is basically a black box where you can dump your data. You can find your data by a folderpath and a filename. Thats basically what metadata you get for your document. For me I might as well put the document straight in the trashcan because I know I won't be able to find the document when I need it in a month when there are several versions of the document and a lot of documents have been written since.

The contextual information is different. I'm in particullar thinking of wikis. Here information is normalised to its 3rd degree, not being repeated. When you need the information somewhere you just make a reference to it.

It's an uneven match. Is your information to be used or are they just to be archived.

DataSource, To bind it all.

A small step for mankind, but a giant leap Plain.

We have found a way to bind a lot of the stuff contained in Plain together in an easy manner. When designing Plain we focused on few dependencies, high extendability, flexibility and ease of use. The ease of use is the one that can be hard to align with the other.

Plain is quite easy to use but very flexible. Code was however still needed to hook things together. Its no longer so. By using a Plain DataSource for ASP.Net, you are no longer needed to write any code to hook things together. Just place a DataSource on your page and define what domain class it should operate on and point it to the query ( defined in your business layer). The beauty of using a datasource is that a lot of standard .net usercontrols know how to use it to retreive and send data. DataSource objects also contain information about paging and sorting, and your UserControls will be able to take advantage of that just by enabling them to do so.