QCon 2007 in a Nutshell

  • Kevlin Henney emphasized the real business cost of not getting rid of the “archaeological layer” of a code base. A system with 1 million lines of code, only 100,000 functional, had hit a wall at processing 30,000 messages a second. He was called in, recommended cleaning it up, and was put off while they tried other things. When those didn’t work, he was asked back, he removed the cruft code, and the system now handles some 90,000 messages per second.
  • Martin Fowler and colleagues, Modifiability, or is there Design in Architecture:
    • On doing “the simplest thing that could possibly work”, there is confusion between “the quickest thing” and “the simplest thing that will work in the long term” (Fowler reports Kent Beck as saying, on recoiling from some code: “Yes, but the phrase is the simplest thing, not the stupidest thing”)
    • Often preliminary investigation reveals things that would not be predicted from outside: in a case where they were building a process for collecting information about clients, the useful model was not the client information, but the collection of that information. (As we recently saw in one of our projects, where the client domain did not provide the right mental model for dealing with the new process.)
    • “Defer any decision to the last reasonable moment” (not the last possible moment), and recognize the point at which you have to make the decision (Erik Meijer echoed this in his keynote)
    • “Always know and be able to articulate the model. If the system changes, change the model. Because if you can’t articulate it, you don’t know what you’re doing”
    • “Keep the domain model clear of implementation details at all costs”
    • “Test-driven systems tend to drive better design and architect themselves to a greater extent”
    • “Things are going well if developers are talking and you can’t tell if they’re talking about code objects or business objects”
    • “If you think you need to break encapsulation, either you’ve got the model wrong or you haven’t got the right solution yet. Hide as much as possible for as long as possible.”
    • “Agile can be used as an excuse not to do the basic right thing. Don’t.”
    • Growing great developers is important. “It’s really easy to double the productivity of a programmer in a six-month agile project.”
  • In one of the tutorials and in Erik Doernenburg’s Selenium paper the Presentation Model was discussed. If you’ve got a messy GUI, testing is notoriously complicated, but if you represent the state and behaviour of the GUI in model classes then you can manipulate those directly for testing purposes, bypassing the GUI. So long as you also test the proper binding of your presentation model objects to your GUI, testing the whole becomes much simpler.
  • Rob Harrop, in his talk on JRuby (fully wrapped by Spring 2.0.2 and later) didn’t actually mention JRake (which I see has now merged with Raven), but the talk did remind me of it. (More on this later: I think it well worth pursuing as a better build solution.)
  • Rod Johnson, in his speech on Spring AOP: “Currently as customers we have all ten of the world’s largest banks”
  • Larry Constantine, in his keynote on usability, emphasized the importance of meeting genuine user needs (“Don’t ask users what they want, because they’ll tell you, and it might not be what they need”), and of never passing technical constraints back to the user.
  • Erik Meijer, in his keynote, spoke of IDEs and other tools as helping the user, like intelligent paper, which strikes me as a really neat starting thought for a user interface.
  • Joe Walker spoke of the three proposals for adding closures to Java (BGGA, supported by Gosling, CICE, supported by Bloch, who finds BGGA too complex, and FCM), and noted he felt the Gosling-supported version most likely to get into Java 7. (A recent article lists four proposals: add C3S to the list.)
  • Rails, Grails, SEAM have all jumped on the convention over configuration bandwagon and allow a simple un-customized app to be built with scaffolding code with a single command. The 25-words-or-less version of the differences: Rails has Ruby code (ActiveRecord etc) under the hood, Grails has Hibernate and Spring MVC, and SEAM incorporates JPA and JSF. (More on this later, too. SEAM is the obvious choice where clients mandate architecture-by-the-standards, but I went into the conference intrigued by Rails and I still am, and Grails looks to have a much easier learning curve for Java developers while providing many of the same benefits.)
  • In their keynote The Yawning Crevasse of Doom, Martin Fowler and Dan North talked about the importance of building bridges between techies and customers: Fowler spoke of writing Domain Specific Langauges that the business folk could read (they don’t have to be able to write them, though that does happen sometimes, but they should be able to read them). North noted how acceptance test driven planning gives both the business and techies a shared definition of “done”, and plugged Behaviour-Driven Development
  • Obie Fernandez, in his introduction to Ruby, noted that it was used by the 4th largest manufacturer in the world, and that it was used by Barclays Bank for internal systems. He added that it “gives you enough rope to hang your entire team” if you don’t do it right.
  • Zed Shaw, speaking of Mongrel, but by extension of other successful open source projects, noted that one of the keys to Mongrel having a hundredfold better takeup than any other rails server was quite simple: it has the documentation right on the home page. And the documentation describes how to use it, not how it works, and gives answers, not explanations. “Ultimately, it’s about removing suffering. Make it easier to use than the competition.”
  • James Cox, talking of rails scalability, noted that the most important thing could be to ask the users what they thought was slow, that fixing perceived performance problems could be a bigger win than fixing the actual ones. He also made lots of good points about fixing the actual ones (talk here).
  • InfoQ’s summary of blogs of the conference.

It's only fair to share...
Share on Facebook
Tweet about this on Twitter
Share on LinkedIn

Leave a Reply