~pperalta

In his ORM session today, Scott Ambler talked about the impedance mismatch between databases and objects. The technical mismatch is a well known and studied issue. However, he spent quite a bit of time discussing the mismatch between the object and database communities. In particular he addressed the manner in which data people work, which is usually BDUF as opposed to the evolutionary iterative approach that is preferred by object people. As the author of Agile Database Techniques and Refactoring Databases, it is not hard to tell which position Scott takes. However, he does acknowledge that traditional data/DBA types have knowledge and experience that is vital to effective high performance databases. These are skills that OO developers don’t necessarily have. At the same time, data people tend to only view data on its own instead of how it will be used in a real world OO system. He argues that both communities need to work together and to learn a bit about the other’s discipline in order to develop the best applications possible.

He goes on to describe basic ORM techniques, such as how to map inheritance, associations, collections, and so on. The content of the presentation is available on the Agile Data web site.

In the first talk that I attended today, Uncle Bob makes a convincing argument that time constraints are not an excuse for sloppy coding. His claim is that bad code has a “more profound and long-term degrading effect” than anything else, including bad schedules, requirements, and even team dynamics. He states that coding clean will actually speed up development, especially when you have to go back and make changes. The code sample that he presented was a condensed version of this article that he wrote about a command line argument parser. He starts out by writing code to parse boolean arguments, but his initial design ends up not scaling very well when he adds processing of integer and string arguments. We saw lots of if/then/else statements that were doing type checking. When you see this in an OO language, that’s a good sign that an object hierarchy is in order. The slides show him adding a hierarchy to replace the if/then/else statements with polymorphism, along with some other code cleanup. Here are some tips that he passed along:

• Write code (and tests) in tiny increments.
• Functions should be small. He asked the audience how big a method should be, and an audience member suggested that it should fit within your screen. That would have been my answer as well, but he pointed out that screens are so large (and high res) today that this old rule of thumb doesn’t apply anymore. The limit should be about 20 lines or so.
• A method name should describe exactly what the method does. If you have to browse to the method to figure out what it’s doing, that may be a bad sign.
• Use the Command Query Separation principle. Methods that return a value should not change state, and methods that return void should be used for changing state.

Both in this talk and the Compleat Agile developer, he talks about the allure and dangers of complete rewrites as a remedy for ugly code bases. This is a topic that I have read about before from Joel. In addition to all of the reasons that Joel gives, Uncle Bob provides another one. He has seen elite groups formed in many places to rewrite software only to discover that they cannot keep up with the legacy systems that are still being maintained. Eventually the new system becomes just as much of a mess as the old system. The team tasked with the redesign starts to loose members. Before long, developers are demanding that the new system be redesigned yet again!

Ken Pugh of Pugh-Killeen Associates presented guidelines for creating interfaces:

• An interface implementation shall do what its method says it does. This principle was also mentioned in the clean code talk.
• An interface implementation shall do no harm. This means no nasty side effects, such as memory leaks, etc.
• If an implementation is unable to perform its responsibilities, it shall notify its caller and report an error in the user’s terms, not the implementation terms. This one is important because many times methods will throw internal exceptions that the caller has no idea what to do with.

Tomorrow I’ll get to see Scott Ambler talk about ORM.

Today is a brisk fall day here in Boston where the SD East Best Practices conference is getting started. The first day consists of half day tutorials, one before lunch and one after.

The morning tutorial that I attended was presented by Luke Hohmann of Enthiosys. The topic was “Innovation Games: Creating Breakthrough Products Through Collaborative Play.” The focus of this talk was strategies that can be used to solicit customer input and how to process this data to turn it into innovative products. The techniques consist of games that can be played with small groups of customers in order to understand their wants, needs, and priorities. They have an entire catalogue of games that can be used for various purposes and audiences. During this presentation he went through three of them: Speedboat, Buy A Feature, and Spider Web. The game that I found the most interesting was Buy A Feature. Each customer is given a certain amount of play money and a list of features along with their cost. The customers then get together and decide which features they would like to “buy.” Sometimes features are expensive and a single customer does not have enough to purchase the feature, thus they must collaborate and pool their money together to get what they want. I like this game because it demonstrates the constraints (especially time constraints) that developers have, but it puts control of what goes into the product in the customer’s hands.

After lunch it was “Principles of Object Oriented Component Design” with Robert C. Martin, AKA Uncle Bob. The theme was software complexity and how OO design can make software simpler to write and maintain. OO systems that have modules that have cyclical highly coupled dependencies are very difficult to modify. Changes made to one part of the system can affect other parts of the system that are not related. Thus, Robert describes how to build systems that are loosely coupled by actively managing dependencies across modules. In practice this is harder than it sounds because all it takes is one wrong import statement (or the wrong #include) to create a cyclical dependency. (For the purpose of this talk, the definition of a component is an isolated binary that can be deployed independently, such as a jar file or a dll.) With Java, JDepend can be used to avoid this problem. Dependencies should always flow in one direction across modules; in other words module A must never depend on module B. Sometimes this cannot be avoided, so a few techniques can be used to avoid a bad dependency:

• Copy and paste the code from module A to B. Hint, this is not the best option.
• Refactor the functionality to a module C, and have both A and B depend on it.
• Express the functionality that B needs from A as an interface. Define that interface in module B, but have the implementation injected from module A.

It would be nearly impossible to determine up front exactly which modules should exist and what their dependencies should be. For this reason, he advocates a design that evolves over time, which is the Agile approach. As I pointed out to him, skills in test driven development and refactoring are absolutely crucial in order to develop in this fashion. Without the ability (not to mention the tools that IDEs provide) to refactor, developers will be reluctant to shift code around that already works. TDD is the tool that gives developers the confidence to restructure and move code around because that is how they know that nothing was broken in the process. Although he did mention using interfaces quite a bit in the talk, I think that interfaces play a huge role in loosely coupled classes and modules. I think this point could have been emphasized more, but then again maybe it would not have been necessary for the target audience.

Tomorrow morning is his talk on Clean Code:

This class is about code. We will put code on the screen and we will read it and critique it. And then, one tiny step at a time, we will clean it. In this class, you will participate in the step-by-step improvement of a module. You will see the techniques of the Prime Directive (Never Be Blocked) and Agile Design principles brought into play. You will witness the decision-making process that agile developers employ to write code that is expressive, flexible and clean.

Conferences don’t usually go this deeply into coding, so I’m looking forward to this talk!

Here are more pictures at the conference.

Here’s some news on JRuby, a version of Ruby that runs on the JVM. Sun is hiring the developers that created JRuby to work on it full time.

As told by Charles Nutter, one of the JRuby developers:

The primary goal is to give JRuby the attention it really needs. The potential for Ruby on the JVM has not escaped notice at Sun, and so we’ll be focusing on making JRuby as complete, performant, and solid as possible…

And yes, JRuby will remain as open source as it is today. It just might start moving a bit faster (as if it weren’t moving fast already!)

This is yet another indicator of the growing influence of dynamic programming as talked about by Jim Moore at the last OJUG meeting. The JRuby team should be congratulated and commended for their good work and contribution to the Java and Ruby communities.

Yesterday the NY Times published an article about the newest draft of the subway map. The current draft, like the current map, points out major streets, parks, neighborhoods, and other landmarks. The New York map is unique among subway maps in that it is (somewhat) geographically accurate and that it points out things that have nothing to do with the subway. When I was a kid I was very much a map (and subway) geek, and I studied the map thoroughly to the point of almost memorizing it. Not only did I have a good idea of where the routes went, but I also knew where all the major neighborhoods were even though I had never been to most of these places. Whenever I travel to other cities with a subway system, I always miss this feature in their maps as they always show just the subway routes to the exclusion of everything else. In one sense this makes the map easier to read since it is less busy. However I would argue that one does not take the subway just to take it; it is helpful to be able to tell where certain streets lie in proximity to a station.

Apparently I’m not the only one with this opinion. Back in 1972, map designer Massimo Vignelli designed a map that emphasized the routes over everything else. Only straight lines, 45 and 90 degree angles were used. As an MTA spokesman said at the time,

“Maps like these have to make deliberate distortions to clarify. We tried to make sure that nothing unnecessary distracts the eye from the subway routes. There’s no sense in using a transit map for geography lesson.”

However, according to the NY Times article the map was not well received at all. After much complaining, the map was redesigned and a new (much more geographically accurate) version was issued in 1979.

From the article:

Although designers love to discuss why Mr. Vignelli’s schematic map didn’t fly, no single theory has emerged. The graphic designer Michael Bierut, however, suggests that New York’s street grid was to blame.

“Londoners are actually unclear about how close one stop is to the next,” he said. “But a lot of Manhattanites could tell you authoritatively how long it would take to walk from Fifth and 28th to Seventh and 44th. So the geographic discrepancies in the Vignelli map, which are no more than those you find in lots of subway maps around the world — they’re just glaring.”

For more on the 1972 map redesign, see this map guide on subway.com.ru. The site nycsubway.org has a great scan of the 1972 map. This map was discontinued in 1979, so I have very vague memories of it. Looking at this map now I offer the following observations:

• Central Park is a square, and a tiny one at that.
• Roosevelt Island and Randalls Island are completely missing from the map. I was going to point out the missing Tramway link but that was not built until 1976.
• The transfer at 42nd St between the 8th Ave IND (The A, C, E lines) and the Times Square station is not drawn. I’m fairly certain this existed way before the 70′s, and it would be something important to know.
• The Grand St station is on the East River!
• Queens appears to be very small and it appears to have a lot of subway coverage. Even looking at maps in the 80′s and 90′s, the subway coverage of Queens is quite distorted. To see what it really looks like, have a look at this mashup. Queens is much larger than the map indicates, and most of it is not covered by subway.

In learning about this history, the most amusing thing is the quote “There’s no sense in using a transit map for geography lesson.” That is exactly what I used it for, and it has served me well to this day!