Jiri Lundak

Archive for the ‘Programming’ Category

The 3 Axes of Agile Architecture

In Agile, Architecture, Programming on April 30, 2007 at 11:10 pm

When thinking about my last post today, I was not quite satisfied with it. The values seamed quite unfocused to me in hindsight.

Actually I think we need to condense – especially the values – some more, so that we get at the essence of the agile spirit we need to be able to measure a good architecture against it.

In the end I think it boils down to the following three axes, along which an architecture (maybe embodied by a framework) can be judged (see the figure below).

Agile Software Architecture Principles

I would contend, that an architecture satisfying all three of the axes is THE agile architectural basis for software development that is able to deliver on the agile promise.

Let us have a deeper look at the individual axes:


This axis focuses on embracing change. For an architecture to support this, it needs to be easily modifiable, extendable, refactorable. If it is hard to change, it will lead – over the long run – to clumsy code, horrible work-arounds, lots of glue code and very extensive documentation, that needs to explain all of its quirks and potholes.

If it is easy to change and the developer is free to change his application at will, without too much effort, without breaking existing functionality of his application, then the overall design of the architecture (and the framework eventually embodying it), will remain simple, clean and easy to grasp over quite a long period of time (good tending practice implied).


Agility has one of its foundations in the delivery of production quality code on from iteration 1 to whatever number of iterations a project takes to complete. As such an application developed in agile manner needs a foundation, that has quality build right into it. This kind of architecture makes it hard for the average developer to make stupid mistakes.

It simple does not allow to circumvent good coding practices. It allows freedom of interpretation only in dimensions, that are in the application domain. It helps the developer to test his code in an easy, dare I say fun fashion, so that he wonders, how he could ever live without the safety net he is constantly weaving.


Though I mention this axis at the end of this text, it is the focal point of agile software development. When we do not produce the right thing, it is of no use to produce it as fast as possible with the highest possible quality.

That said, it is crucial to produce value for the customer. The architecture should not stand in the developer’s way to produce some useful application. It should encourage him to produce value out of the box, to be able to show his customer a thin, but fully working, slice of the final product he will get.

At the same time it should prove to be a tool in the developers hands, that allows to try out easily alternatives, that can be quickly transformed into a visible artifact to put in the hands of the customer, so that fast feedback can be harvested, which eventually flows back into the development cycle.

Complementary products like acceptance testing support and generic self-documentation should help to produce value faster.


To produce an architecture (embodied in a application framework) that supports these essential values, may not be easy, but at least this is a starting point to think more deeply about principles that support this value-system.

As a nice side-effect I now have a system, that allows me to have a look at existing application development framework and weight them against each other. But I will spare this for another post.

Agile Software Architecture Principles

In Agile, Architecture, Programming on April 30, 2007 at 1:30 am

It is not a secret that I am fond of Agile software developement. I have published multiple articles over the last few month on pitfalls with Agile implementation and I am even writing a book about it.

But in my chest there still beats a heart of an architect and developer. As such I would like to see still better tools, frameworks and development practices. Last friday I was the last standing man at our company, with a colleague of mine and we were fantasising about our personal take on a lean, mean application development framework. We found quite a common ground, when it came to our dislikes with the existing way to develop software in the Java world.

It is always easier to articulate your dislikes, instead of reflecting on the values and principles, that you would like to see flourish.

So what we dislike about existing frameworks boils down to the following short list:

  • Configuration in monstruous XML configuration files
  • The jungle of XML WebServices as the SOA silver bullet for all application integration
  • Way too much code generation in the past
  • Although we are fond of metadata to be leveraged in applications, we dislike too much annotations (obscuring further how things work)
  • Writing still applications for the single VM, not using the power of many distributed ressources
  • Frameworks, that grow to such giant dimensions, that you have to install a 60 MB package, of which you use only 1% in your application
  • Frameworks, that want to be everybody’s darling, by including hunderts of alternatives (we integrate anything) for each module and for this sacrifices ease of use and efficiency in programming
  • Generation of boiler-plate code seen as THE holy grail in increasing productivity

When going through these points in retrospect, I would like to synthesize some values and principles, that I would like to see in a framework, that really helps me concentrate on giving a customer what he needs, without much of the grieveance included, when using today’s breed of tools.

Here are the values I would like to see embodied by an ideal framework:

  • Efficiency
  • Purity
  • Easy Modifiability
  • Expressiveness
  • Openness

These should be support by principles the framework should enforce and follow:

  • Ease of use
  • Transparency
  • Scalability
  • Maintainability
  • Testability

There is some tendency towards easing the pain of development with the advent some of the newer frameworks for web development, maybe started by the hype surrounding Ruby on Rail. Other new frameworks, that fit in this category are SEAM and Grails.

While these frameworks tend to point into the direction I would like to imagine, they are still not there, yet. Too much boiler-plate code, sometimes too much XML. And if all else fails: I could still argue, that they are not Java frameworks! 😉

I just would like to take the Agile thought to the extreme and make it as easy as possible (in Java) to implement and maintain an enterprise-ready application. “I know I’m a dreamer…but I’m not the only one”, to speak with Lennons words.

But who knows, out of idealism, sometimes something new and revolutionary can emerge. Let’s get surprised.

Technorati : , ,
Del.icio.us : , ,
Ice Rocket : , ,

Poor People … Being So Platform-Dependent

In Programming, Technology on April 1, 2007 at 2:55 pm

In the April 1st 2007 issue of SD Times, in an article called “At Last, Visual Studio 2005 Works on Vista” David Worthington wrote:

“The Visual Studio product team had a decision to make last fall as Windows Vista progressed toward release: It could either ship a first service pack for Visual Studio 2005 that worked on the then-current versions of Windows, or wait for Vista. If it waited, there would be no compatible version of Visual Studio ready when Vista launched. Since a delay wasn’t acceptable to the team, the service pack was made available in December 2006. Vista was unveiled one month later, but Visual Studio 2005 was not certified to work with the operating system.

Since that time, Microsoft has caught up with itself. Visual Studio 2005 Service Pack 1 for Windows Vista arrived in March. Earlier versions of Visual Studio cannot run on Vista.”

This is just one consequence for making the software development environment dependant on the operating system. It actually shows the problems Microsoft is going to have in the future, when it continues with these dependencies.

Sure this makes developers dependent on the operating system release and forces them to buy a new operating system version, to get new features and to buy a new IDE version to be able to develop on top of the new operating system release. A downward spiral.

This does not lend itself to an agile software development approach and only make developers slaves of the platform.

This also shows how plattform abstraction in the virtual machine of a runtime environment is so important. And Microsoft is not able to deliver something similar. So I remain still grateful, that I never went down the track of .NET too far. Else I would have been crippled in my choices, something I prefer not to be.

QCon Day 4

In Conferences, Programming on March 15, 2007 at 2:04 pm

We have arrived at the forth day of the QCon conference. Although today there is an Agile track, I will attend some of the more technical session, too.

Deborah Hartmann introduced the sessions and off we go. I will start with the session on “Grails” by Guillaume Laforge, the Groovy project manager and co-initiator of the framework, that tries to port ideas from Ruby on Rails to the world of the Groovy scripting language. A colleague of mine that is writing a book on Grails has recommended the session, so I will go and see what I get for my money. 😉

Grails = Spring + Hibernate re-invented

Here are the main messages of the presentation:

  • Even simple things are quite painful to accomplish with Java frameworks (ORM persistence hard, numerous layers and config files lead to chaos, UI integration messy)
  • Grails is an MVC action-based web framework
  • Principles: Convention over Configuration (CoC), Don’t repeat yourself (DRY)
  • Grails builds on proven components: Spring, Hibernate, Groovy, SiteMesh, AJAX

How Grails addresses pain points:

Pain Point 1: ORM persistence (many XML config files)

  • Domain model based on POGO (Plain Old Groovy Objects)
  • Relationships between POGO’s based on convention
  • Grails generates (called scaffolding) view and controllers for you for a quick start
  • By adding constraints to fields an easy way of validation for correct values is provided
  • Write only your domain model objects and generate the rest
  • Modify some GSP (like JSP) page (view) or some text and reload the page and you are done

Pain Point 2: Numerous config files and layers

  • Most things work over conventions (dynamic finder-method construction, based on known fields)
  • Reading over relations
  • URL’s have easy, consisten mapping like ‘controller/action/id’
  • Parameter passing thru easys maps
  • Easy job scheduling using Quartz

Pain Point 3: Messy JSP-like pages

  • Predefined Taglibs and Components
  • Define own Taglibs

Sweet Spot: Enterprise-ready

  • Existing Java libraries
  • Employee skills & knowledge
  • Spring configured beans
  • Hibernate mappings for legacy schemas (but still benefit from dynamic finders)
  • EJB3 annotated mapped beans
  • JSPs, taglibs for the view
  • Deploy to your pricey Java app-server & database
  • Grails will fit in your J2EE enterprise architecture

Positive impressions about Grails (maybe to incorporate somewere else)

  • Conventions over Configuration
  • Extend that with metadata where needed
  • Dynamic language, so short code-build-run cycle

Questions that remain

  • How much logic goes into the GSP-pages?
  • Taglibs, huhhh?
  • Still generation needed? Why?

All in all an informative talk of Guillaume. Maybe I should try some first steps with Groovy (although its syntax does not appeal very much to me).

The afternoon starts with another scripting language: JRuby. I first wanted to attend the Test-Driven Development session of Steve Freeman, but during his introduction I noted it was too elementary for my knowledge, so I voted with my feet and went for the session about how to integrate Java and JRuby.

In contrast to the Groovy session, the JRuby session seamed quite low-level. No so much the content, but the form of presentation. The presenter (Rob Harrop) just started with the jirb (JRuby interpreter) in commandline manner. He type away quite fast, but after the code moved over the top of the screen, I think, nobody new anymore, what exactly he was doing (actually creating a small Swing application) directly in the interpreter.

So how does JRuby compare to Groovy/Grails. I am basing my lay judgement on few things I saw on the two sessions, so see this not as an expert talking.

Ruby integration into Java is not seamless. Instead you have to use special integration classes to bind it in. Groovy instead makes the use of Java objects a breeze. Java objects and Groovy objects can be used as if they were the same.

Ruby showed a strength in creating new domain specific languages (DSLs). From the point of view of a poor Java programmer JRuby feels very awkward and strange. Many things are not obvious, this is one of my main critique points. Explicitness ist often missing, like when you overload operators, etc.

A issue I find critical with JRuby and Groovy is the dynamic additon of an API (say methods, functionality) to ONE specific instance of a class. While this might be useful in some case, it can actually be nightmarish when it comes to read and understand code. It actually decouples classes from logic making it more difficult track down, where something happens at which point in time (without recurring to debugging).

The next session was “SEAM” presented by Gavin King. He started with the usual rant against Agile and Test-Driven Development (TDD), by saying you need nothing of this “crap”, just use Seam and you are up to a quick start with your web application.

Seam generates a skeleton for a web application inclusive some simple test code. You can modify the code of your application much like in Grails.

“We need no f*cking unit tests. Any one programmer can write those simple POJOs without error. The problems come, when you test a class together with its collaborators.”. So much about a professional attitude to testing.

Seam uses much XML configuration and is in that regard not better than Hibernate or Spring. Gavin admits, that he would prefer doing it in plain Java.

What Seam brings to the table:

  • Single component model for JSF, ESB, EJB, etc.
  • No actions
  • Persistence: No DAOs, instead binds components that access database through JPA/Hibernate directly to the view
  • After changing the DB structure, you need to restart the web server.

Seam incorporates the concepts of conversation based transaction. This a very valid approach to transaction handling in web applications. In fact we have incorporated something quite similar in our own framework.

The next session I attended swang back to Agile software development, when Jeff Sutherland, the co-inventor of Scrum, talked about “Agile Project Management: Lessons Learned at Google”. The room was crowded full, which nicely reflected the interest people had in Scrum. The voices I overheard at the conference showed clearly, that many people would like to try Agile, but feel very unsecure, what agile would bring them and how to start with it. Many doubt that it is worth the effort.

At Google the Adwords project is using Scrum, they have begun about a year ago in early 2006 to introduce individual Scrum practices, like a release backlog, into the company. Originally in 2001 Google decided, that they did not need any Managers, because they were not adding value to the company. So they eliminated all managment positions. So from that time on, projects evolved organically. When Google was growing bigger and the software (in case of Adword) increased in size (500’000 LOC and still growing fast), the project manager of that project saw the need for a little bit more structured approach, which would not destroy the organic nature of the current way to do things, as this was seen as a good thing.

Technorati :
Del.icio.us :
Ice Rocket :

QCon Day 2

In Agile, Architecture, Programming, Technology on March 14, 2007 at 3:33 pm

On the second day I participated in Kevlin Henney‘s “Hands-On Agile Development Workshop”. You may ask yourself, why as a proponent of Agile development and coming from a company, that tries to employ Agile practices across all its projects I attend such a newbie-event.

Well this is mainly for one reason: Part of my role at Löwenfels Partner is that of a Agile advocat or evangelist. The other part is to coach our teams in Agile practices and values, by leading through giving an example.

So my main interest in this session was to see how Kevlin presented the session. Some things I observed about his session:

What I liked:

  • Organized Scrum-like in four Sprints
  • Complex-enough problem to solve
  • Sprint 0 used to introduce Agile concepts in a very fun and lightweight fashion.
  • Sprint planning/commitment included
  • Strong test-first approach thaught effectively
  • Team collaboration stressed through pair-programming, changing pair, focus on clean interfaces for easier integration of team results
  • Practical stories from real world projects mixed in
  • No dogmatic propagation of Agile practices, but pushing common sense conclusions
  • Real struggling with personality types (people you do not know) when pair-programming and cope with that diversity
  • Introduction of kind of a metric for a good unit test: nearly non conditional logic in the test itself. This leads to more readable and understandable tests, that communicate well the intention of application unter test, a lot like a good a specification.
  • Nearly as much test code as application code to be tested.
  • “By omitting tests we will not be able to write the double quantity of code”.

What could be improved:

  • Kevlin talked very much himself. I at least would have prefered more interaction

And the reaction of the attendants? Most of them were convinced to need to apply the trained practices in their organizations, some even against the current paradigma in their companies.

Would I recommend the workshop? Definitely! We should do something similar in our organisation (at least for new employees, if not all). I will try in the coming months to build on that.

Technorati :
Del.icio.us :
Ice Rocket :

On my way to the QCon Conference in London

In Agile, Programming, Technology on March 10, 2007 at 5:45 pm

I am sitting at Zurich Airport and waiting for my flight to London right now. I am attending the new QCon Conference there and am quite curious, how it will be like.

The roundup of speakers and tutorial hosts promises an information packed week. Besides quite an interesting Agile track, there are lots of sessions about technological themes that have caught my eye. After investing lots of my time recently in Agile processes and soft factors in the software engineering field, I feel it is time to go a bit back to my technical roots and have a look at architectural and “hype” themes this time.

Besides that I hope to meet many known faces, like Deborah Hartman, Joseph Pelrine, Peter Sommerlad, Steve Freeman and some other I got to know and appreciate in the past. But I am sure, there is also room to get to know some new and interesting people. And besides that London is always a place that never gets boring.

So stay tuned, as I will try to post some daily conference update on these pages.

Technorati : , , ,
Del.icio.us : , , ,
Ice Rocket : , , ,

Explicitness Going Down the Drain in Java

In Programming on September 6, 2006 at 12:50 am

There it goes down the drain: The wonderful explicitness of the Java programming language.

Do not missunderstand me. No, Java is not the mother of all languages. It was, in its beginning, just a very easy to learn language, with a tightly integrated language core, and with a growing set of more or less powerful libraries, that could very easily extend the language’s usefullness to many areas.

Sure, primitive data types (like int, boolean and long) were a bad choice. Making everything an object would have been more appropriate (as in Smalltalk et al.) and would have given Java the possiblility to be not just an easy way to learn a programming language but an easy AND elegant way to learn it.
But we just plain missed on that chance. Instead we introduce constructs and syntactic sugar to the language core, that mess things up, make the language more complicated, more obscure, doing magic things, that – instead of giving us transparency and a clean concept to build on – just make programming harder and more error-prone. See one terrible example here in this blog entry.

Is it time to say goodbye to Java? I think not yet really. There are still too many Java libraries out there that make it worth messing with Java!

So what can we do about the new Java language features? Well, just say no to autoboxing et al. and go explicit again! What do I mean by explicit? See this old JavaWorld article about an explicit programming style, and why to prefer it.