Tag Archives: Friday funnies

Murex Easter eggs

Murex Easter eggs? Here’s one question that comes back from time to time and as it is chocolate season this weekend, So before you start punishing your liver with all the cocoa you can get your hands on, have a read!

Murex Easter eggs – Definition and Considerations

So for whoever never heard of Easter eggs in a software, they’re tiny features (or often games) which are hidden and can be triggered by a specific series of keystrokes or clicks. For instance, if you are using chrome, when internet is disconnected you get the pic of a dinosaur. Press space bar then and the dinosaur starts running across the desert.

Alright, so to the question: are there Easters in Murex? The answer is I don’t know. So far I haven’t seen any actual ones (but I’ve got more things to share or this post would be incredibly short!) but I’m curious if there are any. One one side, Murex is a software used to trade and supports critical services. So I’m not sure customers would really appreciate that some of the development time and code is used for coding Easter eggs. Especially if you get a bug/regression because of a Doom-like game hidden in the software. On the other hand, you have developers spending days and nights on their keyboards writing lines after lines of codes, one could assume that among all these developers, one would sneak in something funny just to release some pressure.

So if you know of actual Easter eggs, please share otherwise I’ll move on to some features which are close to Easter eggs

Murex Easter eggs – Murex typo

While there are quite a few typos in Murex, here’s an example of a typical one:

– Fx settings: Use of the word Inhibate. Of course if you activate, you can then Inhibate… Not really a word in English but you get the meaning.

Murex Easter eggs – Undocumented feature

I did not test it on more recent Murex versions, but when trying to define Commodity spot indices, the label box would not appear. You can’t save it or anything without populating the non existing box. The solution? Change the index type once the definition box is opened and revert back to spot index. The label box is back!

Murex Easter eggs – And probably the best one

This one was developed on purpose and it is probably the closest thing you can get to an Easter egg (after your omit of course the Hawaian beach feeling from the option series). Anyway, the purpose of that development was to make it easier for people doing comparison testing to know which Murex screen was running a different version.

The problem of that function, it was certainly coded by someone high on LSD or effectively color blind (as such, Murex would be just 50 shades of Grey(Sorry for that one)). The color selected could have been pastel or slightly different, but no, the color mix is what you get from a leprechaun after St Patrick’s night when he partied high on rainbows. Best is to try it for yourself but brace yourself for seizure!

In your session arguments, add /FREAKMODE and start tasting the rainbow!

If you have some pearls to share, please do but in the meantime Happy Easter!!

Murex interview – What NOT to do

During my time at Murex, I had to recruit quite a few people and I faced different profiles, so have a read, smile and relax. For an interview you need to be prepared and at your best. So here are some pitfalls you can easily dodge.

Murex Interview – The Test

There is a test! Yes, it’s best to revisit your finance/programming/math lessons so everything is fresh and handy in your mind. You have 1 hour to do your best.

I think I have to give the golden crown to one candidate (to whom I already told there was a test): he came in, sat in the room and I left him to work on his test. 10 minutes later, he came out, handed me back the test (nothing written on it, not even his name, perfect to give to the next candidate). “I don’t think I’m suited for this role”. At least he was honest.

Second place goes to someone we ended recruiting because that person is actually really good. But when asked to give a simple definition, there was actually a fair bit of writing. 1 page! In small characters when 1 sentence could have sufficed. Know that we discuss with you the answers you give and we can easily tell if you understand or not

Last place goes to the bullshitter. Answers were very generic and could not make much sense out of them. When asking him for more details, he told us that he did not believe that it was so important to know things in details, you can always talk your way out. Well, he managed to talk his way out of the interview.

Murex interview – Presentation

Job interview is a two way street, you discover the company and people who are looking to recruit BUT they also discover you and who you are.

Once we had this candidate who was just looking at the table, did not even look at one of us once. And his answers were short when not single worded. Not matter what we tried to get him to relax, we failed miserably and we could not get him to open up. As many Murex roles are customer facing, being comfortable talking to people is important!

When you present yourself, it’s important to explain why Murex is of interest to you and especially on the longer run. Some people (yes it happened more than once) were upfront enough to mention that they were looking at Murex just as a stepping stone in their career. Definitely not a smart move!

Murex interview – The good surprises

But sometimes you get good surprises. The feeling (usually straight away) that you found a gem, someone that would fit perfectly the bill. And the interview/test will effectively confirm it.
I often pondered if it was simply the first impression that decided how an interview would go but I do believe that the Murex test makes things actually fairer. Someone with very good presentation but lacking knowledge would effectively be at a disadvantage after the test. Someone not so good at presenting can gain some confidence and feel more on familiar ground thanks to the test.
After that if you’re not good at presenting and don’t know much, maybe it’s better not to take the interview!


The devil is in the details

Whoever worked for some time with Murex must have heard that sentence at least once : “The devil is in the details”. So as we’re Friday and try to relax before the weekend, let’s put it under the spotlight and have a good laugh at its expenses.

The devil is in the details – What does it mean?

The idea behind that sentence is to say that details are important. In practice, people tend to use it to escape answering a question or request.
Let’s take an example of a request (note the 4 first words from the request, they set a mood):

– It must be easy to have a full explanation of my PL

Either you go with yes and you’re in for many iterations because PL explanation is never simple especially when the portfolio contains different types of trades. Top that with choosing the right time to close the portfolio and the market data and you realize it is nowhere near easy.

If you reply: “Must be, but the devil is in the details”. You more or less killed the request. The requester will then need to detail exactly what he wants and you’re more or less letting him figure out what is the next step. It’s a good silver bullet (especially on Friday afternoon) but should be used with parsimony.

The devil is in the details – The machine gun

The problem is that some people overuse it to the point that they dodge all questions.
In a 1 hour meeting, I’ve once heard it 4 times! That’s a lot. To the person’s defense, they were the wrong person asked. But the other party got annoyed as they could not get anything out from them and I believe that the meeting could have been much more productive by answering differently.

The constructive method

Instead of using that sentence, the best is to offer a path to solution. If you’re the wrong person asked and don’t know all the details, just point it out and propose to get in touch or to gather the information from them.
Similarly to the question about PL explanation, I would rather start asking about the details: “Do you just have this type of product in your portfolio?” or “What effects you’re after in your explanation?” Of course, experience is then needed to be able to drill into it.

I think it is better to show people that their request is not simple after all and they need to refine their requirements. As Murex expert, people need to see you as a solution provider.
And sometimes I even go faster where I actually accept the request but based on my knowledge I tend to know quite well what they want. If you can then deliver 95-100% of the request, you’re on your way to build yourself a good rep.

Murex bugs: Funny stories

For this Friday, I’ve decided to write about the bad and ugly: Murex bugs!

All software contains bugs (even good old Notepad). I won’t go into details about how to debug them or anything like that. Today, I’ll be interested more in the exotic ones. The ones that as a customer, you report knowing that:

  1. No one will believe you
  2. They can’t be reproduced
  3. They always happen when you’re about to go on weekend

As a Murex consultant:

  1. No one will believe you
  2. Your bug will tank in severity and priority
  3. You’re in for a debugging session

The problems with these bugs is that while rare they do happen and are hard to pinpoint.

I’ll start with my number one in weirdness:

Exotic Murex bug number 1: The 1 week curse of bermudan swaption.

At my desk and got a call: simulation is crashing for the IRO exotic book. Alright, usual checks and impossible to trace down what is causing the issue. On-site visit, can reproduce the crash and as all debugging methods failed, had to break down the portfolio till I isolated 1 deal. A simple bermudan swaption expiring in 2025 (at the time we we were in 2005? 2006?). Long story short: the root cause of the crash was the expiry date. If it was falling within 1 week in 2025 it was crashing! Any bermudan that would mature during that week would crash.

The problem was a memory corruption. It was not happening on every server OS. And in the end, a debug binary showed the developer where to fix his code.
Problem solved but when good luck explaining to a trader he should not have bermudan maturing during that week till it gets patched!

Number 2 in my experience of funny Murex bugs:

Exotic Murex bug number 2: Computer says no

When trying to open trade number 100, trade number 99 gets opened. Trade number 99 opens normally. The two trades were not linked (nice try for those who thought it could have been the case). Whatever we were doing, we could not get to open trade 100 from the browse. If we were querying trade 100 alone, then it would open fine.
All traces were showing that we were querying trade 99. I had given up when a PAC guy came up with an idea (bless him for being around that day!). The issue was the java version of the client being too old and a java bug was causing the focus to go on another trade.
Why was it happening only on that trade? I will never know but the problem did disappear with the correct java version.

Last one for today:

Exotic Murex bug number 3: When consolidated simulation is right and detailed wrong

When you start working on Murex, there are some Murexian laws you learn quickly one of them being that: Always trust the detailed simulation over the consolidated one.

We got a call from a trader complaining that his detailed simulation was wrong but the consolidated one was correct. Back to rule number 1 above, we did not believe him at all but we went to have a look with him.

And truth was: detailed was indeed incorrect and conso was right!

The issue was that the workflow was playing with the trades entered, somehow the trader was losing access rights to the transaction and were no longer loaded in a detailed simulation. But the warehouse was correctly aggregating the trade and showing the right position.

A quick fix in the workflow status and updating the existing trades fixed the issue and let us move on.


Just to keep things in perspective, such strange bugs occurs less than 1% of the time. That’s what keeps them exotic and every Murex expert after few years will always have couple of similar stories to tell.

And exotic or not remember, as any bug you need to:

Do your part: smash bugs!
Do your part: smash bugs!

End of day – The joy of night shifts!

The terror of everyone working in this industry: end of day and especially their crashes. Because end of days happen at nights, most of the time everything is automated. Reports, market data copy, accounting generation are all these lovely activities which happen during the night and which are supposed to be a well-oiled mechanic.

Murex has come a long way in terms of End of day issues (EOD for the acronym lovers). When I started, the big fear was the future rollout date as the system would often crash and one would need to sort it out manually, undo what was done and redo manually. Fortunately in 15 years,  if the EODs have become more complex due to stronger requirements, the system has proven to be also a lot more reliable and resilient.

I won’t cover how to debug these issues (that was another post earlier, the search function is your friend!), but the funny cases (well, looking at them now is funny) that I had encounter.

Calling my wife. A customer had my wife number (I had given it to them when my phone was broken) but few years after, they were still calling her for EOD issues. Quite a classic, when it’s 11pm and my wife is awoken with questions she can’t understand.

Missing cutoff times. Such a big stress the first times. GL entries need to be posted by 12am or… Your first times, guesses are that it is the end of the world, bank will go bust, another black Thursday will happen. So when an issue happens, massive panic and how to get everything rolling before the cutoff. Later you learn that the world will keep going if the data to the ledger is late. Not ideal, but not a cause for WW3.

Leveraging of someone’s visit. This happened actually quite a few times. When visiting a customer and the day is closing, I got a call from the office asking to help someone for a small problem. I then spent few hours (finishing just before midnight) to solve that “small” problem that was end of day related. Other variations include saying bye to everyone and being asked if I could help on this tiny matter.

This being said, that’s an aspect of the job I like (and I hate as well). You need to be always on your toes and it’s actually good fun to be at the customer that late: very few people in (and most lights turned off) and quite a relaxed atmosphere.

And you? How much did you enjoy your night shifts?

Having fun with the system

For a lighter mood this Friday, let’s talk about the ways to have fun with the system. Murex is a complex system, not always easy to configure or to get familiar with.

But who says complex system also says lots of places to put this funny little touch that will bring a smile when spotted.

Here are a few I’ve encountered:

  • Classic but always good: the funny comment in code (pretrade or stored procedure for example). One of the best, was /* Added to please Ms Princess while it serves no purpose */ Had to tell that person that this code was going to prod and taking it off would probably be a good idea
  • UDF consistency rules messages: “Why did you forget to enter XXX” (this was when entering bonds). I could tell the person who wrote that bit must have been so frustrated that they had to vent some anger into the message. Had a smile on that one building back the story
  • Name of views and filters. One of my ex-colleagues was always putting insults into his filter labels (and normally was deleting them after use). Well, let’s say that some DBs still have these words on few places
  • Description fields. I have to admit that this one is best used on static data that only support people have accessed to, not everyone might agree on that one!
  • Documentation and label of objects used. Remembered that bond called NOTABOND, classic but gold 🙂

Did you encounter some too? Did you put some yourselves (voluntarily or not)?

Have a good weekend!

Another Friday funny… Christmas style

It’s December 24, it’s 6.30pm, I’m going into the deli shop to buy the last things I need for our Christmas dinner.

Phone rings…

“Hi, we have a production DB issues, it says database is corrupt, reload a previous dump”

This is of course in production and talking a bit about the problem it is a deep DB issue and the dbas are on it but struggling.

Fortunately, I found the right team in Murex to help and they got a solution in their timezone much before their end of the afternoon.
But the dbas on the customer side had to work on 25 and 26 to get it all fixed and they did.

I think all Murex consultants have these horror stories when the last thing you need is a production issue and it does happen.

Since then, I have to admit that during each public holidays I’ve got that shiver down my spine when the phone rings!

Friday funny story

Working with financial markets means often stress and pressure to deliver under a short timeframe.

So trying to push some of the stories I’ve lived (hopefully funny for you too) to lighten the mood just before the weekend.

This story happened while working on a project. The character here is a brilliant person, very smart and quick to understand but even the best sometimes have their weaknesses.

So I get a call from that person asking me what happens when the trade number ID gets above 10,000 and given that the size of the field is 10 digits. So my first answer is 10,001 but I suspected that there was some confusion between 10 digits and 10 times 1,000. Anyway the person hangs up and 20 minutes later I get a call that the project is threatened.

Had to get there and explain everything even if I felt bad that a simple misthinking snowballed into something bigger. Anyway, better to laugh about it now!