Last night QCon offered an after-hours chance to hear Martin Fowler and Dan North speak on the topic of the “Yawning Crevasse of Doom,” more recognisable to us as the communication gap between the business and development. The talk began at a very pedestrian pace and I was soon fearing that this seminar would yield nothing new or stimulating, but this proved unfounded.

Dan and Martin used an analogy of a ferry man and a bridge builder to illustrate the trouble in communication. In the case of the ferryman, an analyst is used as a conduit between business and development with the risk that too little is communicated or communication is inaccurate. Also to its discredit, this is a slow, “low bandwidth” form of communication. The bridgebuilder, on the other hand, allows direct contact between the business and techies, thereby enabling tight feedback loops and frequent, “high bandwidth” communication. Obviously, building bridges is the preferable scenario.

The topic of domain driven design came up, with Fowler stating that it’s been around for some time but only now coming into popularity. Evolving a project-wide “ubiquitous language” is indeed an important concept and one that Fowler stressed. Business people should be speaking the same language as developers and testers. Fowler then brought the concept one step further, stating that even technical aspects of a project can affect communication. Programming languages was the example, which Martin suggested can impact the ubiquitous language and communication on a project. One of his current “hobby horses” of the moment is domain specific languages, which are “little languages” that are intended to solve problems within a given domain. (VBA for Excel is an example of one of these, basically a domain-specific version of VBScript!) See a Fowler talk on this topic here.

For his part, Dan North focussed on the increasing importance of soft skills in making software development work. He brought up the importance of usability testing and how this is something we should definitely be testing for, as per the context-driven testing school. He also mentioned interaction testing and ethnography, which involves direct study of the way people use a system. Off-shoring came up, and Dan made the comment that the only distributed model he’s seen work is the one whereby teams of business analysts, developers and testers are still co-located together. Across a project, one such team might be onshore, another might be offshore.

Fowler closed by asking the largely development audience to think about each of their technical challenges and what they mean for communication. “How does this affect the bridge?” He asked. It’s an interesting line of inquiry.

The place was literally crawling with ThoughtWorkers and a post-session visit to the bar provided a good chance to catch up, as we at SQS have worked with them before at Egg and Barclays, among other places.

http://www.infoq.com/presentations/Fowler-North-Crevasse-of-Doom

Today marked the first day of one of London’s newest and most anticipated technology conferences, QCon. Today was the first tutorial day of the conference, with a morning session on JMX and an afternoon session on Test Driven Development. The crowds weren’t huge, but they had come from all over Europe and as far as Saudi Arabia. I had a great time at both sessions. Here’s my rundown of the two.

Session I: JMX with Simon Brown

I wasn’t sure exactly what to expect out of this seminar as I was only vaguely familiar with JMX before today, however this turned out to be a really interesting session. JMX is a set of Java management extensions that allow an application to report back various different metrics to the JConsole management console or a bespoke console/application. These can be things like how many concurrent users are accessing a system component, how much memory is being used by the components, the Java heap size, or the CPU utilization of each java process within a JVM. It can also return values of properties or variables and allow users to action class methods via the console (e.g. to start or stop a service).

Dan stated that JMX is best used to instrument coarse grained architectural components in this way. He instruments Java applications for London-based banking clients using JMX primarily so that they can be monitored in production.

Simon’s blog can be found here: http://www.simongbrown.com/blog/

Session II: Test Driven Development with Erik Doernenberg

Unfortunately, Martin Fowler was not on hand for this tutorial as promised but it was still an interesting session. We’re all pretty familiar with Test Driven Development by now– the practice of writing unit tests before authoring source code– and really I had been curious to see how Fowler addressed the topic and pick up tips for SQS Agile training.

Erik started with the premise that primarily a design technique that allows developers to focus on delivering only what’s required and thinking about how best to model their application. Naturally, it has the additional benefit of producing lots of unit tests! Fortunately this session went a little further than your average TDD session. We started with the basics (writing tests, then producing source code). We quickly advanced to the more interesting topics, and one became a recurring theme: state verification testing versus behaviour driven testing (i.e. the TDD classicists vs. the mockists). Older techniques such as using stubs or making state-based assertions are popular and still have their place. However newer techniques such as mocking, which make assertions about an object’s implementation, can also be useful. There was some discussion of the pros and cons but Erik was careful not to place himself too firmly in either camp. The outcome was, as with many things, that the context should drive which to use and when. Martin Fowler has an interesting article on this.

Another purpose of this tutorial was to talk about software patterns that lend themselves to TDD. A natural one to open with is the red-green-refactor pattern, which simply involves writing failing tests, then making them pass by developing the appropriate source code (i.e. causing the status of your build to go from red to green), and finally refactoring to improve on your code. Erik recommended checking in the code once everything was green and then giving yourself a strict time limit to refactor so that you didn’t waste time going nowhere. The object mother pattern also came up, which can be used to generate elements of tests as needed. The dependency injection pattern also reared its head, it being the practice by which a class’s dependencies (more accurately resource providers) are injected via the constructor. This makes the class inherently more testable as dummy objects can be easily passed in to it.

Erik also recommended not testing private methods through public ones that may interact with them, but instead to use protected methods instead of privates and keep your tests within the same package (this would put them within the same scope). Test coverage came up, and Erik said he thought it was of particular value for teams learning TDD and commented that the aim was for it to be increasing in such cases. For experienced TDD teams, he was not so sure of the value. He was certain that it was not a good thing to become too obsessed with it and not to advocate 100% coverage.

Some other points:

• Copying test code is a no-no in Erik’s view. Test code should vary greatly and copying could mean you mistakenly end up with a very homogenized test code base.
• easyMock is an alternative to jMock which may improve on it to some degree.
• We briefly discussed domain driven design and ubiquitous language. UL basically states that the business language should match the development language. An interesting thing came up: what do you do when the business language is not English? This can cause problems as IDE’s and programming languages don’t lend well to non-English languages, though it was mentioned that you can get around Java’s reserved word restriction on “class” by placing an umlaut over it, i.e. “cläss.” It certainly does look cool, as Erik pointed out!
• Symmetry in design- that natural symmetries should appear in application code. A simple e.g. would be that if a class has a setter for a property it should also have a getter.
• We were all entertained when Erik’s MacBook crashed mid-presentation.

Lecture slides will eventually be posted on Erik’s blog: http://blogs.doernenburg.com/