Saturday, May 31, 2008

ODA Ecore Driver Backport

This post is a continuation of the description of the ODA Ecore Enablement plug-ins, now available for download from the Eclipse datatools incubator.
Recently, the ODA Ecore plug-ins were backported for JDK 1.4 and Eclipse 3.2 compatibility. This project has been moved into the datatools incubator attic directory. The same functionality is there in both sets of plug-ins, but there is no guarantee of future support for the archived version.
The primary difference between the Europa version and the backport is the backport's use of the now-deprecated org.eclipse.emf.ocl API for running ocl queries that has since been replaced by a new org.eclipse.ocl query parser. The backport does work in Europa, but the newer, EMF 2.3-dependent version of the plug-in allows shorter, context-free ocl query syntax.

Set up the ODA Ecore Driver in Eclipse 3.2

Download Eclipse 3.2 Callisto and unzip it.
Download EMF 2.2 and unzip it into your Callisto directory.
Download the EMF 2.2 examples and unzip them into your Callisto directory if you want to try the example described in the ODA Ecore Getting Started Guide.
Download EMFT Validation 1.0.1 and unzip it into your Callisto directory.
Download EMFT Transaction 1.0.2 and unzip it into your Callisto directory.
Download EMFT OCL 1.0.1 and unzip it into your Callisto directory.
Download EMFT Query 1.0.1 and unzip it into your Callisto directory.

After starting this installation of Eclipse 3.2, install the following plug-ins from the Callisto discovery site:
Database Development -> Datatools Platform Enablement 0.9 and its dependencies
Charting and Reporting -> Eclipse BIRT Report Designer Framework 2.1 and its dependencies (to run the example described in the ODA Ecore Getting Started Guide).

Import The Archived ODA Ecore Driver projects from CVS.
The Host is
The Repository path is /cvsroot/datatools
Browse to org.eclipse.datatools.incubator/attic, select
  • org.eclipse.datatools.enablement.oda.ecore
  • org.eclipse.datatools.enablement.oda.ecore.ui
and check the projects out to your workspace.

Because the plug-ins are JDK 1.4 compatible, if you have a later version of the JDK, you might want to set your Java Compiler Preference to 1.4 Compliance to eliminate any compiler warnings.
Everything should be set-up correctly, and you should now see no compiler errors.

Try the ODA Ecore driver extlibrary Example

We can now launch a new Eclipse runtime and set up an initial BIRT report and .extlibrary file in our workspace as described in the example from the ODA Ecore Getting Started Guide.
Data source creation is the same, so we can follow the instructions without changes.
Data Set creation is slightly different because the query syntax for the backport is more strict. The boolean query in the example, self.oclIsKindOf(Writer), will work for the backport. The differences show up with more complex queries.
Suppose we want to find only references to James Fenimore Cooper. While we can use = 'James Fenimore Cooper' in the latest version of the plug-in, this query will not work in the backport. The query must read self.oclIsKindOf(Writer) and self.oclAsType(Writer).name = 'James Fenimore Cooper'. The newer org.eclipse.ocl query parser can handle the stricter old-style query, but the older org.eclipse.emf.ocl parser cannot properly interpret the shorter context-free query.
Aside from that slight difference in query syntax, the plug-ins currently have the same features. So if you have the restriction that you must continue using Eclipse 3.2 or Java 1.4 and cannot upgrade to Eclipse 3.3 or EMF 2.3, but you need the features exposed by the ODA Ecore driver, you have this backport as an option!

Sustainable Pace

Often the term sustainable pace implies working long hours over the course of a few weeks. On projects that have long release cycles (anywhere from three months to three or more years), discussions of sustainable pace crop up as deadlines approach and as teams work long hours and weekends to fit in all the features scheduled for the release. XP and other Agile processes recommend short release cycles, continuous code merge and continuous integration to establish a regular rhythm for a development team and automated test driven development to reduce the number of bugs in production code (and the after-hours fire-fighting that often accompanies production bug fixes).
I propose that there are (at least) three types of regular project rhythms for individuals, teams and development organizations, and there are corresponding forms of unsustainable pace that accompany each rhythm.

Day to Day Development

For an individual, the day to day rhythm of development may include rituals such as getting a morning coffee, reading /. before work, eating lunch, and any regular team-related events. For a team, daily rituals may include a morning stand-up, switching between driving and navigating when pair programming, or switching pairing partners every few hours. Disturbances to a normal pace might include a dentist appointment, illness, oversleeping. These occurrences rarely harm a project because they tend to be infrequent. More insidious are consistent distractions that become an irregular part of the regular day-to-day pace. For example, in a non-pairing environment, there are often a few members of a team who are in charge of code quality control, who are domain experts, or who have specific technical expertise, and these superstars face constant interruption from other team members asking questions or needing code reviews. This type of interruption drives down the productivity of the individual, but can improve the team through the spread of knowledge. One benefit of pairing is that this type of knowledge transfer and the constant review of code quality becomes a standard part of the day-to-day pace, instead of an interruption.
Any form of active notifications, such as instant messages or Outlook and Mylyn popups provide more intrusions. Open web browsers with unread articles of interest are a more passive distraction. Given enough open browser tabs, a developer will certainly notice a decrease in performance of other applications, such as development environments. Also, programmers will often justify reading technical articles on the job as a form of continuing education, even if the article is not related to the current project, or they will justify reading an article by saying that they will make up the time by working later or by working from home to finish the task that they should be working on. This line of thought is particularly dangerous and directly contributes to what is often called unsustainable pace. When developers bring laptops home to work on stories that should have been completed during the day, that is a sign of unsustainable pace. When developers start thinking that they can put personal, non-work related programs or other distractions on their laptops, that practice can lead to a decrease in productivity and to unsustainable pace. Maintaining good pace is not just a matter of estimating tasks in manageable chunks or of sitting at a desk for no more than eight hours per day. It is a matter of having the discipline on an individual and on a team level to minimize distractions that can lead to incomplete work and to long days.

Sprint to Sprint Development

For a team, the rhythm of inter- and intra-sprint development may include rituals such as release and iteration planning, retrospectives, or weekly drops of code into production. Intermittent disruptions to this pace might include temporary (vacation) or permanent (termination, death, quitting) loss of team members. Such disruptions will affect team velocity but should not affect the occurrence of rituals. One form of sprint to sprint unsustainable pace comes from the repeated disruption of sprint rhythms and the cancellation or postponement of rituals. For example, when teams over-commit to a group of stories or set stretch goals, often the pressure to finish billable work will cause individuals to question the time spent on retrospectives or daily standups, which do not directly generate revenue. Consistently falling short on point commmitments undermines the morale of a team, which is another form of unsustainability; it leads to unsatisfied product owners; and the rolling-over of committed stories or the unfinished work from one sprint to the next may result in the pushing-back of sprint deadlines. Stretching a sprint from two weeks to three because commitments were not met treats the symptom and not the cause, i.e., that past velocity should dictate point commitments and not that committing to an artificial stretch goal will inspire a team to work harder. Repeated sprint extension degrades the meaning of sprint boundaries and reduces the satisfaction of knowing that a sprint is really complete.

Project to Project Development

For an organization, the rhythm of project to project transitions may include rituals such as kick-offs, code hand-offs, post-mortems. Teams may fragment or may move in toto from one assignment to the next. The smooth transition of individuals and teams is especially difficult because it often entails accurately predicting the end of one project, while the beginning of another often depends on the timelines or budget deadlines or product launches that need to be coordinated with another team in the same or a different organization. Often, when one project runs past its expected end-date, the transition period is especially difficult because over-allocated individuals may be put in the position of working 60-hour weeks to meet commitments to multiple projects. One individual split between two teams can also cause disruptions in sprint rituals because of scheduling conflicts and because of unavailability for consistent pairing on both teams. A long overlap between projects is certainly unsustainable.
The immediate dove-tailing of individuals from one project to the next, even despite some over-allocation, is a healthy sign. Inconsistent transitions with breaks of weeks between revenue-generating work, however, is unhealthy. The persistent lack of proper coordination of an individual's time can lead to a very insidious form of company-wide unsustainable pace. One particular example of this would be the feast-or-famine professional services company. New project work comes in waves. As a new wave arrives, there is a rush in one department to hire new developers with a specific skill set, rather than to double-up some developers temporarily or to transition developers from a starving part of the organization and re-train them. Self-organizing teams sometimes fail to see the bigger, company-wide picture and are only focused on the immediate success of individual projects. As the wave subsides, the sales pipeline looks sparse, so some developers are let go instead of transitioned onto established teams temporarily to help out, put on internal projects, or put into other roles (e.g., writing RFPs, going on sales calls) that have the potential to generate revenue. This cycle of hiring and laying-off is incredibly wasteful. The hiring process and the acclimation of any new employee to a company's culture and processes is very expensive. The lay-off process, as well, is expensive, and any number of lay-offs in a company for non-performance reasons erodes morale by generating fear, uncertainty and doubt, not necessarily about the quality of what is produced by the company, but about the position of the company in the marketplace.

The term sustainable pace means more than just 40-hour work weeks. Maintaining a company-wide sustainable pace may require interruptions to the normal rhythms of day to day or sprint to sprint development. It may require individuals to work long days or weeks for some period of time. It may require that individuals leave their comfort zone by stepping into other roles and being re-trained. Mostly sustainable pace means knowing when to be flexible and when to rigidly follow ritual.