Living in a state of accord.

Don’t Get Around Much Anymore

Human Resource Executive Online has an interesting story related to my previous entry:

Ask yourself this question: If you were offered a new job in another city where you have no ties or networks, and you suspected that the job would probably not last more than three years (which is a good guess), how much of a raise would they have to give you to get you to move? Remember, you’d likely be trying to find a new job in a place where you don’t have any connections when that job ended. I suspect it would be a lot more than most employers are willing to pay.

Again though this should be driving up the number of remote jobs, but where are they all?

Where Are All The Remote Jobs?

It seems like forever that people have been arguing that remote working is the future. Why limit yourself to just the people who live near your office when hiring? Why suffer the distractions of an office when you could define your own environment in your very own home? Why waste employee time commuting? Surely by now every employee would want to be working from wherever they choose and employers would be forced to accept it, if not actively encourage it to save on office costs and get the best employees.

Yet somehow despite all the hype and promise there seem to be exceedingly few jobs around that allow for remote work. The fastest way I know of to ensure a recruiter never contacts me again is to simply mention that I’m based in Brisbane Australia and have no interest in moving. That greatly surprises me – especially in the technology industry.

When I do see jobs that support remote work it’s almost always for companies that primarily work on open source code or companies that primarily hire employees based on either their involvement in the company’s community or their other open source contributions.

So perhaps one of the big reasons employers aren’t adopting remote work as much is the difficulty in hiring the right people, training them and integrating them into the company and evaluating if they’re actually working out. Remote working involves a significant amount of trust between employer and employee. New employees generally haven’t had a chance to build up that trust unless they were already contributing to the companies community or demonstrating their contributions in open source. Unfortunately looking at open source contributions excludes any developer that enjoys their job so much they spend all their spare coding time on that and don’t currently work in a job that involves a lot of open source.

That fits with my current situation – for the last two and a bit years I’ve had the luxury of working from home, but it only happened because I originally worked in the London office and then resigned to move home. Fortunately they were keen to keep me so I wound up staying on and working from home. Later a second developer went through the same process and now works from New Zealand.

Once trust and culture is established we seem to have plenty of tools to make remote working extremely effective. If remote working is really the future though, we’ll need to find better ways to establish that initial trust and on-board new employees.

Are there hordes of remote working jobs out there that I just don’t hear about? If not, what’s stopping it from taking off?

Combining Output of Multiple Bash Commands Into One Line

I wanted to create a CSV file showing the number of JUnit tests in our codebase vs the number of Spock tests over time. I can count the number of tests, along with the revision pretty easily with:

git svn find-rev HEAD
find src/test -name '*' | wc -l
find src/test -name '*Spec.groovy' | wc -l

But that outputs the results on three separate lines and I really want them on one line with some separator (comma, space or tab). The simplest way to achieve that is:

echo "$(git svn find-rev HEAD), $(find src/test -name '*' | wc -l), $(find src/test -name '*Spec.groovy' | wc -l)"

It’s also very handy to remember that echo has a -n option which omits the trailing new line, so:

echo -n 'Revision: ' && git svn find-rev HEAD


Revision: 55450

The Single Responsibility Principle (and what’s wrong with it)

Marco Cecconi – I don’t love the single responsibility principle:
The principle is arbitrary in itself. What makes one and only Reason To Change™ always, unequivocally better than two Reasons To Change™? The number one sounds great, but I’m a strong advocate of simple things and sometimes a class with more reasons to change is the simplest thing. I agree that we mustn’t do mega-classes that try to do too many different things, but why should a class have one single Reason To Change™? I flatly disagree with the statement. It’s not supported by any fact. I could say “three” reasons and be just as arbitrary.
Interesting critique of the single responsibility pattern. The quote above is perhaps one of the weaker arguments against the single responsibility pattern but it struck a nerve with me because all too often we assume that because a rule sounds good it has some validity. In reality, picking one responsibility for a class is quite arbitrary and, as the article argues, deciding what a responsibility is is even more arbitrary.
So, whilst I agree completely on the premise of not make ginormous classes, I think this principle is not at all helpful in either illustrating the concept or even identifying unequivocally problematic cases so they can be corrected. In the same way, anemic micro-classes that do little are a very complicated way of organizing a code base.
Given I’ve spent time today fixing a bug that was almost entirely caused by having too many classes with too focused responsibilities which caused the combined structure to be difficult to reason about and have unintended consequences this resonates strongly as well. Making responsibilities too fine grained is just as detrimental to the maintainability of code and somewhat counterintuitively also to it’s reusability. Reusing a single class is far simpler than having to work out how to piece together ten separate classes in the right way (hence the existence of builders which create a facade that everything is really a single unit again). I can see a lot of value in discussing things in terms of coupling and cohesion rather than responsibilities and using those concepts to find the right balance.

Testing@LMAX – Testing in Live

Previously in the Testing@LMAX series I’ve mentioned the way we’ve provided isolation between tests, allowing us to run them in parallel. That isolation extends all the way up to supporting a multi-tenancy module called venues which allows us to essentially run multiple, functionally separate exchanges on a single deployment of the LMAX Exchange.

We use the isolation of venues to reduce the amount of hardware we need to run our three separate liquidity pools (LMAX Professional, LMAX Institutional and LMAX Interbank), but that’s not all. We actually use the isolation venues provide to extend our testing all the way into production.

We have a subset of our acceptance tests which, using venues, are run against the exchange as it is deployed in production, using the same APIs our clients, MTF members and internal staff would use to test that the exchange is fully functional. We have an additional venue on each deployment of the exchange that is used to run these tests. The tests connect to the exchange via the same gateways as our clients (FIX, web, etc) and place real trades that match using the exact same systems and code paths as in the “real” venues. Code-wise there’s nothing special about the test venue, it just so happens that the only external parties that ever connect to it are our testing framework.

We don’t run our full suite of acceptance tests against the live exchange due to the time that would take and to ensure that we don’t affect the performance or latency of the exchange. Plus, we already know the code works correctly because it’s already run through continuous integration. Testing in live is focussed on verifying that the various components of the exchange are hooked up correctly and that the deployment process worked correctly. As such we’ve selected a subset of our tests that exercise the key functions of each of the services that make up the exchange. This includes things like testing that an MTF member can connect and provide prices, that clients can connect via either FIX or web and place orders that match against those prices and that the activity in the exchange is reported out correctly via trade reporting and market data feeds.

We run testing in live as an automated step at the start of our release, prior to making any changes, and again at the end of the release to ensure the release worked properly. If testing in live fails we roll back the release. We also run it automatically throughout the day as one part of our monitoring system, and it is also run manually whenever manual work is done or whenever there is any concern for how the exchange is functioning.

While we have quite a lot of other monitoring systems, the ability to run active monitoring like this against the production exchange, and go as far as actions that change state gives us a significant boost in confidence that everything is working as it should, and helps isolate problems more quickly when things aren’t.