Tag Archives: design

Disconnected architecture

I was reading an interview with Renzo Piano in this fridays issue of D2. He is one of the most revered architects of our time and is responsible for many great buildings, amongst them the Pompidou centre in Paris which was his first big break through. He is known for his innovative ideas, but also his very good technical and functional execution of the designs. He was interviewed in connection with the Tjuvholmen project in Oslo, and one of the quotes was just spot on (my translation):

My fundamental reason has it’s origins in my builder background. To me, architecture is a craft. You can’t separate the idea of a building from the execution of it, even though a lot of architects act like it. This has been catastrophic for architecture. – Renzo Piano

In the software world there seems to be a notion that you can draw the architecture, and then let someone else design the details. Because it is based on high level ideas and sometimes faulty assumptions it becomes a resistance for building a good solution, in stead of enabling a solid foundation. Stop separating the architecture from execution, and make sure it is something that is flexible and evolves as execution moves forward. In other words: Architects need to take part in the execution to see the constraints the architecture imposes, and see new opportunities for the architecture to evolve into.

I’m not going to go into that rant now, that’s content for another post, but that also means that the architecture must be evolvable. And less code is more flexible than a lot of code. Strangely enough most architectural constraints tend to lead to more code, not less. πŸ™‚

DDD and generic repositories

Reuse is good. That’s what we learn, so we all strive to reuse code, but sadly sometimes we over generalize and try to be too clever. I have had the suspicion that creating generic repositories that takes criteria/queries as input parameters is one such over generalization. Some things, in fact a lot of things, are worth making explicit.

As Greg Young points out in this excellent article, this over generalization can even hurt you when it comes to tackling performance at a later stage. It’s well worth the read. πŸ™‚

JavaZone 2008 is over

So JavaZone 2008 is over. Had a blast, and saw lots of cool stuff. It was a bit crowded some times, and a bit too many talks was full, but all in all good. Just a short summary for on the good stuff:

  • Heidi Arnesen Austlid on Open Source in the public sector – The government in Norway has a strong preference for Open Source. The motivation for this is to reduce costs, enable exchange of information through open standards and take back control of their it-systems.
  • Rickard Γ–berg on Qi4J – A good introduction to the component oriented stuff Qi4J is built upon. Everything i compiled by the Java compiler, and everything is refactorable. Really nice stuff, that will be extremely interesting once it matures.
  • Mary Poppendieck on the Double Paradox of Lean Software Development – Mary is always interesting. Utilisation is not the thing to strive for, throughput is. In fact if you maximise utilisation for the expected you have no capacity to handle the unexpected and performance will suffer severely when the unexpected occurs.
  • Robert C. Martin on functions for Clean Code – Uncle Bob is also one of those really good speakers that are always entertaining. A good talk on the basics of function design and how to make this readable and maintainable. Most of us has a lot to learn about pretty basic things, and that a lot of this basic training in good programming (often good OO) is ignored in our education.

Reviewing the program I now see that I have missed more good talks than I really wanted. A mix of bad planning, beer and walking around meeting people will have to take the blame. πŸ˜‰ I hope they publish most talks as videos later on.

Great conference, see you next year. πŸ™‚

Abstractions always leak

A quote of a quote in a InfoQ article on the release of GWT 1.5:

Key point: GWT gives you a lot of leverage, but it isn’t intended to be a “walled garden” in any way. Abstractions always leak, so it’s better to embrace that fact. We intentionally make it easy for you to punch through the abstractions and get down to the nuts and bolts JavaScript environment so that you can integrate with any other technology you like. That flexibility is a sort of insurance policy for both GWT itself and GWT users: you can be sure that you’ll be able to combine any client-side technology you want with GWT, and we (the GWT development team) don’t feel as if we have to explicitly provide integrations for an open-ended set of things, because you can always do it yourself without waiting on us. For an example of the kind of flexibility I’m talking about, check out Ray Cromwell’s Syndroid work.

This is a key aspect for good frameworks. Not only because abstractions leak, but also because sooner or later someone will discover a bug or a missing feature. Making it easy to fix or extend the framework for those special cases is essential for a good framework to live and to be adopted.