New family member again!

It has been less than 9 month since the last happy event, but my family has received a new member again:

Unfortunately it has been a bit of a premature delivery ... it will take another two month before it will be allowed to go outside ...

follow me on twitter, I need some friends :-)

Musing about Code Generation, MDSD and DSLs

Disclaimer: I am a developer of business applications. The following view is certainly shaped by my experiences in trenches of enterprise IT. I am aware, that there are other domains of software development. Especially in industrial and/or embedded systems development the world might look different.

I have blogged about MDSD and code generation before: Code Generation vs. Code Synthesis, Sunday Morning on InfoQ, Part 2 and Generic and generated - an oxymoron?.

I think MDSD is still too much tied to code generation.

Code generation is only useful, when your code contains a lot of noise and/or is very repetitive. In other words, when your code can not mainly focus on the essential complexity, but is polluted with accidental complexity.

In my opinion the trend in current platforms and frameworks is exactly to remove accidental complexity and letting the application code focus on essential complexity.

So these new platforms/frameworks take a lot of the wind out of the sails of the MDSD movement.

DSLs (textual ones) are another trend that tries to enable the sole focus on essential complexity. While DSLs can be used as source for code generation, they are not primarily tied to code generation. DSLs (especially internal DSLs) basically let it open to be interpreted/executed at runtime. [runtime code generation is somewhere in between].

So even if DSLs are often mentioned together with MDSD, I think they are really an alternative to MDSD. And given the current hype, they also take the momentum out of the MDSD movement.

If you have reached the goal of ultimately removing accidental complexity out of your code (I know this is fictitious), then you have arrived at a textual model of your business problem. This cannot be further simplified!

Nice boxes and diagrams do not offer another simplification or elevation of the abstraction level! They may be good for visualization, but even that is questionable. A picture is not always the best representation to grasp complexity!

Further more, the current state of the tooling involved in MDSD adds another level of accidental complexity (think: synchronization, diffing/merging, refactoring ...) which basically nullifies the ultimate goal of simplification!

Look at the following ActiveRecord model, as an illustration of my theory:

class Firm < ActiveRecord::Base
   has_many   :clients
   has_one    :account
   belongs_to :conglomorate
end

I dont think that this can be any more simplified. Also any graphical representation with boxes and lines would be no simplification, and would not offer any more convenience (think about layouting, refactoring, searching, diffing ...).

follow me on twitter, I need some friends :-)

Some requirements are different...

Last week I was at a requirement engineering course.

One thing that stuck was, the Kano model, which can be used to classify requirements:

Depending on their category (excitement-, performance- or basic-attibutes) the corresponding requirements have a very different influence on customer-satisfaction.

Basic attributes can easily be overlooked, if you are not familiar with the domain, because often they are not explicitly mentioned.

Excitement attributes are the factor that make the difference.

Over time, with each new product-version, given attributes drift from excitement to performance to basic.

follow me on twitter, I need some friends :-)

Fowler, a Werewolf and no Silver Bullets

Fowler as a werewolf is just hilarious:



This is from the No Silver Bullet Reloaded Retrospective OOPSLA Panel 2007.

There are a lot of gems in the quote from this discussion! The sarcastic comments from Fowler alone are worth the read of the summary...

Reading the summary there seems to be a general consensus that there is really no silver bullet.

But this is also a dangerous consensus. As Bertrand Meyer (also in the summary) poses it:

... many people, especially managers, rejected new ideas of the ‘80s and ‘90s like OOP, because they did not believe the new technology proposed to them would have a serious impact on development ...

Using the insight, that there is no silver bullet as an excuse to stop trying to improve is certainly not the way to go!

I was a student of Bertrand Meyer at university, and he was a critic of Fred Brooks paper, because he claimed that it was smothering innovation and the desire for improvement.

follow me on twitter, I need some friends :-)

IntelliJ IDEA 8 on OSX crashes on 64-bit JVM

Smart Java Beans 3.0 Ready IDE
for Error Free EJB Development I am playing around with IntelliJ IDEA 8.

The IDE kept crashing on me after building a project.

The problem did not occur any more after configuring the default JVM to J2SE 5.0 32-bit (with Java Preferences).
For some reasons I had changed that to Java SE 6 64-bit ...

I am using: OSX Leopard 10.5.5 and IntelliJ IDEA IDEA 8 build #9013

This could be the same problem as reported here. But I did not test the suggested solution (delete growl.jar).

follow me on twitter, I need some friends :-)

Alternatives to Hibernate updated

Recently I stumbled over another ActiveRecord implementation for Java: activeobjects.

Instead of updating the list from my last blog post, I decided to start a Wiki-page: ORM solutions for Java

The goal is not to list every existing framework, but solutions that are actually valuable when starting a new project today.

Feel free to complement the list ...

follow me on twitter, I need some friends :-)

Work smart not hard: another step in the right direction

Today SpringSource acquired G2One, THE company behind Grails.

Read the announcement from SpringSource.
... and the blog posts from the Graeme Rocher and Guillaume Laforge.

I think this is a very pleasant step for getting Groovy and Grails into the enterprise and consequently a big step for enterprise developers that want to work smart not hard.

In my experience it has been hard to bring Grails or Rails into the enterprise. Decision-makers in corporate-IT seem to be terribly afraid of new languages. In my opinion this is not justified, given the fact that other technologies are happily adapted, regardless of their over-complexity in many cases!

If Groovy and Grails becomes a part of the Spring portfolio, the argument becomes much easier or even obsolete, because Spring is widely accepted in the enterprise.

I have to start looking for a Grails project ...

follow me on twitter, I need some friends :-)

Two views on the importance of code

Today I had some time catching up with my podcast-backlog. Here the two most memorable quotes:

Code Quality is very low on the list of things that matter.

- Jeff Atwood on Hanselminutes #135

You have nothing to do in Software engineering if you didn't ever code.

- Markus Völter on SE Radio #112

Slightly controversial... though I like to share Markus' opinion, I think Jeff's quote is the sad truth...

follow me on twitter, I need some friends :-)

Anemic vs. Rich Domain Models

There is an interesting discussion on stackoverflow: Why do we need entities?

When I read through this discussion, I get the impression that most people here are looking at entities in the sense of an Anemic Domain Model. A lot of people are considering the Anemic Domain Model as an antipattern!

There is value in rich domain models. That is what Domain Driven Design is all about. I personally believe that OO is a way to conquer complexity. This means not only technical complexity (like data-access, ui-binding, security ...) but also complexity in the business domain!

If we can apply OO techniques to analyze, model, design and implement our business problems, this is a tremendous advantage for the maintainability and extensibility of non-trivial applications!

There are differences between your entities and your tables. Entities should represent your model, tables just represent the data-aspect of your model!

It is true that data lives longer than apps, but consider this quote:

Models are forever ... data is a happy side effect.

-David Laribee

Some more links on this topic:

Why Setters and Getters are evil

Return of pure OO

Generalization - Another Gap between DB- and OO-Models

POJO vs. NOJO

Super Models Part 2

TDD, Mocks and Design

follow me on twitter, I need some friends :-)

Architectural cornerstones

Recently I was listening to the excellent episode of Software Engineering Radio about the new Guardian.co.uk website.

There is also an article about the same project on InfoQ, focussing on the DDD aspects.

As an aspiring architect I am sucking up qualitative and quantitive characteristics of interesting enterprise applications.

So here is my summary of the facts as I understood them:

The application stack consists of

Velocity as view technology

Spring

Hibernate3

Oracle

The interesting points here are:

No EJBs are used, just WAR deployment.

No higher-level view-framework is used, just templating with velocity.

The productive system is depoyed on Caucho Resin, no heavyweight appication server.

The nonfunctional requirements are:

180 million hits a month

18 million unique users

17 Pages/s per Server with 8 servers as peak-performance

The developer-team has peaked at 104 members. Those were split up in 4 smaller teams.

One of the most interesting aspect from a development perspective is the fact, that the business people are actually responsible for the domain model, not the programmers!

follow me on twitter, I need some friends :-)

What it takes to stay happy: More!

We act as though comfort and luxury were the chief requirements of life, when all that we need to make us happy is something to be enthusiastic about.

— Charles Kingsley

Recently at the shnit-festival I have seen the brilliant shortfilm "More" by Mark Osborne (better quality on youtube):

More - Funny home videos are a click away

The underlying theme of the movie is a frequent topic on my blog:

Scrum pigs - musing about commitment

Salary vs. Suckage - is there a relation?

Care and Commitment - Don't even get started without them

Job Conclusion

Motivation and Productivity

follow me on twitter, I need some friends :-)