Flank your problems

The other day I took my youngest daughter to football practice. She is 5 years old and has a lot of energy to spare. Its great fun to watch these small kids play around on the field.

When I saw them playing I noticed a pattern I have seen in software development. All the kids were chasing the ball at once. This made it a somewhat confusing match to watch. The problem was not that the girls lacked the technical skills to play football or that they didn't understand what the goal of the game was. The problem was that they were so entutiastic about getting the ball to the other end of the field that they all rushed to the ball to help the team get the ball to the other end.

I think this anti pattern should be called something like "Beeing too specialized" or "Follow the leader". The pattern to overcome this would be the "Think before you act" or "Flank your problems".

My point is that you shouldn't rush for a quick solution as there might be a better and faster solution if you're open minded.

One liners in .Net

Just wanted to show a few one liners from a project I'm working on. I get a lot of data from a third party as XML. In my business logic I want to work with objects so I have made a class that wraps on entity in the XML.

var orgs = doc.SelectNodes("//Organisation").Cast<xmlnode>().Do<xmlnode,wrappedorganisation>(x => new WrappedOrganisation(x));

So in this line all the organisations in the xml are located and a list of WrappedOrganisation is created from it. With the next one we had to hide a lot of textboxes on a page if a related hidden field had the value "0".

Page.findControl<placeholder>().Do(x => x.Visible = x.findControl<hiddenfield>().Count(h => h.Value != "0") != 0);

The next one retrieves a list of custom objects from some textboxes on a UI.

IList<customvalues> list = UserControl.findControl<textbox>().Do(x => timeSpecs.Add(new CustomValues() { Amount = int.Parse(x.Text), Month = StartDate.Value.AddMonths(i++) }));

Finally a line that identifies TextBoxes on a UI with a value that is not an integer and marking them.

UserControl.findControl<textbox>().Where(x => !int.TryParse(x.Text, out i)).Do(x => x.CssClass = "borderRed").Do(x => messages.Add("Not a valid amount"));

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.

The good and bad of recent .Net

The Good:

• Extension methods
  I must admit that I can't get enough of extension methods. They make it much easier to create powerfull structures that are very easy to use, without compromising your good architecture.
• Lambda expressions
  These are not much of a revolution, but I like having a more compact way of writing code.
• WCF
  WCF scores high on the simplicity and extendability. I'm not sure I would have designed it the same way, but it does the job. It's coolest feature is that you can start out simple and add complexity a long the way.
  
• F#
  F# brings functional programming to .net. The functional paragime brought to .net is very exciting and it will hopefully inspire a lot of people out there.
  

The Bad:

• Silverlight
  This framework has been hyped a lot. Although it has a lot of cool features, its lacking the most important one: Interoperability. If I choose silverlight I'm still forcing all my user to windows.
  
• WorkFlow Foundation
  I had high hopes for this framework. I have previously worked on workflow systems and was looking forward to having a framework that would ease the creation of workflow systems. I think the problem is that workflow foundation wants to do too much. Anything is possible and that makes it closer to a generic than to a dsl for workflows. I would have preferred a more specialized framework.
  
• Entity Framework
  The good thing is that more .net developers have now heard of ORM. The bad thing is that the ideas with EF are quite bad and I would choose another ORM anyday. Too bad this means that more and more will use EF and at some point we are probably all going to be forced into using it.
  
• MSTest
  This product doesn't really make a difference. It doesn't provide anything that was not out there already. My preference is still NUnit.
• TFS
  If you haven't tried this, then don't mind. It is way too ambitious and too complex to use.
• Monodevelop
  Mono has come a long way. The big problem is and will always be that Mono will always be behind ms .net. Mono has serious problems in being compliant with .net because .net is so closed.
  

Sales people explained

It has always been hard for me to communicate with sales people. I think this is a problem most technical people experience. It doesn't matter whether they are selling me things, or selling my work. They just live in another absurd and parallel universe.

It is common knowledge that communicating across continents can be a challenge because of cultural differences. It's the same when communicating with sales people. These are the main differences to "normal" people as I see it.

• A more liberal approach to the truth or maybe just a more ignorant attitude towards facts. They are often only interested in the good story. I you want to hear about the perfect world or solution, do contact a sales person.
  
• A low signal to noise ratio.
  The goal for communication for a sales person is the communication itself. Whether any useful information is communicated is often not important. The entropy of a conversation can therefore be very low. Often it's just not worth the communication.
  
• Have no interest in, and no knowledge of what they speak of. The best feature of a sales person is his ability to small talk. Most of the time he won't have the slightest idea about what he is selling.
  

Don't get me wrong. I generally don't think salespeople are liars or bad people. I just don't think they always comprehend the stuff they are working with. Therefore it is harder for them to separate right from wrong. Therefore they are hard (or impossible) to communicate with.

Bulk calling of methods

You have your domain model defined in a class called DomainModel. You have a lot of usercontrols that handle seperate parts of the domain model. All the user controls implement the following interface:

You want to call the PopulateControl method on all your usercontrols to get data mapped to the UI. This is how you would do with plain.

When did things stop being natural

I might be a bit off on this post.

I'm just a bit confused with a word. To begin with everything was natural. When you apply a natural process to a natural substance, it will remain natural. So when and how did some things become unnatural?

Creating a bug report

I have seen some bad bug reports. This is my little guide how to write a useful bug report.

• Get to the point. It’s about a bug, and that’s what you should be writing about. It is of no in-terest why this bug is so important to you.
• Explain the context. Al though you might think the context is obvious, explain it anyway. Explain how you can reproduce it.
• Be polite. The people that are to fix the bug are probably very enthusiastic about fixing your problem. By calling them names they will be less so. They don't necessarily have anything to do with the bug in the first place.
• Give it a priority.

Validations in Plain

We thought we were very original when we thought of the validations for plain. It turns out that there is a NHibernate Validation project that uses the same idea.

Although we were not aware of the NHIbernate Validation (and I guess the other way around) the way the validations are defined are very similar. The biggest difference is that Plain validation is focused on the domain model and the UI. NHibernate is focused on the domain model and the data layer. Plain Validation has (or it is supposed to have) translations for displaying validation errors directly in the UI.

As the two validation frameworks have very similar capabilities, we might make a mapping for you.

Programs I'll lay out for a fresh install

I've seen a few bloggers listing the programs they want on their machines.

I have thought of this as well, and the conclusion is that the only program I need to be bothered installing is apt-get. When I have apt-get installed and it is pointed to the repositories I want, any other program is an ease to install and won't take long. I can wait untill I need that program to install it.

This of course only goes when I'm on Linux. There is no apt-get on Windows, and installing a fresh machine will take a looong time. Keeping track of licenses makes the process even longer. I won't go into that. :)

Being pragmatic

Being pragmatic means that you consider what works over what is correct or pretty.

I'm a big fan of being pragmatic. A big mistake I see is that people think that if you are pragmatic you should not be concerned with doing things smart. This is wrong. I believe pragmatic is about spending the least amount of time creating a thing that fulfills a need.
If the need is to be able to maintain it, the pragmatic solution won't be to hardcode everything.

The pragmativc solution is not:

• Ignore common sense
• Start coding before you think
• Avoid design

The pragmatic solution for me is almost always to stop and think about what makes sense. This is the way I solve my problems in the most optimized way. I hope you will too!

Configuring Sharpdevelop for web projects

I want a small .net IDE installation that is fast. I have for a long time been happy with Sharpdevelop but one big issue is that there is no default webserver provided that you can use to develop web apps on.

Luckily my good friend Kristian Gundry has fixed this for me.


By providing the right parameters you can start a webserver. Either you can start the mono xsp2 webserver or you can use the one that comes with Visual Studio Express.

Happy happy joy joy! :)

Puzzle

Consider the following:
I provide you with a .net 3.5 dll that implements the class SomeClass plus some operations that operate on this class. The Isvalid method has no side effects, will throw no exception and always return true.

You run the following code:

What is output to the screen?

1. "o is valid"
2. "o is not valid"
3. "Exception has been thrown"
4. impossible to predict

Place your bets please

Note to self

When building an lightspeed vesel don't make the brake a button on the dash board. At light speed you will only be able to move backwards in the vesel and you will never reach a button in front of you.

Link to the plain project

http://code.google.com/p/plain

Misunderstanding: The path to new ideas

Isn't it frustrating that people misunderstand each other all the time?

At one point I though that all the problems people have communicating were holding us back. Even though a person has a brilliant idea, he might be the only one who truly understands it. A lot is lost in translation. Wouldn't the world just be magnificent if you just had to tell people things once and they would understand. There is just one little problem with this illusion. If we all just understood each other there would be little reason to interpret what you hear and come up with new ideas. Perception has a big role here.

So, the next time you are annoyed with somebody because they just don't get what you are saying to them or by people that can't explain anything in an easy manner, remember it is for a better cause. EVOLUTION! Even the simplest things can be misunderstood and will likely be. It is the reason we have come so far.

I have many times wished that I instantly could grasp the ideas of some of the great thinkers. Instead I have to read a lot of books and spend a lot of time interpreting what is written. My main source of inspiration comes from information that I don't understand.
My theory is that most ideas spring from existing ones that were misunderstood.

Alt.Net FTW!

I attended an alt.net usergroup the other day. There was a lot of dialog of what alt.net is and if the alt.net movement has already started dying.

It doesn't really matter if there is a movement. Alt.net is more about concept and a way of thinking than it is about a bunch of people. As long as people develop tools and components to use with .net and don't just wait for the next release from Microsoft, the spirit of alt.net will live.

So if you are a .net developer and your primary source of ideas comes from Microsoft then you don't have to care about what alt.net is. If you on the other hand keep looking out for better ways to do stuff, an alt.net meeting might be for you.

Working on collections and searching for objects

I am reading a book about F# which is a functional language for .net. At the same time I have been introduced to JQuery which is a javascript framework for querying and manipulating objects on a html page. It has sprung some ideas for the plain framework.

What I'm striving for is the possibility to query an object structure for objects. When the objects are returned, it should be possible to perform actions on all these objects in one statement. LINQ might be usefull for querying but at the moment I'm guessing that it won't fulfill my needs.

Lets me give an example of what is currently in progress. This will find all TextBox objects that contain the value '0' and set the background colour on it:

form.find<textbox>("[.Text='0']").Do(t=>t.BackColor= Color.Azure);

The .find method is an extension method on object, which means you can use it for any object. The .Do method is an extension method to all IEnumerable<> that lets you perform the lambda function on all instances contained in the list.

Another example is by using the Map method.

IList<string> textboxValues = form.find<textbox>().Map<string>(t=>x.Name +": " + x.Text);

This will produce a list of strings with that name and value of all textboxes somewhere on the form. The Map method is currently not an extension method as I haven't figured out how to implement the syntax of just just providing one generic parameter to an extension method working on a generic type :(
Actually there is a Map extension method, but it requires you to provide the generic type of the collection as well. In this case it would be .Map<textbox,string>(...)

The one thing that is missing is the syntax to search for objects. Will it be LINQ or will it be a homegrown dsl?

If you want to use the .Do method here it is:


public delegate void OneParemeterNoReturn(T x);
public static void Do<t>(this IEnumerable<t> o,OneParemeterNoReturn<t> func){
foreach(T t in o){
func.Invoke(t);
}
}


otherwise you can wait for it to apear in the plain framework :)

Creating overloaded methods with extension methods

I have an interface in an application.

I want the interface to be simple to implement so it basically contains one method that has a number of parameters.

I want the interface to be simple to use, so I have implemented a number of extension methods that will work as overloads for the method specified in the interface.

So far so good. My next wish is to make the interface generic. This is where the everything falls apart. Apparently you are not able to make extension methods on a generic type. Every time i come across such mismatch between part of the .Net framework I am very sad. I wish the next version could just be a little coherent. :(

Statefull SOA

I am attending a course on WCF (Windows Communication Foundation).

State full services are sometimes not considered 'right' when speaking of Service Oriented Architecture (SOA).

My claim is that state has nothing to do with whether a service can be a good entity in a SOA architecture. You might have a strategy that your services should bee RESTfull, but that has nothing to do with whether your architecture is service oriented or not. REST gives you some other properties (quite useful I might add), but doesn’t influence the architecture towards SOA.

The same goes for callbacks. Even though my telephone company allows people to call me on my phone, I still consider my phone connection to be a service provided to me by my phone company.

Plain Validations

For field validations we wanted to avoid the implementation of validation duplicated and spread out over several layers of code.

The right place for validation code would be in the business layer. Actually with plain its more of markup than actual code. What we did was to make an interface for validation attributes to implement. When you need to know if your object is in a valid state, you can ask plain and it will pick up your validation attributes and validate your object. This can be done from your user interface layer or anywhere else you might need it.

As plain just needs you to implement an interface there is no limitation to what kind of validations you can create and have plain use to validate your objects.

We are currently working on a way to define validation messages for each validation and a way to have UI use the validations directly on input fields.

Mapping the domain to the web UI

With Plain we wanted some way simple to get data from the domain model to the UI and back.

We already had a mapping implemented from a previous project that could map properties to fields in the UI. What we wanted to change was the dependencies and flexibility of the mapping. Currently all we have to do is name the fields on the form and tell the system what object type to work on to provide CRUD out of the box with plain.

We have one thing left to do on the mapping part. We want lists of values to be filled out automatically. Our Validation component might be what we need to use to be able to do that. More on the Validation component in another post.

Just Plain

I've been working on a small application framework together with a friend. The framework is for developing business applications. I will probably post some stuff about this in the near future. We made it with the following requirements.

• Simple - This is the main purpose of making a framework anyway
• Transparent - We want you, the user of the framework to be in charge and control of what is going on.
• Reduce redundancy - We are strong believers of DRY (Don't repeat yourself)
• Introduce as few dependencies as possible - use what you like, ignore the rest.

The reason for wanting these properties in our framework is as follows. The simple part is easy. We want the interface to be intuitive to use. To accomplish this we choose the simple path over the complex. If something is complex, why not make it without the frameowrk.

In order for you to control what is going on we want to make the framework as transparent as possible. We want the users to be able to do all the same things without the framework, but provide a shortcut by offering a default architecture.

Reduce redundancy means that we want to provide the users of a way to write their code once. As an example this means moving definition of queries from the data layer to the business layer. This way there is one place to make changes, and you don't have to reflect your changes through several layers of code. The data layer is all of a sudden less important, and so is the UI layer. This means that we can supply you with a generic data layer or a ui layer (no layout), and all you have to focus on is your business layer.

By having very few dependencies we remove the reason not to use parts of the framework. Even if you are using large API’s with very strong dependencies and requirements, you can easily use parts of the framework where ever it makes sense and your other dependencies allow it.

The Framework is of course just named Plain

Real Life Dependency Injection

When making a framework you come across the question of how to instantiate your objects, and how the users of your framework can inject object in the framework. Often you want it to be flexible enough for it to be easy to inject object into, but fluent enough for the programmers not to notice the low dependency barrier.

What we did was to make a static application class with a reference to a configuration object which is only loaded once at application start. The application class initiates the configuration object by running a xaml file through the xaml parser. This is a very pragmatic solution that can be used for initialization of static objects in the application. Everything is hooked together with very little code and it can easily be extended to support more objects etc. in applications using the framework.

When the user needs access to any of the injected object he can do like this:

Application.Config.DaoFactory

Although this only supports "singleton" objects it gives me the flexibility I was looking for.

class recommended over interface

I just pulled the Framework Design Guidelines down from the bookshelf to look at it again. I briefly browsed through it and I must say that disagree with it all the same places as last time I read it. At one point they recommend the use of abstract classes over use of interfaces when making a framework. The reason would be that it's easier to add new methods to the framework later without breaking code build on the framework.

I recommend interfaces over classes when designing a framework. Interfaces give fewer dependencies if you have the choice. Like everything else its dependent on the situation what to do.

The book states what you should do and what you should not. Framework design to me is not so black and white. The book is probably more a description of what practices the .net team followed while designing the .net framework. The book is good for developers with little experience, but it seems a little trivial for experienced developers.

Extensions methods... Still missing some features

I like extension methods in dotNet. Extension methods give you easier access to your helper and util classes with static methods that operate on your object. It's not that extension methods give you any new features, they just give a little different syntax that might be a little more natural. It gives the programmer a way to use methods across your project without learning the syntax of your helper classes.

I like extension methods because they give me a way of separating my code where I find it fit, and still give the user a feal of coherence. Extension methods do not affect the architecture of your application as it doesn't change where code is, just the syntax of accessing it.

So far I have found 3 areas where extension methods fall short.

1. :Extension methods can be made work like instance methods. Extension method cannot be used as static methods. In a static context they could have been great for factory methods and such for your classes and interfaces.

IDomainObject o = IDomainObject.Load(1); //Working on the type. Can't be implemented as an Extension method
o.Save(); //working on an instance. This is ok

Wouldn't static extension methods be cool? :)

2.: Extension methods can't overload operators. As I generally dislike operator overlodings, this is not a big problem for me. I do however have one place in mind where I could use this.

3.: Visual studio does not recognice Extension methods if your code is in the class that is extended.

public class Test{
public void doStuff(){
HandleMe(); //Can't be implemented through extension methods
this.HandleMe2(); //This can be an extension method.
}
}

I don't really see why this is not implemented. Maybe it will come in a future release.

Extension methods are GREAT!

Creating a test/development enviroment

On most projects I've been on, defining the infrastructure has started by looking at the customers current infrastructure and then trying to create an environment that resembles that for testing and for development. I have never seen a test environment that looks like the production one. I have never moved an application from test to production without some unknown settings on the production environment.

My suggestion is this: We should stop using the production environment as the reference of our development. Instead we should specify the environment in as simple terms as possible. this specification should of course be validated by infrastructure guys (or girls). This way the application developer can focus on what is his does best which is the functionality of the application and not hardware and network setup.

This approach should result in better applications because it lets the infrastructure support the application and not the other way around.

Edit: I had a comment on this post. What I mean is that I want the reference infrastructure to be something that can be realised in a test and development environment. I don't want the production environment to be the reference. The reference infrastructure should of course be evaluated by someone who knows the production environment. Getting the application from the reference installation to the production environment should not be a task for a developer.

Databinding in WPF

Data binding in .Net has previouslybeen done by providing a data source and calling DataBind(). It has been a one way data flow initialized directly by user code. In WPF they have changed it a bit. To enable automatic synchronization they have basically implemented the Observer pattern. To make this happen they have implemented the properties in the UI component as DependencyProperties. A DependencyProperty is a static object on the class containing the property. The ordinary properties on the class are wrappers setting the value on the DependencyProperty. In this way you can subscribe to changes on the property through the DependencyProperty.



In the illustration I'm trying to show two connected textboxes. When typing the name of a font in the first TextBox, the font of the second should change accordingly.

This event driven synchronization is dependent on the fact that your object inherits DependencyObject and that your properties use DependencyProperties. If you want your UI to be data bound to something that is not a UI component, you can implement the INotifyPropertyChanged interface and fire the PropertyChanged event when your object changes.

The way to publish data to the UI could be to bind all the fields in the UI in relation to a parent container (the windows or something) and then set DataContext to the data object. This way your UI is filled with data very smoothly.

Xaml, the ultra lightweight IOC container

I've been testing xaml for defining what object to create at runtime. Although xaml is often linked to windows workflow foundation or windows presentation foundation, it can easily be applied to your own domain.

Xaml is a xml language where you can define how a .net object structure is to be initialized. It has many similarities to springframework.net, lightweight IOC.

The greatest thing about Xaml is it's very easy syntax. Every node in your xml is giveng the name of the class to instantiate. By givin the root node a namespace, your VS.Net provides full intellisense to what properties are on what classes and what type they are. By making typeconverters for your classes you are able to provide a simple way of creating your simple classes.

Missing?
What is missing then? Well... Xaml is just a language that enables you to create objects. Because of this it doesn't give you the means of controlling the lifespan of your objects. You can't state that an object should be a singleton for the application etc. If you want that you have to code it yourselfes.

Xaml supports property injection but not constructor injection which means all properties needs a public setter for it to be set by Xaml. Most of my properties already have public setters, but I have to alter a few for them to be xaml enabled.

Another thing I'm missing is the support for generic types. In xaml you cannot instansiate List as an example. In stead you kan implement some xaml interfaces or you will have to make new classes that inherrit from the generic type you want.

Example

I have used my search criteria framework that I introduced in "A use for operator overloading" for testing the Xaml.



The above xaml creates the object structure ressembling the following query: Content = "teste feste" or Title = "teste feste" or (Content="test" and Title="test")

I would also have liked a possibility to cross reference objects (create it once and reuse it multiple places in my xaml), but overall xaml provides a very simple way of creating your object away from your code. Whereas spring.net has quite a heavy syntax xaml is very intuitive and will be comprehendable, even for people with no technical background.

Reflection on Lazy loading

No, I'm not going to reflect on lazy loading. :)

By lazy loading I mean having an object model without all of the objects being loaded (from database) at once. If I for instance have a User object with an Organisation, I don't necessarily want the Organisation object to be loaded when the User is loaded. Not loading everything at once speeds things up because you can control what is retrieved from the database and what is not. Anyway, enough about why lazy load. NHibernate implements lazy loading by creating a proxy class that inherits the class of the object. The moment you try to access your object, the object is retrieved from the database. The object you asked for has been loaded internally in the NHibernate object and it will be transparent to you because all your interaction with the object will be passed on to it

The object model you want

The problem starts when you start to use reflection on your objects. The Organisation object on the User is actually not a Organisation, but a subclass generated by NHibernate. If the object you are trying to access is an ExtendedOrganisation, you can't cast it to the type you want because its type is defined by the reference on your User object.


Because NHibernate caches its loaded object it can be hard to tell in advance whether an object will be a proxy or not. If you ask NHibernate to load a Organisation object, you will get a proxy class object if NHibernate has cached it as a lazy loaded object beforehand.

The objects NHibernate gives you

If you want reflection on your objects that may be lazy loaded, you can make generic method where you also have to give the type. When applying reflection you will have to use the generic type for your analysis. If you object has been loaded with a wrong type, you can make a property that returns the same instance. Because the NHibernate proxy contains a reference to the real object and passes all method calls etc. through you can make it work just by returning "this".

Some of the components in .Net that consume list of objects do this by reflecting on the first object in the list, using this type to handle all the objects in the list. You can overcome this by implementing a TypeDescriptionProvider and registering it like described by Ayende. The problem with this is that it will change the way your types are handled throughout your application. You would no longer be able to have a list of ExtendedOrganisations.
The much nicer approach would of course be to have type aware components through Generics.

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

The easiest operating system I have tried yet.

I tried to install Linux some years ago. I gave up using it as my primary operating system as I thought I had to use too much time setting it up.
Things have changed and Ubuntu is an example of an operating system that requires almost no setup. It installs with a collection of applications that will satisfy most desktop users.

For instance if you want to install mono on your system so that you can run .Net application you do the following.

sudo apt-get install mono

1. "sudo" changes the user to be the administrator.
2. "apt-get" is the package manager.
3. "install" is the action you want with the package.
4. "mono" is the name of the package.

Now all you have to do is follow the instructions on the screen. You will be prompted for the administrator password, and asked whether you want to install all the dependent packages. It doesn't get much easier than that.
Next I want a development environment :

sudo apt-get install monodevelop

Actually I could have started with this command. Monodevelop is dependent of mono, and it would have installed mono automatically.

Once a program is installed this way, you will be notified if the packages has new versions.

Avoid using the System.Collections namespace.

It is good practice to avoid the use of variables of type object*. By using object as a data type, you will not have compile time validation on your types, and you have to cast you objects every time you use them. Its the exact same situation when using the System.Collections namespace. Objects handled by System.Collections will only be validated to the object type at compile time. It compares to creating an object[] array to contain strings. You would never do that. You would create a string[] array.

The System.Collections namespace has served us well in the past, but now it is time to move on.
Use System.Collections.Generics instead!

*(sorry for the casing, but I think I have already written about my opinion about diverting the .Net languages so that the same classes are called different things in different languages)

Playing a bit around with the .Net 2.0 framework.

Generics in .Net works nicely. Its nice to see casting and custom validation can be removed from one's code.

I have written about my problem with the naming convention of interfaces in .Net and now I'm going to write a bit more about it. In the System.Collections.Generics namespace, they have renamed a class compared to the old Collections namespace.

The ArrayList is now... TADA! List ???

I'll give you an example of why I think this is a bad name.

IList list = new List();

You want a list. So you create a variable of the type IList. Now you want an instance. But List doesn't make sense as a class name. It doesn't tell the user anything about it's behavior. Does it work like a linked list, an arraylist or maybe an array? You can't tell by the name.

ICar car = new Car();

This example is thought up, but equally weird.
customer: Hello! I would like to buy an ICar.
dealer: and which type would you like?
customer: I would like the Car...

Car car = new Porche911(); makes more sense just like List list = new ArrayList();

To me this looks like a lack of understanding of interfaces. It however makes perfectly sense in the VB6 world where interfaces don't exist:

List list = new List();

At work we have decided to drop the use of I. :)

The smartest things are often the most obvious.

Behind the scene, my blog is flooding with posts in draft. I don't have time to publish the posts the way I want (without too many spelling mistakes etc.). The reason for this is that everywhere I look I see things to write about. I think the reason for this is that smart things are often obvious when you have been introduced to it. There is nothing like the "Ahh!" experience when someone explains something to you, you understand instantly. I think this goes for software as well as for everything else.

The wheel is one of the best inventions ever: it has a clear advantage, and everybody understands it as obvious. This is what I want! I want to design applications with the same characteristics as the wheel. Very useful, and comprehendible for everyone.

This leads to my problem with this blog. I could start writing about the wheel as one of the mayor components of modern life, but my guess is that all humans alive already know about the wheel. I'll instead focus on software development, but it is unavoidable to write about the obvious. The obvious is often the best... I'll try my best to make it interesting :)

Performance enhancement through simplicity

People have different views of how one should take performance measures while designing an application.

One approach is to think performance all the way. This means putting as much code in stored procedures as possible (most of what I do has a connection to a database), having denormalized data structures and generally focussing on the shortest execution path for everything. This approach makes sense because it directly confronts the problem.

It however has some problems which makes it suitable for only small projects. While being very simple with small applications the complexity grows a lot when the application grows a little. It has no focus on maintainability and can be a nightmare to fix later.

On the other side is the completely object oriented model. EJB is is an example of such an approach. In EJB (at least in the old version that I know) the programmer or designer lives in a happy cloud of ignorance towards performance. This is of course my interpretation of the framework. The fact is that the performance considerations in EJB lies in its scalability. All a matter of defining what performance is.

What I have concluded to my self is that performance is partly raw power, partly scalability but mostly simplicity by design.
By focussing on simplicity, it will be much easier to refactor those parts of your code that does not perform adequately. This is why I also consider OR mapping frameworks to be performance enhancing. They might not be directly performance enhancing, but they simplify the programs and make it possible to spend your time where it is more needed.

Close your eyes and imagine you followed the right path?

Most of software development is not about actually developing software. It's about choosing and following a path that leads to success. What path to follow may be influenced by a lot of 'external' factors. Such factors might come from the sales department.

Once a path has been selected, it is wise to follow it for some time. To follow a path will help your productivity, and give you a more detailed view of what you chose.

Once in a while you should reconsider you path. If you are following MS, you should see what tools the open source community has to offer, and you should let your self be inspired by the Java world... adopt those techniques that will improve your path. Just to sit back, relax and wait for the next release from your favourite vendor will not make you as aware of your development as otherwise. Don't be too pro anything just because it worked for you last year.