Tuesday, 15 January 2013

Problem Domain Expert or Technical Expert or Even Both?

The technology side of software development has always fascinated me far more than The Business Problems that we’re actually trying to solve. This view I suspect is at odds with what many “experts” propose is the way we (software developers) should be. I remember a blog post by Peter Gillard-Moss a couple of years ago called “I am NOT a geek” where he suggests that the geek mentality can be bad for business. I completely agree with the sentiment about the need for a mixed workforce because I’ve seen what the opposite effect is when everyone tries to “align with the business” and it isn’t pretty either. Yes, tactical solutions exist for a reason, but once you start trying to scale that out you need techies too if you want reliability, maintainability and all those other -ilities as well.

I made the conscious decision many years ago that I would put my efforts into learning more about the technology and pay less attention to the business; which in this case has invariably been Finance. Naturally I pick up plenty by osmosis, certainly more than enough to get by on, and more importantly enough to either ask the right sort of questions or to know who to ask. But first and foremost I put my spare time into understanding more about the technology used to solve those problems. And by extension that includes understanding more about how we should go about developing those solutions efficiently.

When I talk to an agent or have a telephone interview I make it quite apparent that I don’t know much about “Finance” per-se and that if what they want is someone who understands the subtitles of all the various instruments, then that’s not me. But, if what they have is a lack of source control, a creaking build system, deadlocks, livelocks, memory leaks, Singletons, poor performance and nasty threading problems then just maybe I am their guy. Of course what they really want is both - an expert in the problem & technical domains[1]. I’ve yet to work with (or interview) anyone who meets that criteria in full. Maybe they exist, I know of a few people that might come close, but as a rule of thumb I find developers sit somewhere on the scale between technical and business excellence.

Sometimes I do question whether I should know more about The Business, especially when there is a problem I don’t immediately see because I don’t know enough to realise something is obviously wrong. Many years ago I was asked to look into a pricing calculation difference and I spent hours single stepping through code side-by-side, and when I asked someone to check over what I found he told me instantly that some market data was rubbish. I always knew I was the wrong man for the task when given it, but perhaps there was no one left to look into it. I still feel my time would have been way better spent fixing stuff I knew how to fix, and it wasn’t like there wasn’t plenty of that to do. I also got to reciprocate with my fellow developer later and help him fix his access violations once we started pushing his code through the heavily COM/multi-threaded trade grinder.

In contrast the other day I spotted that many trades were being excluded because we were missing some market data. Although I can’t name every currency, I do know enough of the major and minor ones to know that this didn’t feel right. A minority currency like the one missing probably shouldn’t be having the kind of effect it was and so I passed it off to the analytics team to see if something was up. There was indeed a bug hiding in there. Interestingly the reason the business didn’t spot it is because the trades were “unimportant” to them.

In this kind of scenario a less business orientated mind can actually be beneficial. For instance where I have strived to ensure that no difference means exactly that (to the nth decimal place), others have taken a looser attitude because they know that in the grand scheme of things the odd number slightly out of place here and there will probably be “acceptable”. The same goes for extrapolating reliability problems - an access violation, out-of-memory condition or timeout to me is a problem just waiting to “jump the cracks” in 64-bit land and take out an entire blade or even create a Denial of Service (DoS).

The argument about Generalists vs Specialists will no doubt go on forever. I like the idea of being a (generalising?) specialist and accept that my openness about not wanting to be a business expert too will reduce the pool of work available to me. But I’m happy with that, I’d rather not pretend to be I’m something I’m not. My CV purposely lists only a handful of skills, the interviewer can either assume that I know VBScript because it’s just “one of those things a guy like that knows” or he can assume I have a very narrow skill set. Conversely the person I want to work for knows how to answer that question by reading about what type of work I’ve done before, perhaps along with perusing my blog and free software tools.

Given that the complexity of the software systems we’re building is only getting larger and not smaller, I think we’re going to need plenty of people who work in the problem domain of "making it possible for the other developers who work in the business domain, to work”.


[1] And preferably someone with interpersonal skills too, but they’d probably take a recluse if they had two out of three.

1 comment: