The Object Teams Blog

Adding team spirit to your objects.

Retrospective of an Old Man (2)

leave a comment »

(continued from here).

Today I want to speak about four engineers who have influenced Eclipse JDT in the past: Srikanth, Markus Keller, Till Brychcy and Yours Truly. All of them have left the team over the course of the years. None has left because they didn’t love Eclipse. It would come closer to the truth to say, they left because they loved Eclipse too much. I am not authorized to publicly speak about the personal motives of these people. For that reason I will generalize as if all four situations were identical. Obviously this isn’t true, but still I sense a common gist, some overarching topics that might still be relevant today.

What is said below is meant as observations about these four engineers only. Whatever quality I ascribe to them, may well be shared by others not mentioned here. It’s not about drawing boundaries, but about perceived commonality.


Every healthy community has members with a very focused area of expertise, in which their knowledge is thorough and deep. Other members may have a wide range of interest and involvement, connecting the dots between different focus areas. Some members excel by way of sharp analytical capabilities, others contribute the experience from years of working on a component. The personae in this story drew their strength from combining (at different degrees) all four qualifications: knowledge both deep and wide, understanding both analytically sharp and founded on a body of experience.


While every contributor takes responsibility for their contribution, some people feel responsible for an entire component or even product. In this text I don’t speak of responsibility from a managerial perspective, but of a code-centric point of view that cares about the code in all aspects of quality.

In one of the most complex endeavors that I got involved in, one of our four engineers mentioned in retrospect: “failure was not an option“. Feeling responsible for a component implies to closely track the bugzilla inbox, and to make sure that every incoming bug report is handled with due attention. It also implies to make sure that every proposed code change is of highest possible quality, not only in terms of functionality but also as being in harmony with existing design, to prevent architectural decay. Such responsibility finally implies to care about completeness of functionality. In particular when a new Java version changes the game, JDT must support users in working in that new environment. As an example for the latter aspect think of the conflict between unit testing and the Java Platform Module System. In this context, treating test sources differently from main sources is a must, which is why Till added this functionality to JDT (a huge project of its own).


Working with the attitude described above requires a lot of energy. In a healthy community this energy flows in both directions, and everything may well be sustainable. In the cases of our four engineers, however, too much energy was burned, obstacles appeared and caused frustration. Some may get frustrated when they see code changes that are made with insufficient understanding, unaware of maintenance costs incurred. Sometimes it’s the tone of discussion that kills any pleasure of contributing. There’s also a structural conflict between meritocracy and unlimited openness of a community: Think of our engineer who wants to take responsibility, he will have to make some decisions. He feels that the rules of meritocracy grant him permission to make such decision and furthermore he is convinced that such decision is necessary to fulfill the assumed responsibility. If the community doesn’t accept such decisions, our engineer would have to fight an extra (seemingly unnecessary) battle just to get permissions for enacting a decision he deems necessary for the greater goal.

In all four cases the community failed to balance the flow of energy, to get obstacles out of the way, to empower those who feel responsible to enact that responsibility. Not all four experienced a full-blown burn-out, but that’s more a question of whether or not they pulled the plug in good time.

Two of our engineers actually had to quit their job to leave Eclipse, the other two didn’t have to ask anybody, because they never received a penny for their contributions.


Is it just normal that engineers risk burn-out? Is it something happening to everybody? Is it acceptable? Does it make a difference to the community who is it who gets frustrated? More generally speaking: is the community willing to make any difference between newbies and potential “meritocrats”? Does the community actually support the goal of excellent code quality, or is speed of change, e.g., considered more important?

In my previous post I spoke of the end of an era. Does the new era have use for engineers like these? It may not be an extinct species, but I’m afraid their number is dwindling…


No, in this post I’m not begging for any “presents” that would lure me back into my previous position. I had my share of responsibility. Quite likely I had bitten off more then I could possibly chew, when I felt responsible not only for all of the compiler (ecj) per-se, but also to drive Oracle towards improving JLS in ways that would enable the teams behind ecj and javac to finally converge on the same language. I felt responsible at other levels, too, but I will not enumerate my merits. I made a final decision to shed all this responsibility – in good time before it would affect my health.

Written by Stephan Herrmann

June 23, 2021 at 10:44

Posted in Eclipse

Tagged with

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: