Categories
Development

Code reuse is a myth

Arash Barirani is pondering why domain models is so rarely reused. After all they did teach us in school that reuse is one of the big advantages of object orientation. Everyone could see that the Car and Tire objects the teacher used for illustration easily could be reused in another car and tire application.

He still seems to be having some faith in the concept though, and is still wondering how to achieve it. I on the other hand has lost all faith. Well, not all, but most of it. The problem is: Different customers has different views of their domain, even though they might be doing the same stuff.

Some domains like accounting could probably be used across companies. It is strictly defined, and there are common rules for how to account for everything that happens through a year. Other domains like running a big warehouse will not be the same unless both organizations believe in the exactly same way of running their business. Depending on processes and the people in it the domain can be completely different. There might be some similarities, but even the language might be different. And you sure as hell can’t march in there and tell them to change their language and processes just to fit to an existing model.

It depends on the people running it. As they change or leave, the company will need to change too. That’s when you need SOA… Of course not. But you will need a flexible well designed system that copes with change and is easy to maintain.

Categories
Development

Big screens

I want big screens. Martin says I should. 😉

Categories
Development

Malcolm Events

Rands writes about the little things you forget that will screw you over. I know exactly what he means, and it is hard to propagate ideas and decisions throughout the project and organization. I have no silver bullet, and being quite new to the business I find myself experimenting with what works well.

In my current project we have a couple of things in our toolbox, and they are working to a certain degree. We do a weekly time boxed gathering where we talk about issues and solutions, and we use a wiki for documentation. But these are both weakened when you are in a hurry. Because time is sparse, people do not take the time to read up on the wiki, and discussions in the common meeting is sometimes not very detailed.

This is one of the hard trade offs you need to do. If you want to avoid the Malcolm events you should propagate the ideas to the entire organization and listen to all the feedback. The problem is that everyone is going to have some opinion, and the discussions will continue for hours if not days. So when do you stop discussing and try to agree, and just get something done? But if someone disagrees, will the result come out right? Who was just silent and think they understood all aspects, and have misinterpreted just a little bit?

What’s your tricks to get rid of the Malcolm events and get everyone on board?