On October 31, 2011 MF Global filed for bankruptcy.

On July 27, 2026 I received the latest update listing the 3rd and final distribution to the unsecured creditors. This is strange as the letter states the balance due is zero.

MF Global was only spun off as a distinct business in 2007. Thats 4 years of trading and now 14 years of bankruptcy.

KPMG arrived en-mass to take over the company. Anyone without a support role was instantly dismissed. I heard horror stories of the way the accounts were settled. KPMG would give instructions to the remaining mangers who then told the staff to act. No information ever flowed up. MF Global was the first big case after some new legislation had come in so KPMG wanted to  build the process. It helped that their offices were only 4 buildings away.

In the 3 month extension I had 3 days when any work was required. We started off using our Pluralsight accounts to train at x2 speed. We then started taking phone interviews at our desks. This even allowed is to pass around details of failed interviews to other candidates.

The day after the bankruptcy I got a rather odd call passed through to my desk by reception. Aparently ‘America’s Next Top Model’ wanted to talk to me. This was obviously a recruiter who had paniced when asked who was calling.

We managed to arrange some group meetings with recruiters (one of which set up a session in a nearby pub and bought us all lunch).

I just bought a new apple laptop. At the checkout I was told that the power adapter is a distinct item that I need to buy.

This would make sense if the power supply were a commodity item like for a mobile phone. However Apple decided to require a custom magnetic plug and needs a 70w supply. You can’t argue that you are using standard components then require  a custom one.

There is not even the option to buy a sensible setup where the adapter is a distance from the plug.

I don’t bother with the apple mouse, which has the charging point on the underside so the mouse cannot be used while charging.

I have generally had good results when asking about details of a large codebase. Having tests keeps everyone honest. It may not always get the right answer on the first try and sometimes only does a partial job (find all other instances like the fix you just made).

Things go wrong when working with new external APIs as the AI will have read pote tial fixes that were never implemented. I have found that asking to see the documentation for a feature is a good way to avoid guesses.

In the life of any growing software based company you eventually need to split along domain lines. That way each team can master the area in thier domain.

This does have consequences during and after the split. Who owns what? This has two problem areas: things that belong to multiple teams and things that belong to no one.

Eventually data will end up in an analytics database (sometimes called a data warehouse). The question I have for you is: When was the last time that you checked that this database is accurate?

If many teams are passing data to a system how do you ensure consistency?

You know the ones. The tests that pass 93% of the time and always on the second or third run.

There are several solutuons to this problem.

1. Ignore and rerun
2. Keep tabs and invest in fixing on the third try
3. Aggressivly fix them, frequently asking AI how to recreate the issue.

I have recently started on the third path. Unstable tests kill productivity. They will break when you don’t have the time to spare. Remove them mercylessly.

I play varuous games in my spare time.

Merge Dragons is the one I have been playing longest.

The weekend chsllenges generally involve trying to assemble large items from components that you can mine. This forces you to build a pattern so that you merge the right items at the optimal level. This teaches several of the theory of contraints topics such as reducing wait time at a critical item. In particular you don’t want your dragons to waste time travelling to drop what they mined.

The timed challenges get you to focus on what you need to do. You don’t need to collect everything on the board, just what you need to hit the goal.

The GDPR is a EU ( and now UK law) that relates to handling of Personal Information.

The idea is that individuals own their own data and that it can only be used in ways that they had agreed to use. If you want to use data you need to seek permission and tell the user what you are using it for. Users also have the right to opt out. This does not have to be instant, so extracting your list a month before an email is sent would be fine. Doing so six weeks or more is not.

It includes details that data use must be opted in to. In several cases recently I have seen surveys sent out that have the “add me to your mailing list” autochecked. This is specifically not allowed.

You also can’t pass PII to third parties without either a good business reason or with permission. A good business reason would be passing a delivery address for shipping a product. A bad reason would be selling details to a third party to update a marketing database.

You can also only use the data for the requested purposes. For example Facebook asked for my phone number for account recovery purposes. It would have been a violation if you got a phone call from a market research company on that number.

GDPR has teeth. The fine can be 4% of your global income. Note that is income, not profit.

All that is required is having good practices.

Given that I am working on a relatively large codebase with sigificant size domain model and tests it is surprisingly easy to ask an AI for answers to questions and get useful answers. Sometimes it can multiple passes to get the details right.

For example I was asking about an error message that was found in the logs. My first set of questions where about how to replace this with a useful message for the user. Having done this work the follow up questions really helped.

I asked how is it possible for this error to happen. It found an option that required the user to have the application open in two tabs at once. This allowed me to suggest adding a couple of simple rules to the system to make the error not possible to happen. This was much simpler than the first solution (which was causing problems to be tested). It makes no sense to edit anything other than the latest version and two rules will enforce that.

AI assistance here is helpful, provided that you review the output carefully so it does not attempt to cheat (bypass a failing test rather than fix the cause).

It is also very good at finding and preventing those flaky tests. You know the one that everyone just reruns. If you can stabalise the tests everything gets much faster.

Another benefit has been correcting bottlenecks in CI. By looking at the slowest parts then splitting them up we have dropped our CI build time from 15 mins to 5-7 mins. We uncovered a pointless step that had been costing 5 mins on every build.

Now AI is going to get more expensive over the next few years so take advantage of the current window to simplify the codebase and clean up that tech debt.

I had been skeptical about using AI for development. My first experiences were with the simpler auto-complete options.

These were erratic – it would offer to complete what you were typing but would frequently start using properties and functions that would have been useful, frequently did not exist. The AI had no context and only guessed.

More recently I have been using the more sophisticsted chat option. Here you can give the AI more context about what you want it to do. This seems to work better if you give the AI context and use the plan mode to agree what you are going to get it to help with. Between each of its steps run tests and ensure that you understand all the changes.

This works well when an application has reasonable test coverage. Good practices like TDD really help. Ensure that the test coverage remains high. Refactor things to keep them tidy. The AI will only build the minimal test (one assert). Ensure that you expand the coverage.

AI is great at finding race condition issues or that failure in the middle of a long chain. You may need to interact with alternative solutions if it gets stuck. Treat it as an enthusiastic novice.

I have finally started to use Copilot for development work.

Its a power tool. You can do more faster with it but need to be able to understand what it produces.

It will hallicinate (in one case provide a randomly generated value rather than correct hash).

It is great at finding and suggesting fixes to race conditions in a large codebase.

Now rather than just rerunning a flaky test I ask copilot to find why it is flaky.

If you can still understand the codebase after a transformation then it can be a positive thing. Just generating code and you not understaning it is a problem.

This is where TDD practices really help. The tests can give the AI context about the problem being solved. They also act as guardrails for changes.