Up at 5AM: The 5AM Solutions Blog

Lately we've had some internal discussions about training and certification. As part of those conversations, we recognized that we are generally certification light, and decided to get direct experience on the exams themselves to use as input to our discussions. To that end, I took (and passed the SCJP) exam last week. Here's my experience.

Some background: I have been programming in Java for over 13 years - since JDK 1.0.2 (warning - time warp). I've used every version of the language, up to and including 1.6. While I don't write code daily anymore, I still spend time coding and consider myself up to date as a programmer. Over these 13 years, I have peaked into the corners of the language from time to time and have read the JLS, books on the VM implementation, and managed to get most (though certainly not all) of the Java Puzzlers. But I never bothered with certification for myself and didn't give much weight to SCJP on a resume.

My prep was pretty minimal. I took two practice exams from Sun one evening to get used to the format and identify trouble areas. I brushed up on the couple areas I fell down on and signed up for an exam the next week. The exam at the test center had some fill-in-the-blank type questions that weren't on the practice tests, but otherwise the material was pretty similar. You learn your exact percentage score and a pass/fail evaluation immediately after clicking the final submit button.

I've got mixed feelings about this exam, and its value as a certification. On the positive side, the exam certainly establishes a credible entry-level bar for Java knowledge. I don't think it'd be possible for a junior developer to pass without having actually used the language for non-toy projects and put in some significant exam prep. I also think the exam will be a bit easier for those with firm CS grounding, rather than coders that learn just enough to solve the immediate problem at hand. (My personal bias is towards those with a CS background, because I think it's easier to learn coding than CS on the job.) This is also a required exam for the other, higher-level Java certifications (which I've yet to take but seem decent.)

The exam topics are a mixed bag to me. Some of the API content is either highly specialized (I hadn't heard of NavigableMap) or the type of stuff most people's IDE (or the online javadoc) gives them. The threading questions were low in level and (in the interest of small code size) often did decidedly odd things to test knowledge about concurrency. Such topics mean that exam-specific study is required and some topics are unlikely to be encountered by developers on a daily or weekly basis.

I have two major objections to the exam. First, there is a ton of what I'll call "are you a compiler?" questions. Many questions are of the form: does the above code (a) not compile do to error at line x, (b) run, but give runtime exception at y, or (c) give output z. Who cares? We have compilers for a reason, and modern IDEs are extremely helpful to the neophyte and seasoned veteran alike. I agree that it's important, for instance, to know that you cannot decrease the visibility of an overridden method in a subclass, but any attempt to do so will cost a developer what, 5 minutes? And finding that error, among other gotchas on question after question is very aggravating. My second objection is that, in order to test specific language features, the example code is full of antipatterns and bad style. Tools like checkstyle and pmd would light up at the code in the exam, pointing out all sorts of problems. As an experienced developer I found it frustrating to have to manually sort that stuff out, and I wouldn't expect a less experienced person to need that knowledge to start coding on any of our teams.

In my previous post I gave two examples of leaky abstractions. In this post I want to talk about what makes leaky abstractions likely to occur. This will require a perhaps unlikely detour to a laundromat.

First consider what abstraction is. In the general sense of the word, Wikipedia defines it as "the process or result of generalization by reducing the information content of a concept or an observable phenomenon". So we start with some concrete item or idea, and then divide its properties into two categories - ones that are important and ones that are incidental. We discard the latter, and we declare the former as the abstraction. Our original concrete concept or idea is one example that fits the abstraction, but hopefully there are others (otherwise the abstraction would not be very useful).

One place where this process can go wrong is the choice of which properties are to be included in the abstraction, and which are incidental. The subtlety is that this choice depends on the context in which the abstraction is to be used. For example, consider clothing. In the context of placement within a store, the important aspects are type (shirt, pants, etc), and perhaps the designer - we have a section for jeans, or a section for Levi's - and we can abstract away other details. However, in the context of doing laundry, the important aspects are color and material, and the others can be ignored.

To bring this back to the realm of software architecture, take the distributed object paradigm. Here, the important aspects of an object are declared to be its fields and method signatures. How fast the methods execute is an implementation detail that has been abstracted. As a result, one can indeed reason about the correctness of a program using distributed objects without breaking the abstraction - e.g. without caring whether a given object instance is local or remote. However, it turns out that in the real world performance is as important as correctness to whether a program is useful - and here the abstraction breaks down, and the difference between local and remote objects is quite large indeed.

The choice of context is fundamental. As Joel Spolsky and Jeff Atwood point out, all abstractions are leaky to some extent. The important thing is, on the part of the abstraction creators, clearly defining the context within which the abstraction can be expected to hold, and on the part of the abstraction consumer, not using it outside of that context. The irony in software is that you can, in principle, reuse any component for a purpose completely unanticipated by its creator; in reality, this makes meaningful reuse harder. In other engineering disciplines, the set of feasible uses for a component tends to be much more circumscribed, and therefore, within those tight boundaries, more reliable.

So how can reuse be controlled in software? In the end it comes down to explicitly documenting the assumptions and preconditions under which the abstraction is expected to be valid. A good framework for doing so are the architectural quality attributes of the ATAM framework. Using patterns helps as well, since they carry shared understanding of how an abstraction will behave.

Over the past 1.5 years, a project we have developed has been required to utilize the ISO 21090 Healthcare Datatype specification. This requirement has been challenging for our team and our partners throughout the project lifecycle. However, I didn't spend much time thinking about root causes for these problems because the requirement was non-negotiable. That changed when I read Adam Bosworth's Healthcare XML standards post a couple weeks ago. His points about good standards provided the structure to talk about our 21090 challenges.

Keep the standard as simple as possible. This is a major criticism of 21090. Casual observation and our experience with this standard shows that it is not simple. As two examples, consider that the BL (Boolean) datatype has no fewer than 8 attributes, and that address (AD) takes 11 pages to detail such things as "delivery installation type" and ideographic address use. Still, is it as simple as possible? I don't know. The USPS address standard is some 200+ pages long, and doesn't consider international addresses. But I've yet to see a more elaborate logical (boolean) datatype in any language or specificaiton. I think this is because....

Keep standards focused. There is poor separation of concerns in 21090. When I send a BL, I can communicate not only the truth value, but whether this BL is a change from the previous value or the start and end times for which the value will be valid. I believe that such considerations should not be part of a datatype, and instead should be explicit fields of a containing class. Another example is telephone numbers, where the spec includes not only how to encode a number ("+12125551212") , but how that number should be used (mobile, home, pager, etc.) and time information (use this number only between 8-5pm). Address is particularly bad. The standard is so unfocused that its own examples appear completely different from each other.

Percise encoding. 21090 is fine in this regard. There is little like an HL7 2.x Z segment to be found.

Real implementations. Note that 21090 is in the ISO "Approval stage" today. During most of our implementation period, relevant google searches' top hits were our team's wiki pages. No one had implemented these datatypes before – our team's questions were generally escalated to the author of the specification, because no community expertise existed. Even the downloaded XSD was invalid syntactically. This particular standard evolved from other datatype standards that are in more widespread use, but there is still a need to vet the standard via a real end-to-end implementation. Even today, top hits for 21090 are teams asking questions about how the spec might work, rather than discussion about how it is or is not working.

Free, publicly available spec with examples. Nope. Costs money to buy.

While I think there's a lot of good in standardizing datatypes, I think the above discussion should give pause to others considering the value of adopting this particular specification as an enterprise standard.

• Meaningful Use of electronic health record technology. The government is still working on its definition of meaningful use, which it will distribute at the end of the year. Many clinicians, care providers, and organizations are angling for a way to get in front of this definition so they can qualify for this designation (and attendant financial benefits), when it’s defined. I’m not going to spend time discussing the issue here (see this for more info), except to say that Chopra indicated that parts of it are staring to lean toward outcome-based definitions, rather that a checklist of compliance items, which is refreshing (although outcomes are a lot harder to define than checklist items, so this should be an interesting story to follow).

• Standards. Chopra is chair of a newly-formed standards implementation group of the Health IT Standards Committee, so this issue is critical to him. He cites support of open standards, and is in the middle of a two-week period in which he’s actively seeking comments, inputs, and suggestions on what the committee should recommend regarding standards. Read it in his own words. As someone who has had to endure the hard work of standards adoption, I appreciate the freedom a term like “open standards” implies, but having achieved the benefits of the hard work of standards adoption, I also view such a term with skepticism and cynicism, because even though they're hard, standards work. I don’t want the government to shy away from defining standards for health information exchange. I don’t want us to wind up with a thousand silos that can’t communicate, enduring the expense and pain of n-factorial translation efforts. My fear is that “open” will lead to “tower of babel,” and I intend to comment and encourage others to as well.

• NHIN (Nationwide Health Information Network). Since I’m working for the NHIN, I was very interested in what Chopra would have to say about it, and what the knowledge and reaction of the audience would be. The NHIN, which is a set of standards, protocols, and policies to allow the secure exchange of health information, is going live in January 2010, with government agencies such as the Social Security Administration, CDC, and the VA exchanging information with regional health information exchange organizations (aggregators of health provider data in states or regions), and delivery providers like Kaiser Permanente. The idea behind the NHIN is that Entity A can query the network about Patient Y, and receive information on that patient from those who have information. (Conceptually it supports the “let’s use the NHIN to see if anyone knows whether this unconscious patient in my ER is allergic to penicillin” scenario.) Chopra’s already envisioning the next version of the NHIN, which he describes as providing a full set of tools to allow individual doctor’s offices and patients using personally controlled health records (PCHRs) to participate. Having worked to get the “current” NHIN out into use, I welcome this expanded vision and look forward to the day when I can grab my lab results using my iPhone (might as well dream big...).

Since he was talking to interested innovators in the health IT space, Chopra laid out a world of opportunity that we can collectively create, where jobs are created (squads of geeks setting up EHR systems in doctor’s offices, systems and people to support online/automated follow-up care between hospitals and their patients), where competition drives new ideas, and where we all benefit from effective, efficient, technology-supported health care. He’s got an inspiring vision, an abundance mentality, and the means to inspire, drive, and support us as we start down the path. At founders of a company in business to see this vision achieved, Brent and I were happy for the reminder that with powerful leaders like Chopra, collaboration, creativity, and collective energy, we could actually get there.