Microsoft-ORM: Quo vadis?

For some time things were looking good for Object-Relational Mapping in the Microsoft space... but the tide seems to have changed:

There is the Vote of No Confidence for the ADO .NET Entity Framework (Microsoft is reacting on this with the DP Advisory Council).

And now Microsoft seems to kill their alternative LINQ to SQL!

So what should developers with a decent sense for domain modeling do? I dont think returning to the DataSet is really an option ...

Independent solutions will profit from this uncertainty: Genome, NHibernate, Vanatec ...

We are legion :-)

My colleague Matt started blogging!
He seems to have attracted already some interesting commenters... what a start!

You can find his blog here: blog.rueedlinger.ch

Slowly the bloggers from our business-unit in Bern seem to challenge the blogging predominance from our London colleagues :-)

Of course Matts posts will also be aggregated in my zühlke-stream.

Generic and generated - an oxymoron?

< quick and not well thought out comment >

Last week I was at an interesting presentation.

Some developers were presenting some stuff they were doing with Eclipse EMF and CDO. This was interesting and gave me some things to ponder about ...

But thinking about it I have a big question mark:
One of the marketing-slogans I heard over and over again was in the sense of:

We are doing code-generation, but the cool thing is that it still remains totally generic!

Well, sounds cool ... but ... is generated code and generic code not quite an oxymoron?

If it is generic, why generate it? Wouldn't it be better to refactor it out in a generic component? That's the idea behind Code Generation vs. Code Synthesis.

Is it not the benefit of code-generation to generate highly specific code? Since the code can be regenerated at any time, it is no flaw to be very concrete and verbose, those LOC do not count for maintainability! (I am not the only one to oppose this kind of reasoning, but it is a common argument...)

Once more I had the feeling that I am just not getting the whole Code-Generation-Model-Driven-What-So-Ever-Movement ...

</ quick and not well thought out comment >

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

We are all amateurs blindly stumbling in the dark!

Programming has become too complex. I suspect that we have lost it for good!

Here is another evidence:

Look at this blog post by Jeff Atwood about database deadlocks and look at the comments.

The density of contradictions in the comments is just frightening!

Considering that the commenters are probably the upper class of developers out there, it seems a miracle that there are actually working transactional systems out there...

I am not considering me any better at all, a lot of the things the commenters are talking about seems like black magic to me. But I feel terrified by that fact ... thats the basics man! If we don't know how transactions work, how can we start building business applications?

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

stackoverflow - let it flow some more!

I am pretty late in joining the choir, but I think stackoverflow.com is an amazing site.

This is the very definition of Web 2.0. Just try it: ask a question and be amazed ...

The brains behind the site are the heavyweights Joel "on Software" Spolsky and Jeff "Coding Horror" Atwood.

There are two interesting podcasts with Jeff Atwood, discussing the creation of the site: Herding Code #14 and Hanselminutes #134.

The podcasts reveal some particular interesting facts about the technical realization [see also here]:

The site is based on the Microsoft ASP.NET MVC framework, which is still beta!

The DBMS is SQL Server 2005

The whole site is running on one server: two quad-core CPUs with 4GB RAM

Web-Server and Database take about the same load

The DB-schema consists of about 16 tables

Basing a heavy-traffic application on beta-technology, thats probably what they call extreme courage.

The server seems quite a lightweight! I have seen enterprise applications with a lot less load that supposedly needed much more horsepower...

I would have expected more tables in the schema... but maybe they were talking only about the dynamic part of the data...

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

Java EE: The blue pill of enterprise development?

One thing that stroke me, when I first came across Carbonado was that it was originally developed by Amazon for internal use.

This is another example where a real big boy is not using standard technologies that are brain-fed to foot-soldiers like me out here in the trenches of enterprise development. [Other examples are all the upcoming cloud-technologies: Google AppEngine, Amazon SimpleDB, Microsoft Strata ...]

Sometimes I think I am stuck in some kind of matrix: I am brainwashed that Java EE gives me the right tools for enterprise development. Those tools are not really attractive and provoke a lot of suffering, but hey that's the price for being part of the enterprise!

Strangely, very often I stumble across enterprise-applications, that were entirely developed with those tools in a totally brainwashed and conform way. But they still suffer from exactly the problems that the tools promise to prevent (like performance, scalability, maintainability ...).

On the other hand, sometimes I get a glimpse behind the scenes of the real big boys, like eBay, Amazon or Google... and I get the impression, that there is not much of Java EE there.


I wonder, why might that be? Maybe I should start looking for the red pill...

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

Optimize your app - play Quake!

The quake optimization rule:
Your boss comes to you because your code is running too slow. You take a week to look at the code. Then you go back to your boss an say, that it takes you about 18 month to get a performance improvement by factor two.
Your boss then says, well thats all right.
You go back to your cube and play Quake for 18 month and wait for the next generation of Intel processors.

-Ted Neward, DNR 377

That is an interesting application of Moors Law. But Ted's point is, that those times are over. Scaling processor power with higher frequencies has reached its limits.
Increasing the cores in processors, does not make your existing applications faster for free. Entirely new programming concepts have to be applied to make use of the additional power.
Functional languages can be helpful in implementing those concepts.

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

EJB 3 - The complete makeover?

EJB has undergone quite a makeover!

While EJB 1/2 was considered obese and ugly , EJB 3 now claims to be the complete opposite.

I find the following observation illustrates the complete makeover:

EJB 2 was one of the main reasons for the development of the Spring Framework. Spring aimed to provide a developer-friendly alternative to EJB:

I wrote this book for architects and developers who have grown increasingly frustrated with traditional approaches to J2EE design, especially EJB. It shows what you can do right now t implement cleaner, more productive alternatives to EJB and move into the next era of web applications.

- Rod Johnson (founder of Spring), 2004,
J2EE Development without EJB

During several years Spring was THE lightweight alternative to the heavyweight EJB model.

Now with EJB 3 this seems to have changed to the exact opposite:

The Spring framework then would be "Just Another EJB Container On Steroids" (JAEC :-)) - it would make, however, the integration between EJB 3 and Spring easier, than even now. This lowers the entry barrier for EJB 3 as well: the migration to pure Spring environment, in case EJB 3 wouldn't be sufficient for functional, or non-functional requirements, should be not that hard.

- Adam Bien, 2008

EJB is now presented as a quick and easy technology, very lightweight but maybe not ready for advanced enterprise scenarios.
Spring on the other hand earns more and more critique as beeing overly complex, verbose, xml-heavy [see Bob Lee here and here, Guice Comparison, another blog ...].

One of my last projects was a simple web-application. We decided that EJB would be an overkill and went with a straight JSF-and-Hibernate-in-a-single-war-approach.
Today I think that leveraging EJB3 would have made the implementation easier and not more complex, especially when implementing stateful-conversations.

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

Backing up iTunes Library

I have a Netgear Ready NAS NV+.

I am using rsync to backup my music library to a share on the NV+. This is the exact command I am using:

rsync -av --progress --stats Music/iTunes/ /Volumes/media/Music/iTunes/

[I am posting this mostly as a reference for myself, because I keep forgetting rsync syntax]

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

Are we all toddlers?

Apache Foundation was founded in June 1999.

Eclipse was announced in November 2001.

Hibernate was registered on SourceForge in November 2001.

Those are all indispensable cornerstones of my current professional life. At the time those cornerstones were built, I was finishing my studies at university.
This means during most of the time in which I was being prepared for my future professional life, the stage in which this professional life should take place was not even nearly defined!

This is like being a physics student in 1687, at the time when Isaac Newton published his Philosophiæ Naturalis Principia Mathematica...

You could argue, that it's only the tools that are moving so fast in our industry, the concepts are remaining the same. But I dont't think that is true. We are still in a phase where the concepts are constantly developed and evolved. They have to, for being able to satisfy the ever growing expectations and requirements:

Programming today is not the same as 10 years ago! Most of us have been thought that computer science is about mathematics. We had been learning about algorithm and data structures etc...
Most of this is not really relevant today any more!

[Discaimer: maybe my perception is a bit distorted from suffeing too long in the trenches of enterprise development, but I think nobody can generally deny the change]

Compare this to the following statement from Teach Yourself Programming in Ten Years:

Researchers (Bloom (1985), Bryan & Harter (1899), Hayes (1989), Simmon & Chase (1973)) have shown it takes about ten years to develop expertise in any of a wide variety of areas, including chess playing, music composition, telegraph operation, painting, piano playing, swimming, tennis, and research in neuropsychology and topology. There appear to be no real shortcuts.

What does this mean for our industry? Are we all still toddlers, playing inside our little baby-fences?

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

Have I lost my faith?

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

I was eagerly sucking up the facts the two architects Matthew Wall and Erik Doernenburg are presenting in the podcast.
But after about 20 min I was shuddering: At this point Matthew and Erik are talking about applying Domain Driven Design (DDD), specifically about enforcing aggregate rules, when the host (Markus Völter) was stating the following:

If I had done that, I probably would have defined a domain specific language, for example a textual DSL, that would know about those concepts. Then you could actually write programs using those common language terms as first class citizens.

This made me cringe. I know the Markus Völter is an expert in MDSD and DSLs, but stating the above quote in such a casual manner rings a lot of my alarm bells.

I just have a bad gut feeling if someone wants to build such essential infrastructure up front. That's when my invented-elsewhere-syndrome kicks in.

[YAGNI, Race to Running Software, Less Mass are other things that come to mind ...]

I have just seen too many projects, that invented their very own framework.
In the beginning everything goes smooth and it is very cool to work on TheFramework(tm) and not having to solve the real business problem. You can really feel smart ... But then the 80-20 rule kicks in and all the special cases threaten to turn TheFramework(tm) into a big ball of mud.
And that's even before maintenance becomes an issue of its own ... who is going to hatch TheFramework(tm) when the underlying technology evolves?

I think that endeavors like this should not be taken light-headed. This can cause a lot of suffering.

As my self-confidence as developer is growing, I think I would refuse to work on a project with this premise.

I think it is exactly the point of domain driven design that it is not about technology but about concepts. People too often rush head first into technical realizations. Thats also what Eric Evans says when he mentions that the competent developers often are not invoved in "domain crunching".

On the other hand, some years ago I would not have been so hesitant and precautious. As a highly motivated graduate, I would myself have rushed headfirst into the challange, working on a cool TheFramework(tm) of my own ... So one could ask: Why did I loose my faith?

Honestly I don't know... could it be that I lost my courage in the trenches of enterprise-developement?

Humor is a quality for an architect!

The following question and solution is from the preparation for the Sun Certfied Enterprise Architect (SCEA) from the Sun Learning Center:

You have the assignment to create a new architecture that will be used by your organization for all future web development. Which three characteristics are important when choosing a web application framework? (Choose three.)

A) Billing rates of framework consultants.

B) Code re-use.

C) Ease of Use.

D) It was featured in a computer magazine.

E) Industry acceptance.

F) We write our own web frameworks.

The solution:
Options B, C, E are correct. Options A,D are incorrect because they are not valid architectural concerns. Option F is incorrect because this is generally not the best solution as existing frameworks are well refined.

They didn't get the joke:

I don't think you can count someone even as a semi-decent java dev until he wrote his very own web framework at least once in his life.

-- comment on this blog post

Scrum pigs - musing about commitment

Programming is very difficult. To do it well requires a phenomenal amount of commitment. To motivate yourself and keep yourself committed, you need to have pride in what you're doing. If instead you consider yourself a mechanical assembly line worker, [...] then you're not going to have enough interest in what you're doing to do it well.

The broken window theory

If your commitment doesn’t encompass a genuine passion for the work at hand, it becomes a void that is almost impossible to conceal, no matter how elaborately or attractively designed it is.

Getting Real

Study after study has shown that motivation probably has a larger effect on productivity and quality than any other factor.

Classic Mistakes Enumerated

Commitment is the key for success! This is my firm personal belief!

Sometimes I wonder if I am wrong ... but then I find evidence that others share my belief.

Scrum is one such evidence. Scrum defines pigs and chickens. Pigs are committed, chickens are just involved:

This is not just a joke, without this fundamental role perception Scrum does not work! Everybody involved really has to understand, what it means to be a pig and a chicken.

If one pig starts behaving like a chicken the others have no choice but to gradually follow... we are entering the broken-window-cycle.

But some animals are more equal than others! This is also true for the scrum-pigs: If an unworthy developer-pigglet feels that it wants to hatch and chatter like a chicken, this can easily be corrected or overlooked.

But when the mighty scrum-master-boar or the grand product-owner-sow starts swinging his imaginary wings and bouncing from pole to pole, then all the little developer-piglets have no choice but to follow!

... jumping out of the allegory ...

If the product-owner or the scrum-master (they may also be called customer and project-leader) give the impression that they are not committed to the project, the developer only has two options:

Either he starts committing even more, trying to compensate for the lack of commitment of the others. This is usually a very frustrating and sometimes even self-destructive endeavor.

Or he begins himself not to care. This often a subconscious act of self-protection. But the result is the typical project-setup in mikado-style (whoever moves, looses) and queen-of-spades-style (pass the blame as fast as possible).