When I was a kid, my favourite toy was Lego. The fun part was that you could always make something new, once you got bored of whatever you were making. Often, I’d never really plan on what I was going to build. The end result was usually a mess, but that’s probably the point of Lego: the fun is in the building, not just in the final outcome. I realise we are supposed to wax lyrical and say how things were better when we were kids. However, I can safely say, when it comes to Lego, the sets available these days are frankly amazing, compared to the (near..) past. You can buy all myriad of different Lego sets these days, ranging from Star Wars craft to replicas of real cars and buildings (even one of my favourite the Guggenheim museum in New York).
In a sense, developing Lego is very much like software engineering. Just as with software engineering, you need to plan how you will build before you start if you don’t want to create a total mess. You also want to make sure that whatever you develop is generic. If you build a car door from Lego, you want to make sure that it’s easy to reuse that same component in another car. If you don’t plan what your doing, well that car door will have to be broken down totally and you’ll have to start again. That’s precisely what happens with software. If you’re writing a Python script that you’re likely to use once to do some calculations, ok, there’s not much use thinking too hard about it. However, if you know you’re likely to be adding to it, changing it etc. and it will form part of a larger system, it is worth thinking about it. In finance, in particular, just like in other industry areas, code which is totally unmaintainable is a costly overhead.
Software design is about trying to think ahead. What will you likely change? How can you make sure the components are self contained (ie. making one change doesn’t ripple through and impact everything else)? Should we try to create abstract classes, so we can strip out the implementation from the description of what the code is doing? Do we really need to write yet another logger, because it’s “better” than an open source one (yes, another unnecessary component we have to maintain for no good reason)? Can we separate out the way we load data, with the code we use for computation, rather than mixing it together into some spaghetti.. (and don’t pretend you’ve never done that!). When code is intended for production, these things become even more important, as do running unit tests, to identify if changes you make, break the code. From personal experience, writing unit tests are very important.
In finance, the market keeps on changing, hence we need to keep adding features to our code. Hence, it is key that we can make code properly maintainable. After all, the main cost of code is not the development phase, it is in the maintenance of it. It also suggests that we should try as much as possible to use external solutions, when possible, rather than developing everything in house. If an external solution has a couple of clients, the maintenance cost will get split by many different people. This compares with a proprietary solution, where only your firm has to shoulder the maintenance cost. Sure, develop stuff in house when it makes sense, and you have a competitive advantage, but only then. Otherwise, you’re literally trying to create your own Lego bricks (and having the cost of maintaining them). I think I’ll stick to buying Lego bricks from Lego, rather than making themselves! As far which Lego set I might be getting next… perhaps it’ll be this Lego Bugatti.