Category: Work History

A Hot Date

Written for Fandango’s One Word Challenge (FOWC), engine.

I’m gonna post today about a component I once wrote in my professional life, which was a date engine.

For part of my professional life I was a consultant to an asset management company. Asset Managers run funds, hundrends of them. The way each fund is set up might be different. Half of it might be based on a commodity, like gold or silver, and half of it might be based on a spread of stocks in such-and-such a sector. Or, you might have a fund which is based on other funds. For example a fund might be based a third on Fund A, and two-thirds on Fund B. The possibilities are endless.

We use the term pension fund, and in fact the two are very similar ideas. The plan is just to invest into a fund, and allow the fund manager to grow the fund, without having to worry about too much detail. In fact, the funds we handled were popular with many pension companies.

Unlike the raw stocks or commodities themselves, each fund would only deal periodically. They tended to be long-term, rather than used by day-traders. In the simplest case, something might deal every day, but you could also have funds which dealt:

  • every Monday,
  • every other Tuesday,
  • the first Wednesday of each month,
  • the 2nd last Thursday of each month,
  • the 15th of each month,
  • once a year, on 31st December
  • once a year, on the first Friday

…and so on. The possibilities were pretty endless. Except that in practise, only a few tens of options were used.

The place I worked, they used to calculate these dealing calendars manually, for each fund, a year at a time. Just this process, over about 1,500 funds, took somebody about six months every year. And somebody else, another six months to check.

So they wanted to build a system which would automate the process. After all, it’s simple enough to have a computer just apply a set of rules and tag one date onto the last.

So I built an engine so they could do this. You needed to tell it the last dealing date, and once it had this, it would apply the rules for the fund and calculate the next dealinng date. So you can imagine, you could run this engine again and again, on each fund, to calculate dealing calendars years in advance.

The trickiest problem was in capturing all of these rules. Capturing them flexibly enough so as to allow many different types of rules to exist, but rigidly enough so the rule could be used to calculate a dealing date.

One of the oe other problem was, what if the engine came up with a non-banking day, for example a weekend, or New Year’s Day?

Plus, the funds were based in different countries/currencies. Different currencies have different ideas about what day is and isn’t a bank holiday. So straight away, you’re having to also capture bank holidays against all the currencies (although funds tended to be only set up in the main half-dozen currencies).

It had to take all of this into account, and more besides.

We got there in the end. It this sounds quite boring to you, that’s because it was. Working with banks was quite well-paid, but it wasn’t rocket science. The reason it paid well was because people had to be meticulous*. A lot of the time you would be working on something to improve a manual process. Either to make it quicker, or less error-prone (in this case, both). Banks are quite a specialised environment, in that respect. In later years, when I was hiring people, previous banking experience was always a big factor, just because it showed that somebody was used to that environment.

* some banks are more meticulous than others!

A Scary Place

Yesterday I didn’t do much, so I had a bit of time/inclination to write. For many of the prepared posts I write (as opposed to responses), I like to just save them as Drafts, then put them live maybe the next day. This gives me overnight, at least, to think about any tweaks, and also means that the final proof reading will be performed with a fresh pair of eyes. So, the post got its final check this morning, and here goes.

From having read my posts, would any of you believe that I have been a published author since very early on in my working life? Okay, not really in that sense! Let me explain:

My very first job out of college was with the UK’s Atomic Energy Authority. It was basically civil service – you can imagine that in the early days, atomic energy was very closely linked to government and military. By the time I jumped on board, quite a bit of separation had happened, but a lot of the structures etc. still followed the civil service’s. By the time I was on board, the Atomic Energy Authority was looking very hard into how it could turn the skills it had picked up in the search for atomic energy, into skills which paid the bills. So I ended up working in a field completely unrelated to atomic energy, in the field of high-energy electricity.

In particular, I worked in the Space Applications Department. Yep. High-energy electrical appications for space-related activities. So I can quite truthfully say that I was once a rocket scientist!

Thinking about it, space-related electricity has developed along a very similar trajectory to autos, albeit with a lag in there. We started with chemical (i.e. petrol) engines, and are moving gradually (very gradually!) toward electric propulsion. Exactly the same in space. Back in the Eighties, there was a lot of development and testing going on of electric engines. Did you know that when a satellite goes up into space, it doesn’t just sit nicely in its orbit, but wobbles about a bit? In fact, it wobbles in a kind-of figure of eight. In theory, electric engines were perfect for reducing that wobble to a minimum. That is one of the areas where we came in.

One of the benefits of coming out of the atomic business was the amount of hardware we inherited. In particular, there were some very large testing tanks, which we could put under a very high vacuum, to simulate, er, space! And very large, in terms of being some of the largest in Europe. Ideal for testing electric engines!

During my time, personal computers were just starting to come along. Somebody had the bright idea of putting several probes into one of these tanks, then controlling them by computer. Of course, at this time, we had to do all this ourselves. Bearing in mind this was back in 1990, we were really state of the art – for example, we were using fiber-optic cabling to communicate between things, because using regular copper wire was just too slow. Current broadband technology, but thirty years ago! (It is a lot cheaper now.)

There were, of course, mishaps along the way. We started off with nylon belt drives, which promptly melted when put near one of these engines! It took a good twenty minutes before anybody noticed, by which time the probe had well and truly melted – in the promimity of one of these engines, you’re in a very nasty environment, and nobody anticipated the temperatures which would be involved. Or rather, nobody anticipated this probe being stuck right in front of one of these engines! When we finally got in to examine this “probe”, we just found a big, melted slab of aluminium! But once we corrected the mishaps, we ended up with a working system, complete with fully-functioning probes.

Within the company, I was employed as a graduate scientist. Lowest of the low – all I really brought to the party was a freshly-earned degree. On this project, I wrote the software to drive all these probes, and to collect data from them. I’d hardly even touched a computer before then, I just happened to be in the right place at the right time. I think back and cringe at some of the stuff I hacked out back then, but it all hung together (somehow), the project revealed to me that this was something I wanted to be doing full-time, and gave me a very solid mastery of the technology. And it only took me until my mid-twenties, to work all this out!

With all these probes on board, we started collecting data. Lots of data. It soon became apparent that my second software project would be to write something which could analyse all this data! And it soon became clear that this second project would be far bigger than the first. Bearing in mind that I was still very green, it was all good experience. God knows whatever happened to that software (I expect it ended up in a bin many years ago) but I found something on Wikipedia which gave an indication of the type of analysis I did:

Okay, the data in my plots would have been completely different, but the idea – turning it into a pretty graph – was the same. It allowed everybody to visualise what was going on – otherwise we were just presenting lots and lots of numbers to people.

Although the whole project was performed on a commercial basis – there was a lot we couldn’t talk about – we were able, at least, to discuss some high-level aspects of it, including at various industry conferences and spin-off publications. Some of my graphs were included in the papers, and so that is how I became a co-author!

Not bad for my very first job, eh? It’s funny, because I subsequently had jobs in banks which easily paid 10x that of the first job, but I look back on this job as having the most interesting subject matter. Maybe a case of rose-tinted glasses? But while a lot of work I have subsequently performed has been in a virtual world, imagining solutions to problems, this project was ultimately dealing with something physical, something real, something tangible, one of these electric engines.

I used this first job as a springboard to become involved, full-time, in software development, and after these projects, I moved on from the space industry, never to return. But I do wonder sometimes whether the stuff I did eventually helped these engines to fly.

So, next time you happen to be passing your nearest technical library, you might want to have a look through some old journals from the International Electric Propulsion Conference paproceedings, or from the American Institute of Aeronautics and Astronautics, and look me up! Which finally brings me full circle to my post’s title, for the internet is indeed a very scary place. It never forgets! I was going to round off my post today with a few references to the papers I once wrote, confident that this far downstream, nobody would take the slightest interest. But I typed each of them into Google, and found the original bloody papers themselves, from thirty years ago! Which of course, are published under my real name…

So, I’m afraid you’ll have to just take my word for it!

Costing Projects

Oftentimes in my career, I’ve been asked to produce project plans. I have a few simple rules I worked by, but they were not rocket science and I usually just ground them out.

By grinding them out, it was basically sitting down and working out, as best I could, all the different little tasks which went into the whole project, and, as best I could guess, the duration of each task. From there, just basically adding up the numbers together. The end goal was to be able to say how many man-years of effort would be required. I let other people juggle with the number of people involved, and, frankly, a lot of the time it really was no more than juggling!

A lot of tasks were repeated across the board. For example, every task finished with a unit test, so “unit test” was always a sub-task. A unit test is simply testing the part in isolation. But again, unless you realised this and took account of it, you wouldn’t allocate enough time for it.

I had a basic rule that a task would take a minimum of half a day. Sometimes a task might be a single change to a single line of code, so a half-day was overkill. But over the course of the project, it averaged itself out. Conversely, if I costed a task at more than a fortnight, I knew I needed to break that task down into smaller parts to get a better idea. Overall, there were normally the same feelings on each project – when you first worked out the numbers, you, and other people, would say “crikey, will it really take that long???” because the number you calculated would always exceed your gut feel. But at the end of a project, I was generally happy with my initial estimates, although requirements invariably changed during the course of the project, par for the course.  After all, because the duration of an entire project was just the sum of these small tasks, for each task if would have been very difficult to miscalculate by all that much. So, unless you hadn’t thought of all the tasks… Project Managers would often be not happy at the end result, but that was their problem – ultimately tweaking the numbers at this point would just have been wishful thinking – they’d have the math right there in front of them, so it’d take a degree of bravery (foolhardiness) to ignore it in favour of their gut. But some of them did, and they invariably got burned. If my advice had been wrong I’d have been concerned, but if they’d chosen to ignore my advice and subsequently got it wrong, that was their problem.

In my last few years, I met another guy who claimed he could estimate the cost of projects without grinding things out as I did. Quite funny, really, I’d regularly meet people in my career who could do things more efficiently than I could. For some reason, I survived despite being so inefficient. This guy just used his gut feeling. The difference, as always, is the working out – the documentation. My detail would be used as the basis of the plan that would span the entire project, the final number that I produced was just the headline. I was fortunate, I suppose, because I encountered this behaviour early on in my career and developed coping strategies – the guy, often parachuted in, who tells you. ever so nicely, that what you’ve been doing is crap, so you just had to cover your backside.