Simply Fooled

It is always good to start out with a diagram. Here’s one:


It tries to say:

Tools that invest in “getting you started quickly” seem to always fail to stay productive or particularly useful in the mid and long term.

The typical example for this is visual programming tools or process designers of any kind. I yet need to see one that is useful beyond most simplistic demos.

I believe however the same problem is inherent with “scaffolding generation frameworks” like Ruby on Rails, Grails, and the like – possibly anything that claims “convention over configuration”.

While these approaches deliver some result quickly – eventually you will need to understand the framework, that is a pile of lots, lots of stuff that, once you lift the lid, can be totally overwhelming.

If you had started with much less, well-understood ingredients, you will be moving more slowly but at least on solid ground.

Not that I ever had an urge to use any of this kind of toolset and platform – I rather build from more essential building blocks that I understand and can keep under control – convinced that that leads to more robust, understandable, and maintainable solutions.

There is one example however that I use a lot and have a bit of a love-hate relationship with: Java Persistence Architecture (JPA).

And yet…

We use JPA a lot in most projects. It is rather convenient for simple tasks like storing records in the database and retrieving it for transactional data processing. The session cache is handy most of the time. Updating entities simply by setting values is nice. But you better not have complex queries, large transactions, or non-trivial relations. And better not ask for too much flexibility in combining modular domain models (a.k.a. Persistence Units in JPA speak). There has been so much stuff written on JPA, there is no need I repeat (the Vietnam of Computer Science however is a must).

Anyway, the point is: When you reach the limits of JPA, you better have your persistence tier already abstracted in a way that it does not hurt too much replacing the actual data access with other techniques where needed, which comes at a price.

Let’s say. If I had not invested in JPA previously, it would probably feel out of place and unwieldy now. Given the style of clean persistence API that we tend to implement on the application level these days, I would rather use some more accessible “bean mapper” tool.


Here is my little theory: Putting your main focus on solving 70% of the problem quickly compromises so hard on the completeness of the approach that the remaining 30% of the problem get overly expensive for its users. Worse, the “left-overs” may require to break your architecture, require unexpected 3rd party stuff, etc.

In addition, if you have made a choice for the early win, the price to pay later on may be due at the worst point in time, just when your architecture has to stand the test of growth.


  • Don’t be lured by promises of simplifications of what is inherently not simple
  • Always try to look under the hood. It is not necessary to understand everything down to the bare metal – but knowing how much there is, helps getting an idea
  • Get into it, avoid what cannot be mastered in time – it will be mastered later!

Wish you a great holiday season!

A Web App Wrapper or “Why are Web Applications Less Likeable Than Native Applications – Still?”

In between for something completely different.

I use web apps in my daily work. Heavily, if not mostly – except maybe my IDE and the occasional MS Office session. But for reasons that I find not obvious, they are still not on par with native apps. This is not due to lack of responsiveness or desktop integration. There is very little in terms of user experience where web apps that I use lack. And still – if available I’d rather chose the native alternative. So…

Why is it that web apps are still not as “likeable” as native apps?

A few weeks ago mozilla thunderbird, the friendly companion of many years, finally became unusably slow for me. As MS Outlook is no option for me I started looking for an alternative that would be fast at startup and while flipping and searching through mail, would run on Linux, AND has a well-working calendar integration. There are numerous promising candidates for the first two requirements. But, strangely enough, it seems that calendar support is a tough problem.

But then, my e-mail as well as my calendar is perfectly accessible via a Web interface. It is just that I do not use it that much – although it is fast, responsive, usable the same on all machines, and obviously OS-independent (and was made by Google). Duh!

So why not use that instead of a dedicated native client?

Turns out what really turns me off is that the Web client exposes you to a through and through fleeting user experience:

  • As your desktop gets cluttered with open browser tabs, usually the sensible way out is to close them all. Your important stuff got closed as well.
  • You are using multiple users but your browser only manages one session at a time
  • You want to have the right stuff opened at startup – not nothing, not what happened to be open last time – and you want to have multiple such configurations.

None of this seems unreasonable. And yet I have not found anything that does just that for me.

Ta da!

As a conclusion I looked into “how to wrap my favorite web apps into a native application”. Not for the first time – but this time with the necessary frustration to see it through. Such a “wrapper” should fix the problems above and other do absolutely nothing beyond the absolutely required. Here is the result:

How does it work?

It is based on electron – that is: It is essentially a scripted chrome browser. And it is very basic and does very little beyond showing a few site-buttons, preloading some of them (always the same) and can be loaded several times for different “partitions” – which implements the multi-session capability.

I have been using it with two different configurations (shared on all machines) and two partitions (private/work), for a few weeks now and finally feel like the five to ten Web apps I use all the time, every day, feel completely integrated with the overall desktop experience – just like any other native application.

Feel free to use, enhance, copy whatever.

Not with the target audience anymore?

Lately when I listen to talks on new and hot stuff for developers, be it in person or on the internet, I have the feeling that its not possibly me who’s being talked to.

It’s not just like having seen the latest web development framework over and over again – it’s that’s it’s only ever Web frameworks – sort of. It’s the unpleasant feeling that there is a hell of a lot of noise about stuff that matters very little.

This post got triggered when my long time colleague Georgi told me about Atomist, the new project by Rod Johnson of Spring Framework fame. Atomist is code generation on steroids and will no doubt get a lot of attention in the future. It allows you create and re-use code transformations to quickly create or alter projectsrather than, say, copy-pasting project skeletons.

There may well be a strong market for tools and practices that focus on rapidly starting a project. And that is definitely good for the show. It is really far away from my daily software design and development experience though, where getting started is the least problem.

Problems we work on are the actual business process implementation, code and module structure, extensibility in projects and for specific technology adaptations, data consistency and data scalability, point-in-time recovery, and stuff like “what does it mean to roll this out into production systems that are constantly under load?”.

Not saying that there is no value in frameworks that can do some initial stuff, or even consistently alter some number of projects later (can it?– Any better than a normal refactoring?) – but over the lifetime of a project or even product this seems to add comparatively little value.

So is this because it is just so much simpler to build and marketeer a new Web framework than anything else? Is there really so much more demand? Or is this simply a case of Streetlight effect?

I guess most of the harder problems that show up in the back-ends of growing and heavily used applications cannot be addressed by technology per se – but instead can only addressed by solution patterns (see e.g. Martin Fowler’s Patterns of Enterprise Architecture) to be adhered to. The back-end is where long-lasting value is created though. Far away from the front end. So it should be worthwhile to do something about it.

There is one example of an extremely successful technology that has a solid foundation, some very successful implementations, an impressively long history, and has become the true spine of business computing: The relational database.

Any technology that would standardize and solve problems like application life cycle management, work load management – just to name two – on the level that the relational database model and SQL have standardized data operations should have a golden future.


  1. Atomist
  2. Rod Johnson on Atomist
  3. Streetlight Effect
  4. Martin Fowler’s Patterns of Enterprise Architecture

Some more…

* it may as well be micro-services (a technical approach that aims to become the “Web” of the backend). But then look at stuff like this

Continuity is King

towerUnfortunately there has been so much going on in my work life and my private life lately that I didn’t get around thinking and writing much.

Here is just a short note that v2.4 of z2 is ready: v2.4

It simply upgrades z2 to Java 8 and upgrades the version of Jetty we use to 9.3. The latter implies that Java 8 is a strict requirement too.

Little change is good as those projects that run with z2 need anything but platform disruption at this time.

As the core did not change incompatibly (at least not that I know), using a v2.4 core with previous z2-base version 2.3 will simply add Java 8 support to any such setup as well.

Anyway here’s what I hope to continue on once I am back to normal operations again:

  • A piece on how to use clojure on z2 with a guest author from Vienna
  • A piece on a variation of the Stockholm Syndrome that can be observed in the relationship of developers with their toolset
  • A piece on how organization can be classified as Project vs. Product driven


The Mechanics of Getting Known

“…a soliton is a self-reinforcing solitary wave (a wave packet or pulse) that maintains its shape while it propagates at a constant velocity. Solitons are caused by a cancellation of nonlinear and dispersive effects in the medium.” (see Wikipedia).

Solitons occur in shallow water. Shock waves like Tsunamis can be modeled as solitons. Solitons can also be observed in lattices (see Toda-Lattice).

Among the many interesting properties of solitons is that solitons can pass “through” each other while overtaking – as if they move completely independently of each other:

By Kraaiennest (Own work) [CC BY-SA 3.0 (], via Wikimedia Commons

By Kraaiennest (Own work) [CC BY-SA 3.0 (, via Wikimedia Commons

This post is my own little theory on the mechanics of how an information (on a subject, person, anything) becomes relevant – over time:

The Theory

An information on a subject, such as “Grails is very popular among Web developers” (of which I am not so sure anymore) or “No point in buying a Blackberry phone – they will be gone any time soon” (I bought one just last fall) or “Web development agency X is reliable and competent” (this time I really don’t know) spreads in a lattice of people (vertices) and relationships (edges) just like a soliton. It may pass others and it may differ in velocity of traversal.

Its velocity corresponds to how “loud” it is, its amplitude. It is louder, if it is generally considered more noteworthy when it entered the lattice.

As so many information snippets reach us every day, we sort out most as insignificant right away. So what makes a piece of information memorable and in particular recallable (e.g. when wondering “what is actually a good Web development agency?”) or even trigger an action like researching something in more depth?

It is the number of times and some (yet unknown) increasing function of the sum of amplitudes of all times that that piece of information (and its equivalent variants) has reached us.

So what?

Now that we have this wonderful theory, let’s see where that takes us.

It fits to common observations: Big marketing campaigns (high amplitude) send big solitons into the lattice. They do not necessary suffice to create action and so need to be augmented with talks, articles, rumors to add more hits,

Also it explains why that is equivalent to creating many small information solitons. There is great examples of open source tools that made it to impressive fame via repeated references in articles and books – without any big bang.

Most importantly, it explains the non-linearity of “return” on marketing: Little will lead to nothing in the short term. Not just little but actually nothing. Over time however hit thresholds will be exceeded and interest lead to action. As the speed with which solitons pass through the lattice does not change talking to many will not speed up the overall process – but increase the later return instead.


Surprisingly enough, some 15 years ago, as part of my dissertation work, I published some math papers on PDEs with solitons:

Not much to say but…

Working on two super interesting posts on z2 v2.3 Maven repository support and smart property pre-processing (check out the roadmap) as well as, and on the other end of the scale,  on how to make secondary indexes for HBase applications.

Anyway, didn’t make it in time and there are seasonal priorities after all.

Hope you have a good start into 2014!


@Gearconf Düsseldorf

A nice conference.

I had the pleasure to give a talk about Z2 at the Gearconf 2012conference in Düsseldorf. The main theme of that event is tools, processes, and anything else around the subject of actual software production. I enjoyed great talks and a well-chosen venue.

My best regards to the organizers!

We concluded the first day with a barbeque

Some final (or not so final) refreshments afterwards

in the courtyard of the really nice youth hostel in Düsseldorf

Last warming rays of sun

And some final impression (from a walk across the Rhine river to Düsseldorf Altstadt):

Sun sends some final rays through the clouds over the Rhine


ERP People get it

Lately we have been visiting a potential customer of ours that is interested in learning more about z2 and eventually using it to increase development productivity, maintainability as well as customizability of customer installations.

The approach behind z2, i.e. what we like to call System Centric, to a large extent and regardless of the implementation implies or at least fosters these attributes. As there is little to no development setup, no build fixing, and integration happens essentially as soon as meaningfully possible, productivity naturally goes up. As sources and customization is always at hand, maintaining and customizing further works just as well as the solution at hand intrinsically allows.

What is strikes me is that developers and operations professionals with an ERP background (disclaimer: not even SAP in this case) typically get this right away.

That is strangely contrasted by the observation that Java developers have a much harder time to notice the waste of time and the added complexity that  gets dragged along. That may be due to being so deeply used to the working mode  that it has become close to a natural law – nothing to question anymore.

Another reason could be that every now and then some toolset manages to creates a level of hype and a so deeply convinced following that tools expand beyond their space of usefulness. In other words, there is a lot of “golden hammers” out there. One now historical example is the Enterprise Java Beans (EJB) technology, that actually started out as Remote Objects – which makes sense – and then got perverted into some sort of locked away, XML polluted, and finally slowly starved “Java Objects Deluxe”.

One more recent example is the Maven toolset. Not saying that it doesn’t have it’s place and problem to solve. It does. Development and maintenance for business solutions is however not part of the Maven problem space. More on that in another post.

In the specific case, the development team had lost a lot of time fiddling with OSGi dependencies, building and deploying bundles, keeping installations in sync, keeping version vectors straight and more technical aspects of solution assembly – none of which added value to the solution.