My second proudest development moment… and why I regretted it

A couple of years ago I wrote about “my proudest development moment“, where I triumphed over a bullying manager. Well, many years later, but at the same company, my second best development moment occurred. But, equally, why I regretted it – it’s a warning for us all!

But, first, context is needed. Lots of context. Buckle up.

What my role was

At this point in time I worked in an EPoS (Electronic Point of Sale) Applications Development team. Basically, we looked after the company’s till software – fixing it, developing tools for it, that kind of thing. There was a separate development team who wrote all the new stuff, as well as making improvement to what was already there.

Whereas once both team reported into the same senior manager, on the same vertical within the business, now we were both quite estranged from each other, which lead to the age-old issue of “one team creates something and doesn’t then care for it because someone else has to look after it”. Or “throwing it over a wall and running away”, as it’s known. The development team could write code that was poor and buggy but it was our team that ended up responsible for it in the long term.

The development team considered themselves superior and had, over the years, become incredible bureaucratic and tied to rules of their own creation. Nothing happened quickly and everything required a lot of documentation. In comparison, we had little of that.

Tills and deals

Okay, this bit may seem unrelated but very much isn’t.

The tills (the Point of Sale stuff) ran our software which had a very advanced deals system as part of it. Deals are the special offers you see in store. 50% off, Buy One Get One Free (BOGOF), etc.

Each marketing team back at head office could create deals that would then go to a single team who checked it all over and to make sure that different areas of the business weren’t creating overlapping deals that could cause issues. In the end, they stopped this final checking part and that’s key to this story.

Let me invent an example. Let’s say you have some Pantene shampoo. You could have an offer saying that it’s half price. But someone else could have created a 10% off all shampoo deals. And somebody else, buy one get one free for all personal care items. Then there could be a store wide offer of, I don’t know, 5% off everything. That one bottle could trigger all of those offers if you’re not careful.

Once approved, the deal updates were sent down each night, where the till files, which contained all the product details, was updated. For each item that a deal was on, the deal number was added to the till’s live item file. If the item is scanned by the till, it looked up that number on a secondary file which then told it what to do with it.

All this was done overnight whilst the store was closed so that live data was not being changed whilst they were trading.

What went wrong

You remember that shampoo example I gave? Something like that happened one day, where a product in store was triggering so many money off deals that by the end, we OWED the customer money.

It went viral (and by that, I mean the forums on Money Saving Expert, which is much the same).

The business wanted this stopped. Immediately. They couldn’t wait until the usual overnight update process because it was estimated by the end of the day the company may loose up to £100k.

So, they went to the development team who said they could find a way to do but they’d need to do some documentation… do some testing… it would probably take a few weeks. Basically, nothing quick could be done no matter what.

They came to me.

Within a couple of hours it was resolved.

What did I do?

I wrote a quick and dirty program, which I tested on a Point of Sale server that I had on my desk, which overwrote, on the till file, the relevant deal number with 9999. Deal 9999 didn’t exist, so the till tried to look up that deal, couldn’t find it so didn’t do anything further (which is how it was designed to work in this circumstance).

Why did I regret it?

Now the genie was out of the bottle. The business knew this utility of mine existed and, boy, did they use it. Unfortunately, it could only be run manually, so every time it was needed, I was employed to test what they were asking for and then deploy it across the stores. And they were using it a LOT – something designed as a one-off emergency now became something that they were using with abandon, regularly.

And there was no incentive for them to pay the development team to resolve it “properly”.

With some management help we were able to eventually push back, reducing the occurrences and insisting that it got higher management sign-off before proceeding. After all, as this was the “quick and dirty” program I said it was, there was an inherent risk each time it was run that it could do something unexpected.

But, yes, until the day I left this was a noose around my neck, draining a lot of my time. And I’d put good money on that, 9 years later, it’s still being used.