Retrospective: JPA Workshop /ch/open

Simon and I gave our JPA Workshop at the workshop days of /ch/open earlier this month.

Now the course feedback is online. I think generally we can be content, especially the comments are pleasant. The participants seemed to like our examples.

All the content (slides and examples) is available as project jpaworkshop on Kenai.

I am looking forward to repeating the workshop next year. By then the JPA2 implementations should be finished.

Note to myself - things to look into for the next time:

Using EclipseLink JPA Extensions for Entity Caching

Understanding EclipseLink Caching

Queries and the Cache

EclipseLink/Examples/JPA/Pagination -> still supporting only Oracle?

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

Abstraction, Encapsulation and social Darwinism (The Antipattern of Framework- vs. Business-Programmers)

Responsibility trap number one: Building a platform to make other (lesser) programmers more productive.

- Eric Evans at SET 2008

Hiding things from developers often requires more effort in the long run than simply trying to educate your developers as to how they should properly do their job.

- Educate Developers Instead Of Protecting Them by Davy Brion

Making development "safe" for lesser skilled developers by taking choices away from developers [...] does far more to hamper the efforts of your best developers than it does to make weaker developers more productive. I'll say that there is a silver bullet(s), it's: Skill. Knowledge. Experience. Passion. Discipline.

- Jeremy Miller

Again and again I come across projects, teams and companies that misuse the concepts of Abstraction and Encapsulation to establish a two class society among the developers.

In those setups you usually find on one side a framework-team that is responsible for a supposedly productivity-boosting, supposedly well crafted framework / platform / infrastructure. On the other side you find an army of business programmers that have to use the provided framework / platform / infrastructure to actually realize business value.

Usually the framework-team members think of themselves as the gurus, the elite, the "real" programmers, while the business programmers are considered as "lesser" foot soldiers.
These attitudes are mostly shared and therefore promoted by management. Indeed the framework-programmers often have the better education and/or more technical expertise.
If the situation is really bad then the framework team does not like to mingle with the business-programmers and the worst thing is, when they are not even co-located.

I heavily oppose this setup. It is an antipattern, that prevents team enabling. Agile, self-enabling, highly-motivated teams will never evolve in such a structured and divided team setup. This is not an environment where individuals are allowed to grow, this is an environment where employees are assigned! In such an environment, people just start to not care any more: framework-developers do not really care about business value, business-developers dont't feel like being able to make a difference...

As I don't believe in the factory analogy, I don't believe there is a situation where lesser developers have to be shielded/protected by a technical framework. The time to create a patronizing framework, would be better invested in teaching and exchanging knowledge.
In my experience, if a developer is not productive, then this is usually a management failure. Simple measures like assigning another task, changing the setup, pair programming, coaching, reviews etc. would usually improve the situation. I have seen projects where this has been achieved successfully, but in the above setup, this is usually not going to happen.
And in the rare case that you are really dealing with a net negative producing programmer (NNPP), no technological solution will save you... Abstraction and Encapsulation are pillars of object-oriented design. They are intellectual constructs to tackle complexity. They are technical tools and not a mechanism to legitimate team structure.

Using engineering techniques from object-oriented design to enforce team structure and separation feels just as wrong as applying Darwin's evolution theory to human societies.

Possible remedies and counter measures for the situation are:

Eat your own dogfood: Framework-developers have to use their own framework. They have to be involved in business-programming.

Empower the business developers: Establish an environment where it is absolutely clear, that the business developers are the ones that are providing value. The framework-team has the sole purpose to enable the business-developers.

Productize the framework: Nobody is forced to use the framework. The framework-programers have to actively sell their work, the business developers can freely decide if they want to use it. (According to a disscussion with Mark Striebeck, this philosophy is very successful at Google)

Collective ownership of the code, including the framework.

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

Geek and Geekess Humor

Geeks fantasies:

If browsers were women...

And here is the female reaction:

If your browser was a dude...

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

Illustrative Programming: I am a skeptic! (and I am not alone)

I have stated several times, that I don't believe in visual modeling and cannot share the enthusiasm that a certain branch of MDSD people have for visual modeling:

Visual modeling: Is it worth it? An example...

Musing about Code Generation, MDSD and DSLs

Now Martin Fowler is coining the Term "Illustrative Programming" in the context of Language Workbenches like IntentionalSoftware, which are tools to build "illustrative DSLs".

For a lot of people coming from the UML camp, the notion of a "DSL" is what Fowler is calling an "illustrative DSL" here. Visual Studio Domain-Specific Language Tools are a striking example of this.

In his article Martin Fowler quotes some opinions of Neal Ford about the concepts of Illustrative Programming:

I think these tools work best for lay people (thus, your link to LayProgrammers). However, in general, tools like this slow down experienced/power users. [...] I would much prefer a markup language I could use to directly define stuff, with macros, snippets, and all the other things I'm accustomed to as a developer.

As these tools grow, they get unwieldy (perhaps because they are ceasing to be domain specific enough?). [...] APIs in programming languages scale much better, with several orders of magnitude more density before they become hard to navigate.

All the best-practices and tools don't exist there: refactoring, levels of testing, etc. Also, you loose the connection to text, meaning that macro facilities either don't exist or complex one-offs. [...]

I share your bullishness around these types of tools, but they are a long time from being useful for full-bore Agile development. I hope they mature fast.

Reading these comments, I am having a deja-vu!

This is really expressing what I was feeling when I was involved in MDSD attempts in recent projects. I don't generally doubt the noble goals that the visual modeling camp believe in.

But the tools and environment are just not ready to provide value. At least not in that kind of mainstream real world enterprise projects I have been involved in.

Also in my experience, the target of illustrative programming is the developers, which is wrong!

As Fowler is pointing out, the goal of illustrative programming is to engage lay-programmers.
Developers need other tools than lay-programmers! So if there are no lay-programmers in your project, there is arguably need for illustrative programming...

This insight was always lacking when I was confronted with attempts at visual modeling.

It is a common mistake in a lot of projects to establish some kind of two-class society among the developers, in this case it could be tempting to degrade the second class to lay-programmers. But that is a sick environment to begin with (and the topic for another post)...

of cource you should follow me on twitter

Quick Tip: Additional File Types for OS X Quick Look

As I am diving into cucumber, I would like OS X Quick Look to display my .feature files.

(and while I was already at it, I also enabled Quick Look for .properties and .textile files)

This is what I did:

I navigated into the TextMate package (right-click->Show Package Contents).

I edited Contents/Info.plist with a text-editor.

I added the follwing snippet at the end of Info.plist (just before the ending </dict> </plist>)

<!-- inserted jb, 20090920 for QuickLook improvement -->  
<key>UTExportedTypeDeclarations</key>  
 <array>  
   <dict>  
     <key>UTTypeConformsTo</key>  
     <array>  
       <string>public.text</string>  
        <string>public.plain-text</string>  
     </array>  
     <key>UTTypeDescription</key>  
     <string>Code</string>  
     <key>UTTypeIdentifier</key>  
     <string>com.macromates.textmate</string>  
     <key>UTTypeTagSpecification</key>  
     <dict>  
       <key>com.apple.ostype</key>  
       <string>TEXT</string>  
       <key>public.filename-extension</key>  
       <array>  
         <string>properties</string>  
         <string>textile</string>  
         <string>feature</string>
       </array>  
     </dict>  
   </dict>  
 </array>

Then I set TextMate as the default editor for .feature files.

Finally I nudged the system o tell it something has changed with touch /Applications/TextMate.app and qlmanage -r on the commandline.

The result:

Need a break - care for a flame-war?

If this is another of those days, getting bogged in the trenches of enterprise IT, here might be your entertaining break:

There is an exceptional flame-war going on between Alex Yakunin of ORMBattle.net and Ayende!

Some of the skirmishes are listed here:

The beginning: ORM Battle.net: The ORM Tool Shootout

The main battle lead by Ayende: Benchmarks are useless, yes, again (check out the comments ...)

Ayende: Benchmark cheating, a how to

Alex: Are results of this test suite really important? Part 1. Why I don't believe Oren Eini.

Ayende: How to lose respect and annoy people

And if this is not enough, check out this flame-war of Bob Lee and Gavin King: Comments on "Annotations for Dependency Injection"

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

The passionate developer: I do like my profession, I don't like my job

Update 2009-09-14: There are interesting discussions of this post on hackernews. Thanks!

To only a fraction of the human race does God give the privilege of earning one’s bread doing what one would have gladly pursued free, for passion. I am very thankful.

The Mythical Man Month, p. 291

Architects, designers, and developers of corporate systems usually have little or no voice in what gets built, or how, or why. They don't sign on, they get assigned. I know that individual developers do care passionately about their work, but usually have no way to really make a difference

Why Do Enterprise Applications Suck?

I consider myself an alpha-geek. I think I have met quite some other alpha-geeks.

I tend to think that there is hardly any other group of professionals that care so much for their profession like alpha-geeks.

Regarding passion, dedication and motivation alpha-geeks are very similar to artists or master craftsmen.

Alpha-geeks usually don't (want to) make a difference between their job and their hobby:
"Tenet of professionalism: Work 40 hours for your employer and another 20 hours improving yourself." (tweet by unclebobmartin)

... at least that would be the case in an ideal world ...

In reality I have almost never met a passionate developer, that is really happy with his job.

In reality it's more likely that the alpha-geek is working the additional 20 hours, because he is frustrated with the 40 hours he had to spend for his employer... because he could not realize his ideas of real development, because he was bogged down with fabricated complexity, because he lost his way in a maze of legacy code and because he had to spend so much time and energy for bureaucratic overhead ...

This is a schizophrenic situation, and I wonder why it is so common?

Probably a lot can be credited to the Office Space clichés that can be found in corporate environments. And to the fact, that in a lot of those environments it's impossible to deliver software that matters.

But I think it's too easy to lay all the blame on corporate environments.


I think a part of this schizophrenic situation can be credited to a blame-the-others-syndrome. If things are hard and if there is friction, it's always easier to blame the others. It's only self-protection to assume the stance "If I only could do things my way, everything would be good!"

I also think software development is especially susceptible to this schizophrenia, because nowadays it almost exclusively deals with intellectual constructs. It is very easy to create a clean, wonderful notion of a perfect software system and to imagine an ideal software development process. That's because we can let our imagination run wild, since there are no real constraints in theory. At least in theory there always exists a perfect solution. That's a major difference to other (real) engineering disciplines.
It's very convenient to think that we could realize the perfect solution, if only we could do things our way...
...only in our perfect solutions we did not consider those accidental constraints like people, time, economic factors ...


A third aspect is that there are hardly any measurable characteristics in software development. Therefore personal taste, preferences and gut feelings become important. And since these are very individual, it's a logical consequence that we always have to deal with compromises when we are working with other people.


I believe that leveraging the passion and motivation of developers is a key factor for forming highly productive teams. This has been shown with different studies.
But to a certain degree this is a blade with two edges. Highly passionate developers are much more susceptible to the schizophrenia mentioned above. I think the key is to accept, that real-world software development is never perfect. Our job is it to pragmatically live with this imperfection.

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

Software development: It's all about trust ...

Software development is a lot about trust.

But It is hard to trust someone, if you really do not understand what he is doing. It's even harder if you suspect that he does not understand what you want!

This is a major problem in enterprise software projects:

The software creation has become a very complex and intricate undertaking that requires a lot of specialized knowledge.

Since enterprise software development is inherently dealing with change, it is almost impossible to know what a solution is going to look like.

Enterprise software development is still a very young discipline that has grown unreasonably fast and that is still very much in flux. It is almost impossible to rely on experience or best practices.

In traditional enterprise software projects we create a lot of management overhead to deal with this situation: complicated contracts are created, detailed project plans are conjured out of thin air, budget arrangements are negotiated, unrealistic progress estimates are enforced, change-requests are fervently tracked ...

All those activities could be considered as engineering activities. But software development is turning out to be less and less an engineering discipline:

Tom DeMarco: Software engineering: An Idea Whose Time Has Come and Gone?

Joel Solsky: How Hard Could It Be?: The Unproven Path

Thinking about it, all this overhead is mostly about establishing trust. If the trust is not there, its about safeguarding and establishing a position to lay the blame on someone else.

Obviously the above situation is hardly satisfying for anybody (except maybe the lawyers). Lots of efforts and resources are wasted. It's hard to focus on what should be everybody's goal: creating meaningful software.

There are different recent trends in software industry that try to tackle the issue:

Agile software development tries to tackle this problem with practices like iterative development, integrating stakeholders and by embracing change with frequent inspection and adoption.

Domain Driven Design (DDD) promotes the creation of an Ubiquitous Language and its realization in a domain model that reflects the business concepts in the implementation. The goal is to minimize translation between the domain language spoken by the business and the technical language the code is written in.

Behavior Driven Development (BDD) promises to be a tool and methodology that fits perfectly for Agile software development and DDD in that it can support the creation of trust by shifting the focus of developers from implementation details to business value.

Scott Bellware has some interesting quotes about this topic in episode 42 of Herding Code: Scott Bellware on BDD and Lean Development:

[In BDD] what we try to do as programmers, is try to justify our worth by trying to communicate how much we know.

The most value we have to business people is to stifle it everytime when we want to start talking about implementation details.

The greatest confidence we can give to business people, is to let them know that we understand the business imperatives, that we understand what is at stake and that we are going to be committed to getting the problem solved. Starting to talk about implementation details is not gonna do it.

We should commit to actually being business people. Its high time that we let go of the mystique of geek culture.

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