“ROA – Resume Oriented Architecture”

(from an internal source…)

I may well have the messiest desk in this building, my tie is on crooked, and my beard is generally fairly untidy. However I have a perverse compulsion to keep my source code neat and tidy – in particular I am obsessive about keeping as little as possible in my list of modified/new files. I’m particularly bad when
working with CVS and the Eclipse CVS integration that shows the list of outgoing changes. The longer I go with a list of outgoing changes the more uncomfortable I become. It’s obvious where this comes from – with concurrent versioning I’m compelled to merge my changes with the current head or branch as regularly as possible, to save myself pain. I also want to see the code that I’ve written build and test cleanly on the continuous integration server.

This has an interesting effect on the way I approach major refactoring/rewrite tasks – obviously it’s a good idea to do these jobs in a staged way. When working in a larger team working concurrently on a single code base this becomes so important – perform a refactoring step, check into the head, see it build cleanly, help the team merge into their current work, everyone build cleanly. Then onto the next step.

It absolutely freaks me out to work with a developer and find 200 modified files and 200 ‘test scripts’ that are not part of the production code base. It’s just not right – the repository should only contain clean code. Move scripts and test classes out to a scratch project, and undo modifications that you did ‘just for testing’ and have held onto. What you are risking is very important – that you’ll miss files that you should check in amongst the forest of modified files. That you’ll accidentally check in a testing hack. Or you’ll spend hours chasing bugs that you can’t reproduce because of something that you’ve changed in your local source.
Now I say it out loud it sounds a bit silly, but it’s just one of my little perversions – hopefully they add up to make me a good developer, not that scary bearded guy.

Irrational Clearcase makes this sooo much worse – I have many a rant to make about that product. It’s also to do with the implementation here at my current project where they are using the traditional ‘checkout-lock/checkin-unlock’ pessimistic locking. This causes so much contention here that people take ‘unreserved checkouts’ meaning you can change your file but must merge later. The Clearcase merge tools are so very poor that it’s an excruciating process – even I don’t like to merge changes from the repository (VOB) a task that I would happily tackle with CVS (using Eclipse anyway).

My ‘shitlist’ for Clearcase is long and unhappy – no atomic commits, ridiculous user interface, how the heck do you restore a deleted file? You can’t get a simple single view of files in your project that you’ve added, so I constantly make the goof of not adding a file and breaking the CI build. The default environment here is also to work with ‘dynamic views’ stored on a remote network location – can you spell S-L-O-W? (Yes I’ve moved to snapshot views). I could go on.
Large organisations pay money to IBM for this garbage. Give it to me instead!

I was perusing the source generated from a psuedo-‘MDA’ tool that is in heavy use at my new workplace. For every domain class the tool generates a dumb structure class or ‘bean’ with setters and getters, plus numerous translators to/from DOM/XML Strings/various other formats. I noticed the translator to XML String was an extension of the DOM translator – basically the code would walk through the domain object and build a DOM equivalent in memory, then call an XSL transform on the DOM to output XML in String form. Yikes!

So I ripped some of the generated code out into a scratch project and made the same traversal of the object model generate events sent to a SAX ContentHandler. I then wired this to the Xerces XMLSerializer which outputs formatted XML text to a Writer – and wrote a test that it output the same text as the existing transformer.

I expected to get something like 3-4x performance improvement in the translator, so I got a little surprise when my next test showed me this result:

Old method: 10000 cycles in 42578ms.

New method: 10000 cycles in 2110ms.

Wow! I really like SAX – in my last project we built some serious functionality around SAX processing of very large XML documents, performing various filtering validation and transformation on the SAX events without ever loading an entire graph into memory.

Aside: I picked up XStream again the other day, definitely falls in the very nifty basket…

Extreme Programming – Uncyclopedia

Extreme Programming emphasises the importance of moving people around, often at speeds exceeding 200 miles per hour. This speed is known as the “Project Velocity”.

Brilliant.

One thing I’ve inherited in my new work place is a coding standard that requires the “Impl” suffix for every interface implementation. I feel very dirty and ashamed. I’ve long held a very strong point of view here – that if there is not a generalised use of a class’ interface then don’t carry around that interface code. Particularly since embracing new IDEs with refactoring tools I’ve been very strict on this one – don’t introduce interfaces until there is a genuine need. “Impl” is a really bad smell to me. Most of the time the way my design falls out means that the interface name does not match the class name exactly anyway e.g. the FooPersistence interface is implemented by the FooPersistenceService which also implements the PersistenceService interface. Very often the interface name is an adjective – e.g. Startable interface for a Service class. I really don’t like “Impl”.

It’s not entirely that simple however. In this environment the convention applies to service interfaces that are implemented on CORBA. The interface is required by the generated CORBA stubs and skeleton classes. You are only hand-writing one implementation of the interface. What else would you call it? TheRealFooService?

The nice thing about being forced to have interfaces for services is that unit testing is easy – it’s easy to stub or mock the interfaces without any magic. Particularly in the mock testing area there seemed to be a bit of debate (at least a couple of years ago when I bothered to read) about whether people should be able to create ‘dynamic’ mocks of concrete classes. The argument against seemed to be that you should have more clean separation of interface and implementation. To me it seemed that if you did a lot of mock testing then you would end up littering your code with a bunch of artificial interfaces. Don’t discount the cost of maintaining a bunch of worthless interfaces – a little bit in code maintenance but a LOT in code readability.

This led me to a heuristic that I’ve used for a while – if I’m testing component A, I often mock the interfaces provided by component B but rarely mock internal parts of component A. I effectively mock at the edges of components and this works quite well. I also find mock testing quite brittle, and the public interfaces that are used between components tend to change less frequently so my tests do seem a bit more robust in this way.

This does however have the occasional side-effect of introducing some ‘artificial’ interfaces, but I can live with that. I don’t call the implementation “Impl” though 🙂

Martin Fowler talks about Implicit Interface Implementation. I’ve occasionally had the same thought, it would definitely save a lot of false interfaces…

It’s been a funny couple of months. Since the start of 2004 I was working on a large content management and publishing system for a large Australian company. On this project we had some great people and mostly very interesting technology. We invested heavily in a very effective build system and continuous integration. Automated unit testing was used extensively and we measured coverage to find weak areas. We did a lot of pair programming, and tried to have daily stand-ups. We used a lot of agile development techniques. I’m really proud of the quality of product that we delivered and particularly the components that I was responsible for.
The project management however was not agile. I’m not suggesting that the best agile ‘coach’ would have saved this project but it broke all the rules – for substantial periods during the project there seemed to little or no stakeholder involvement. How many releases to production did we make during those 2 years? zip zilch. Finally 2 years or more later after a change of CEO, CIO and substantial amounts of senior management overhaul and many other changes to the company landscape it turns out that the project wasn’t building what was wanted any more. Poof – no more project. This was a trifle disappointing for a great many people, including myself. That’s an understatement by the way.

So where do you go from there? A little difficult to get enthused about job interviews when 2 years of work has been canned, I must say. I courted with a couple of companies but ended up taking a contract again, this time in the financial services industry. What I love about it is that there are some smart people to work with, some interesting tech, a new problem domain to explore, and they are building systems that people are REALLY USING. However I do miss a lot. Having worked with substantial unit testing (I hesitate to say TDD) for a few years and continuous integration for at least a couple it does feel very odd to go back to the 1990s… Needless to say I’ve started to introduce people to the joy of jUnit and jMock, and have a super-secret clandestine cruise control server running (on my desktop!) – it might take most of my 6 month contract but I’d like to think that some of it might rub off.

Being exposed to the other side however has really brought home for me what I like about the agile development techniques (I’m being specific here – I mean unit testing, continuous integration, and pair programming mainly… I’ve not yet had the opportunity to work on a project which is project managed in an agile fashion). If I get time I’d like to write some more about what they mean to me – in particular their effect on fear in programming.