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).