Mickaël’s Weblog

Jeremy D. Miller have written a post on Be not afraid of the Visitor, the big, bad Composite, or their little friend Double Dispatch. The “hot” debates/discussions around Design Pattern are still on the edge. I found very interesting and right his disclaimer on Design Pattern.  

Design Patterns are a very useful are of study for serious software designers.  Design Patterns are an important form of common language between developers and a way to catalogue and reuse design wisdom from the ancients.  Design Patterns can be a huge shortcut for designing applications or services.  Overusing Design Patterns is bad.  Using Design Patterns out of their proper context is usually bad.  Committing to a  Design Pattern too quickly can often be bad.  Using Design Patterns at the right times can reduce the amount of ugly, bugridden “if/then” logic in code and make the code easier to test, change, and read.  Don’t just memorize pattern names.  Climb up to the top of Bloom’s Taxonomy. 

I’ve seen too much time people trying to sort out a design pattern to a specific problematic before analysing it…and raise the hand saying “we should use this design pattern, that will solve the problem”. Using a Design Pattern does not ensure success of an implementation…especially if you choose the wrong one. The first thing is to figure out what are the requirement, then elaborate various 10000 feet options/solutions by abstracting your problematic, and then have in mind the potential design patterns that could help. Jeremy says “Using Design Patterns out of their proper context is usually bad”, I would rephrase this as “Using Design Patterns out of their proper context is always bad”.

To me design patterns, are first a way to transfer knowledge from the ancients that already faced to a lot of typical problematics, and second: to have a common language.

Design Patterns are at a higher level (or simply just different) than technology, but even if you face a well know problematic usually solved by a Design Pattern, you previous technology choices may simply prevent using it.

As usual: use your brain, if computer science was only to answer problematics with predefined solutions written in famous books..I should do another job
 

On this ARCast, Architect MVP Juval Löwy is talking about distributed transactions (ie.. WS-Transaction) as a violation of the “Autonomous” tenant of service orientation or not. I agree with Roger Sessions:

Atomic transactions require holding locks, and spanning transactions across services requires allowing a foreign, untrusted service to determine how long you will hold your very precious database locks. Bad idea.

Juval says it is not a violation of the “Autonomous” tenant of SO but the common sense tenant of not locking resource for external service for a long time.

Using atomic transaction help a lot for development, taking care of failure, rollback, locking in a transparent manner. If you can use them…do it! As soon as you interact with external services, add tolerance in your implementation. I think this is also true for every kind of development regarding external process, service or data input: add tolerance and flexiility, do not trust. If you build an application receving data input from a file, do absolutefly no assumption even on the format.

Robert Cooper talked about why he hates BPM products but love BPM: XML is not a programming language! I fully agree on this assertion and you can read about a post (in French) I’ve written on this.

This is true for BPM, but also for many enterprise software (see this post from Ayende about what is an enterprise software): they pretend/tend to be highly customizable to be able to match the enterprise processes without requiring high development skills…this usually true, but the drawback is the maintenance, upgrade and evolution capabilities which are usually also very poor.

I think Designer Oriented Architecture for non-techy (non-techy does not mean “no skill” at all…see later in this post) is not compatible with maintenance, upgrade and evolution capabilities. For the rest of this post and as I’m lasy, I will talk only about maintenance but you can replace by “maintenance, upgrade and evolution”. The incompatibility is simply due to the fact that a non-programmers have in fact development skills but are Morts (see Jemremy’s post which I totally agree on), meaning they have to build/customize applications to fulfil some requirements and they learn/use only what they need to do this: “Mort is a developer who only learns just what he needs to complete his project, on the project”.

Microsoft Visual Studio and .Net framework are addressing this very well. This is in itself not a bad thing, but it prevent maintenance. Evan Hoff catch it in his post. Clearly: Designer Oriented Architecture goes against maintainability…and Enterprise Softwares (or BPM products) have not yet understood this. Today, I’ve seen high level requirements for new Enterprise Software platform for an external company with 3 requirements inside the same slide: “Easy to build quality application” (where quality means testability and maintainability), “High level of extensibility without preventing upgrade” and “Ease tayloring, configure and manage applications”.

I can understand people that are looking for a Ferrari able to do cross over and consuming less than 1liter of fuel per 100 kilometre…but I’m doubtful on the success of the search.

Quality, maintenance, ease of upgrade, evolution capabilities are just incompatible with tayloring done by Mort.

Scott Guthrie announced that microsoft will release the .Net framework libraries later this year.

The licence will limite the usage of these sources: you can only use them…no bug fix, no enhancement and no new features. This will only help to understand some unexpected behaviour…but only this. Especially for bug fix, this licence is a strong limitation. The best choice then is to use Mono :).

Microsoft has a strange definition of “Open” and it seams to be a trap for real open source project as mono. Steven J. Vaughan-Nichols highlight it there.