Mismanagement: The Weakest Link

We all know that a chain is only as strong as its weakest link. All too often leaders like to believe they are the most important link in their chain; it strokes their ego and justifies their compensation. Ironically that belief tends to make them the weakest link. A good leader works toward ensuring the strength of chain as a whole. They do not behave as if they are one tier above those they lead. They behave as simply another member of the team and set an example with their actions rather than with their words alone.

Behaving as if developers are equivalent to plumbers or assembly line workers is a really bad idea. In general, behaving as if the various different roles in the software development chain ought to be ranked from most important to least important, e.g., developers are more important than release engineers, is bound to weaken the chain. When was the last time goodness flowed from an Eclipse project without an associated release engineer, or someone acting like one, making it so? I've always believed in focusing on sound release engineering as the basic foundation upon which all other good things are built. When done well, it's a thankless job that's all too easily overlooked; when done poorly, it's a constant source of wasted time and energy for the entire food chain. Long live Eclipse's release engineers and thanks to the Eclipse foundation for their renewed focus on improving build infrastructure. It's a beautiful thing.


These days it's become clear that mismanagement is a bane of our collective existence. For example, I always thought CDO was an exceedingly cool project which graduated from EMFT to EMF during the last release, but yesterday I found out that CDO mismanagement is the cause of the world's financial crisis. Who would have thought that Eike would have so much influence? Just a little joke at Eike's expense!

All jokes aside though, how could such a complete and total financial disaster be allowed to unfold? Did none of our leaders foresee these possibilities? Of course some people saw this coming, but they were all too easily ignored by those whose vision was clouded by a veil of greed or wishful thinking. Systematic failure is the ultimate result of such mass myopia. I watch my father's struggle getting the mining industry to compute credible risk assessments in a context where hundreds of millions of investor dollars are often at risk for even a single project, yet the silence there too is deafening, which leaves my dad a little frosted.


I'm no economist, but watching all this unfold, I grow ever more doubtful about the actual prevalence of prevailing wisdom. Who decided, for example, that double digit growth is a goal that must be achieved at all costs? Is it actually a realistic goal? It's entirely clear that the risks taken by the few can ultimately become a burden to society has a whole. So as we take action to keep the financial house of cards (or stack of champagne glasses) from coming down, surely it's also time to identify the weak links in the chain. Perhaps many of the world's overpaid leaders' compensation should be scrutinized more closely. It doesn't seem totally unreasonable that one person might be compensated 100 times as much as another, but is 1000 times perhaps a little much? Do the CEOs of the world's large corporations really generate that much value? And most importantly, when they make huge mistakes, are their personal risks proportional? Watching investments evaporate certainly makes the rest of us blue.


Now that I've put the importance of good release engineering in proper perspective and have resolved the world's financial crisis with a witch hunt, I can prepare for my trip to Germany next week. I'll be visiting the itemis site in Lünen and then traveling to Elmshorn for MDSD. I hope I see some of you there. I'll have to check my camera chip's remaining capacity! Germany is so photogenic.

Be Careful What You Ask For

One of life's most important lessons is "Be careful what you ask for, because you might get it." As punishment for joining Kim in critiquing the lack of diversity and fashion sense of the orange-clad committer geek on the new home page, see 249371 for the sordid details, Kim and I are now the new improved cool committers. I'll capture the page here for posterity when the webmasters are done playing their jokes on us by making a mockery of Eclipse's hallowed home page:



I consider the use of my image as derivative work, but given that it's made available under Ed's Public License---they've definitely make the derivative work available in source form---my legal council has informed me that I have no legal recourse. Wassim, you can probably see me better than Russia now!

What's Old is New

Wow. Have a close look!


The Eclipse home page has a new and improved face!!

What Makes Java Objects Plain and Old?

Most people will tell you that Plain Old Java Objects, affectionately known as POJOs, are simply plain old goodness, similar to motherhood, when well planned, and apple pie, sans the hydrogenated lard laced with trans fat. When pressed to pin down what a POJO is though, you quickly realize it's a slippery fish. Mostly it is defined by describing what a POJO isn't. I.e., wikipedia defines it as follows:

... the term "POJO" is mainly used to denote a Java object which does not follow any of the (major) Java object models, conventions, or frameworks such as EJB.

You have to wonder why the "major" qualification is needed? It's okay to follow a "minor" Java object model? Perhaps the prevarication is to deal with this preceding statement:

A JavaBean is a POJO that is serializable, has a no-argument constructor, and allows access to properties using getter and setter methods.

Doesn't that contradict this "clarifying" statement in the definition:

All Java objects are POJOs, therefore ideally speaking a POJO is a Java object not bound by any restriction other than those forced by the Java Language Specification.

If everything is a POJO then non-POJOs clearly don't exist. After all, if a Java Bean is a POJO despite being required to comply to rules that are not forced by the language, e.g., a bean must be serializable and must have a no-arg constructor, then the boundary between plain oldness and the rest of the object universe is very ill defined indeed. Perhaps Java Beans are non-ideal POJOs. Does that make your brain feel as if it's about to burst like an overripe pumpkin?


Some people like to believe that they can sprinkle their POJOs with Java 5.0 annotations and still have POJOs, but BJ points out that this appears to be nonsense. He argues that although some annotations are okay, like @Override, other annotations that are part of a "major" Java object model, and are retained at runtime, are not okay. It's a reasonable argument.

Where does all this leave us? Unfortunately it leaves us in buzzword soup where the unwary are likely to be caught off guard. The important point that's become lost is that plain oldness is an aspect of the framework or context in which the objects are used, not an intrinsic property of objects themselves in isolation. Recall the statement that "all objects are POJOs." That's a recognition of the fact that there's nothing you can add to an object such that it's suddenly not a POJO. Similarly a pumpkin that's small and white, is still a pumpkin.


Consider that a framework that claims to support POJOs is claiming that it works for absolutely any Java object whatsoever without limitation. Conversely, if a framework requires something such that there exist objects it doesn't support, that framework doesn't support POJOs. By that reasoning, a framework that requires every instance to implement java.io.Serializable, for example, doesn't support POJOs. As such, a framework that requires Java Beans doesn't support POJOs, but that doesn't mean there's something wrong with Java Beans.

My reason for dwelling on this issue is frustration with "silly comments" that EMF objects aren't POJOs. Certainly EMF doesn't directly support POJOs (other than as data types) because modeled objects definitely are required to be EObjects. But any framework that claims to support POJOs yet doesn't support EMF's objects, because EMF objects aren't POJOs, is making deceptive claims. Most frameworks require something of the participants in order to be well-behaved players within that framework; from that perspective, most frameworks aren't POJO-based. For example, if you need objects that produce notification as they change, you need more than just POJOs. Generally I think most people need more than what POJO-based frameworks actually provide. While they will say they want something simple, like POJOs, what they ultimately end up actually needing is something rich and powerful. It's best to anticipate a client's ultimate needs rather than simply to pander to their stated needs.

Milestones

Milestones mark not only the progress of the development process at Eclipse, e.g., the passing of Milestone 2 and the delivery of Ganymede Service Release 1, but more generally the significant points in life's journey through time. On Sept 17th, my parents celebrated their 50th Wedding Anniversary.


That's a pretty amazing milestone that all too few people will ever achieve! I've noticed that time passes more quickly the older you get! I bought my parents a headset so that my mom can use skype on my Dad's computer to phone her sister in the Netherlands any time she wants. Her first call was to thank her sister for the flowers:


With the end of summer, sunsets are coming noticeably earlier every day. Colder temperatures threaten to put an end to the garden.


Eclipse project and components leads should take note that with the arrival of fall, their standard plans are almost due. Specifically they're due September 30th, a milestone that is all too rapidly approaching. No one is exempt. Has your friendly helpful PMC member reminded you of your community responsibilities to be involved in this open and transparent planning process? If not, consider this a reminder (and consider reminding your PMC members of their responsibilities as leaders at Eclipse). Don't be sad, it's really not much work; just copy from someone who has already done it!


A particularly happy milestone that's rapidly approaching for me is the end the writing for the EMF book's second edition. Frank has used some of his personal vacation time to help write an appendix to cover significant new things added for EMF 2.3 (generics) and 2.4 (improved support for REST). We're hoping the book will be available at a store near you before Christmas!

Make My Day

I flew out to Dallas today for the Eclipse Board meeting tomorrow.


We have some tough problems to solve, so we decided to tackle them the American way. We headed out as a group to look for the right tools for the right job.


Some of the folks where familiar with the equipment and headed straight for the back room.


The rest of us watched and instructional video, complete with a legal disclaimer, which Janet was kind enough to review for us.


Then we were ready to roll. Check out Chris' technique, taking note of the spent cartridge flying out. Like me, he succumbed to peer pressure.


Tracy literally had a blast!


And Emma, who was laughing maniacally on the way to the range, has us all a little worried. But she was quite the marksman! See the bullet hole? Unfortunately I had to crop the rest of the bullet ridden target for political correctness. Suffice to say she was like a one woman war on terror.


Although I was very skeptical about the whole gun thing, it was quite thrilling to load my Glock 17 and fire off a few rounds; maybe even a bit too thrilling!


Check out the accuracy! This is the first time I've ever fired a gun!!


I took the bullet ridden target back with me. I blew its head off too. That really made my day! Thanks Doug for helping ensure the gun didn't rip by finger open, Todd for arranging this fun outing, and Mike for reminding me not to point the gun at him. It was an accident, really!

You Gotta Have Friends!

As Bette Middler so eloquently sang "you gotta have friends, the feeling's oh so strong!" I'm reminded of this when I noticed today that Eclipse has more friends than a leap year has days. It's a great feeling to have so many friends!


Thanks to Darin for having helped get the ball rolling. Thanks to the foundation staff for helping set it up. Thanks to the web masters for ensuring that the download mirror selection page features this prominently. Thanks to Chris for trying to feature it on the Eclipse welcome screen. And of course, most of all, thanks to all our friends!