The practice of continuous integration is gaining widespread adoption and almost every project I was involved in over the past few years used a continuous integration server to maintain an up-to-date view on the status of the build. Developers can look at the status page of the server or use tools such as CCTray and CCMenu to find out whether a recent check-in has broken the build. Some teams also use build lights, like these for example, or other information radiators to make the status of the build visible.

The reason why developers need an up-to-date build status is a common, and good, practice: new check-ins are only allowed when the build is known to be good. If it is broken chances are that someone is trying to fix it and dumping a whole new set of changes onto them would undoubtedly make that task harder. Similarly, when the server is building nobody knows for sure whether the build will succeed, and checking in changes would make fixing the build harder, should it fail.

To recap: the build must be good for a developer to be able to check in. On one of our projects this was becoming a rare occurrence, though. In fairness, the build performed fairly comprehensive checks in a complex integration environment, involving an ESB and an SSO solution. The team had already relegated some long-running tests to a different build stage, and they had split the short build, ie. the build that determines whether check ins are allowed, into five parallel builds, bringing build time down from over 45 to under ten minutes. Still, developers often found themselves waiting in a queue, maintained with post-its on a wall, for a chance to check in their changes. Not only that but everybody felt the situation was getting worse, that the build was broken more often. This was obviously a huge waste and I was keen to make it visible to management using a visualisation.

Read the rest of this entry »

To begin with an antipodean image, using a service-oriented architecture, when it works out, can be as elegant and exhilarating as surfing on a 10 meter wave, exploiting huge uncontrollable forces to move forward at great speed. However, unfortunately, and maybe much like in the surfing world, the SOA wave often mercilessly rolls over a hapless development team, leaving them confused and wondering whether to give up on the idea or to paddle out again.

Despite its complexity a service-oriented architecture is high on almost every project’s wish list. I have been involved in eight projects over the last year, sometimes directly delivering working software, sometimes reviewing or advising, and out of these eight projects six were, according to the respective architects, building a system with a service-oriented architecture. On these projects I have come across two recurring uses of language around SOA that I found noteworthy.

Firstly, SOA used to, and still should, stand for an architecture that is service-oriented, with “architecture” being the noun. What I have found, though, is that more and more often people use “SOA” as an adjective and then add it to a more or less random noun, such as “approach” or “model” or even “architecture” again. Yes, I have heard people talk about an SOA Architecuture more than once.

This use of language highlights a problem. Sticking the three letters “SOA” onto a random noun, without pronouncing what the letters stand for, makes it easy to forget what this was all about in the first place. In fact, it seems that “SOA” is now put in front of words such as “approach” simply to make something sound contemporary; as in: “How’s your project?” — “Oh, we follow an SOA approach.” Given my experience, chances are that the project’s architecture is not service-oriented. It might use WS-* standards, though.

Secondly, there are people who are referred to as SOA professionals or similar. It usually sounds like it’s their job to build SOAs. But what does that really mean? Shouldn’t developers built software according to a service-oriented architecture? Are the SOA professionals merely advising teams on how to build service-oriented architectures correctly?

In my experience the SOA professionals have a different agenda, and that is to sell SOA. Unfortunately, in the words of my colleague Jim Webber, there are two things money can’t buy: love and an SOA. Again, using the three letters one might think “why not?” but spelled out, would anybody argue you can buy a service-oriented architecture? Or any architecture for that matter? So, what is really being sold is usually a set of products, software and/or hardware, that may or may not help a team implement a service-oriented architecture.

The key problem in this case is that when you “buy SOA” the success criteria shift. It seems that success is defined based on whether something that can be labelled “SOA” is in place, and not whether actual business value is delivered. What is often completely forgotten is an evaluation of the suitability of the architecture, but that’s a topic for another post.

The main features of this release are partial mocks and method swizzling. Sometimes it’s just easier to use a real object rather than setting up a complex mock from scratch, but often in such cases there is at least one method on the real object that has undesirable side effects, or a method returning a value that we would like to change for a test. With the new features in OCMock it is now possible to selectively replace individual methods on existing objects. Did I mention that I love the Objective-C runtime?

As usual the release also includes many contributions and bug-fixes from the community. More details on the OCMock page at Mulle Kybernetik.

Over the past years I have shown everyone who could not run fast enough some of the tools based on Moose. And even now I cannot resist putting a screenshot of CodeCity into this post.

Most of the Moose tools now use the MSE file format as an interchange format. By the way, if you are interested in writing your own visualisations or analysis tools it is probably worthwhile looking at MSE, reading this format is so much more convenient than parsing source code.

In Java it was always relatively easy to create MSE files. Among many other things, iPlasma can read Java source code and export to MSE. That said, iPlasma has so many interesting features itself that oftentimes no export to an external tool is necessary.

For C# the story was different and for one reason or another no tool existed that could create MSE files for C#. This has changed now. As a student project at the University of Lugano such a tool was written and, thanks to Michele Lanza, then donated for general use. I’ve made a few improvements and put the code into this Bitbucket repository.

At some point last year I was asked to review the architecture of the software behind a large and popular website. The resident architect explained how he had followed a modern approach, decoupling the web front-end from back-end services that provide content. To gain further flexibility he had put the front-end and the services on an ESB, mostly to cater for the possibility to make the content available to other consumers. In short, the architecture diagram looked a lot like many others: nothing to see here, move on.

The diagram above only shows one of the content services, which for the sake of this article is a service that provides contact details for a person.

Based on conversations with the project sponsors I began to suspect that at least the introduction of the ESB was a case of RDD, ie. Resume-Driven Development, development in which key choices are made with only one question in mind: how good does it look on my CV? Talking to the developers I learned that the ESB had introduced “nothing but pain.” But how could something as simple as the architecture in the above diagram cause such pain to the developers? Was this really another case of architect’s dream, developer’s nightmare?

Read the rest of this entry »