With the fuss about the Log4Shell vulnerability finally dying down, it’s time to step back and take a good, long think about what happened and, more importantly, what can be done to stop it from happening again.

Sadly the prognosis is not good. The tl;dr is both simple and obvious: we simultaneously like free stuff and getting paid for our own work.

Most companies treat open source software exactly the same as commercial software but with a much lower purchase cost. When the software goes wrong, we want someone else to fix it for us. Unfortunately, sometimes we don’t even know where the software comes from. In the case of log4j, it’s run by volunteers. There is no 24/7 help desk with eager employees waiting to take your call.

As is common these days, I was complaining about something on Twitter.

https://twitter.com/sdarlington/status/1523588282986033152

It’s easy to complain about security practices which, if I’m honest, is why I do it. But there is an important point, one that I included in a follow-up tweet:

https://twitter.com/sdarlington/status/1523602044791115776?s=61&t=69wO28ER8NUpssCyeNkqJw

The security team in many companies models itself on the DUP. Say no to everything. But – and this is the key – offer no alternative.

The tweet above is about passwords but I see it everywhere. Another common one is transferring files. I understand why sharing files can be problematic. Confidential data can be exported, either deliberately or accidentally. Viruses can be imported. Security defects can be exploited.

I stumbled across “On git and cognitive load” and it got me thinking. That post led me to “Oh shit, git!?!” and that got me thinking further.

But first, a disclaimer: this is a post more about having perspective than providing answers. If I knew a better way, I’d be doing it.

The first blog argues that git is difficult to use. Further, that it was designed with the limitations of the time and that those limitations are no longer valid constraints. A decentralised system was required when poor network connections were the norm. Now we have cloud providers and ridiculous amounts of bandwidth.

1. The underlying technology, blockchain, might have uses but a currency isn’t it
2. Many crypto experts were surprised when governments said that profits from trading in digital currencies were taxable in the same way that as any other capital gains. Why would this be a surprise?
3. They also claim that it’s great because it’s decentralised. Except, a few companies do a vast percentage of all business meaning that in reality it’s not very well distributed
4. Much of traditional financial services is not centralised either. There’s no “exchange” for currency trading, for example
5. The lack of regulation in crypto is considered an advantage, right until the point that one of the few exchanges (see above point about decentralisation) is in trouble and stops accepting sell orders. Regulation is there for a reason
6. Decentralisation is supposed to democratise trading. Except, trading in crypto is surprisingly expensive. And, just like traditional finance, quickly gets complicated
7. And it’s slow
8. Many of crypto’s biggest promoters are economically illiterate
9. It’s basically a pyramid scheme
10. Many crypto “experts” claim that it’s possible to reduce the risk of transactions with certain complications. They tend not to use the word “hedging” which is what this is. It’s something that the “old-fashioned” financial services companies have been doing for ever
11. It’s almost like they don’t understand traditional financial markets
12. They says it’s progressive and about freedom, but it entrenches existing hierarchies, if anything, more effectively than the existing systems
13. Except for the use of blockchain, there’s not a lot that’s new. For traditional financial services, regulation means that the worst scams are banned for retail inventors. The “Wild West” of crypto isn’t a feature
14. And no, this piece is not intended as a defence of the traditional financial services companies or their regulators. They are far from ideal

I greatly enjoyed Graham Lee’s series of posts about specialisation versus generalisation in software engineering¹, quite possibly because it’s me.

My background is a little different from Lee’s, though, so I thought it was worth sharing.

I have a two tier experience². With a few minor blips, Unix has been a constant technology underpinning since my first year at university. I started using Linux around the time 1.0 was released. I got a Mac when — or possibly before — OS X was ready for mainstream use because it was Unix with a nice UI. At work I’ve seen the change from big Solaris and HP-UX machines, to Linux, to containerised applications (which are normally based on minimal Linux distributions). Sure, the different Unix variants are not exactly the same, but most of them have something bash-like and ls does the same thing everywhere, even if the more esoteric options vary.

I’m still fascinated by the computers of the eighties. Without well known standards, every machine was different, not only from those of other manufacturers but also older machines from the same company. As as user it was terrible. Back the wrong horse and you’d be stuck with a working computer with no software and no one else to share your disappointment with.

But looking back, there’s a huge diversity of ideas all leaping onto the market in just a few years. Naturally, some of those ideas were terrible. Many machines were rushed and buggy, precisely because there was so much competition. Going on sale at the right time could make or break a machine.

After university, when I first started working, I jealously noticed people leaving their desks and attending meetings. I was left sitting at my desk, bashing out code. What was going on? What exciting things were being discussed without me? Sometimes they’d come back from the meeting and ask a random question. It was all very mysterious.

A while later I started getting invited to these meetings. I found what was being discussed. I discovered the mystery.

As the Downing Street clock reaches zero, as Whitehall is lit in red, white and blue, as the Union Jacks blanket Parliament Square, I wanted to commemorate Brexit actually happening.

In fact, I’ve wanted to say something about Brexit since before the referendum, but what is there to say that’s new? But original or not, I needed to write something.

Far from a celebration, 11pm on 31st January 2020 marks the culmination of years of misdirected anger and politicians harnessing that for their own personal gain.

Here’s something I’ve seen a few times recently: a startup issues a patch for a critical issue seen by one of their large customers. The “enterprise,” however, takes a week to install and test it. Clearly, the startup concludes, if it takes a week to try a patch it can’t be that urgent or the staff are dumb, or, quite likely, both.

Separately, we all know that a big difference between a startup and an enterprise is process. So why do people suddenly get angry and start to lack empathy when that difference is exposed?

When I see a company that has an “innovation team” or a “chief innovation officer” I immediately understand that it’s not the kind of company I want to work for.

Innovation isn’t found in a particular team, person or department. It’s your culture.

If you need a special team outside the normal management structure to innovate, what does that say?