Learning by imitation vs learning by understanding

As I mentioned a while back, the refactoring project’s FX functionality was developed by guess work. We’re fixing that now by spending some time gaining an understanding of the problem domain as we refactor.

I’ve always been pretty proud of the fact that I deliberately set out to know nothing about your business. I think it makes me a better developer. I know that I know nothing about how your business works; I don’t assume that I know better than you do just because I’ve read about your business area a couple of times. I focus on technology and that’s plenty to be getting on with thank you very much. I’d much prefer to spend 20-30 minutes, every now and then, with one of your top people, someone who really knows what they want the system to do, rather than use my ‘understanding’ of your business to deliver a system that’s only my best guess at what he might want. I’m not afraid to ask “Why?”.

I’ve worked in the financial markets for 6 or so years now. I’ve stuck to my rules, and, as I say at project initiation meetings or contract interviews; I don’t know how to price a swap, but I do know how to put robust software together. Choose what’s more important to you right now.

The last couple of weeks I’ve come across a problem that I haven’t seen before. Our business users don’t know the answer to the “Why?” questions. Their response is “Just make it work like this other system that you’re replacing”. That’s what the original developer did. The problem is that we keep having odd boundary condition errors occurring as particular situations arise. These situations are things that he never saw happen in the other system whilst he was “designing” the new system.

So I went and bought a book on FX trading. It’s not my first business oriented book, but it’s the first I’ve bought to solve a design problem. Some of the refactoring required is obvious; we need to rip the GUI handling code out of the rates calculation engine. Some is less obvious; it would be nice if the structure of the rates engine matched the way “the business” viewed what was happening - and if that’s not possible then it would be nice if it used the same language to describe things.

So far it’s been very useful. It’s explained why the results we get most of the time are right even though we do the wrong thing to get there. But more importantly it’s explained how we should be doing things, which makes it easy to see why things currently go wrong. I’m learning a lot, but I expect I’ll forget most of it once the refactoring has been done and the knowledge is safely embedded in the code and its tests; that’s fine, my brain’s not very big and I tend to remember where to look…

It’s interesting stuff; in the same way that learning just enough about how SQL server works under the hood is interesting for a C++ guy trying to write code that uses SQL server.

So I guess I should update my position statement; I don’t know how to price a swap, but I’m prepared to learn if you need me to.