Category Archives: Computing

Articles about computers and the IT industry.

Security by Scapegoat

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

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:

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.

So yes, blocking OneDrive or DropBox is part of the job. What is missing is a legitimate alternative.

Security teams should be enabling staff to safely perform their jobs. Instead, they block the insecure methods and stop.

If I need to share a file or remember a complex password and you don’t provide suitable tools, you did not prevent a security problem. You forced people to write their password on a PostIt note and stick it on their monitor. You pushed someone to use some dodgy new file sharing service that you haven’t heard of.

In the attempts to make the system more secure, you, best case, prevented someone from doing their job. Worst case, you pushed someone into doing something insecure.

In either case, you effectively delegated security to everyone else.

iOS 16 and watchOS 9

As I’ve done on many previous occasions, I thought I’d write a few words about the latest Apple operating systems. I’m sure you’ve seen the reviews and possibly even upgraded yourself, so I’ll keep this brief! This is not intended to be complete; just a few highlights from my point of view.

First: they’re both stable. I’ve not seen any significant problems this year. If you were happy with iOS 15 and watchOS 8, and you’re able to, there’s no good reason not to upgrade.

For the most part, changes are subtle and either easy to ignore or genuine improvements.

The high-profile changes, such as the lock screen, fall somewhere between the two. Having widgets on the home screen is nice, but I’ve not found it to be a game-changer yet. Maybe I need to find the right widgets?

Under “subtle” is the enhanced “Focus” mode. Last year you could silence notifications by using the correct mode. I have a “Work” focus, where most notifications are disabled and a “Sleep” focus, where almost everything is disabled.

iOS 16 enhances this. For example, I now have a “Personal” focus where all my work stuff is disabled. That means notifications, like last year, but it’s also extended to the inside of apps. If I open Mail or Calendar, I don’t see any work emails or meetings. This is flipped in my “Work” focus.

This may take some tuning, but, I think, it is likely to have more impact than the shiny new home screen, tweaks in the Weather app or the ability to unsend Messages. All of these, to be clear, are nice improvements.

The changes in watchOS are also quite subtle. The improvements I like the most so far are all in the Workouts app. There is much more information visible while you’re running and in the partner iPhone app. You can programme in a pace, time or distance, and have the watch keep you appraised of progress during the run. The first time I used the “Pace” mode, I had my best Parkrun result of the year. Coincidence? (Probably. But for the sake of the narrative, let’s pretend otherwise.)

It’s unfortunate that some of the things I was looking forward to are not available on the Series 4. I’m not surprised as such, but it might have been nice if it had been documented on Apple’s website.

Like the phone, there are a lot of other updates, too. Notifications are nicer. I have a different watch face (I moved from California to Metropolitan). But if we’re talking impact, I think that’s the Workout app.

tl;dr? Nice, stable updates. Nothing earth-shattering but great incremental improvements. Lots to like.

Is git too hard

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.

The second post notes that people keep getting themselves into a bind, with some helpful tips on extricating yourself from those situations.

The fun thing to note here is the kinds of problems that we need to solve with git:

  • I missed a file from a commit
  • I put the wrong commit message
  • I put committed a change on the wrong branch
  • I need to remove a commit

To me, the fascinating thing about all of these things is that in the systems that came before git, it wasn’t possible to do any of them. Once you made a commit in Subversion, that was it. It was in the repository and immutable1.

Missed a file from a commit? Shrug

Committed something you shouldn’t have? Tough2

Also, in the late 2000s, when git was just starting to take off, an argument against switching was that the commit history was not sacrosanct; the record could be changed. Subversion’s behaviour was a feature not a bug.

In the next decade, we’ve changed mindset so much that the ability to change a commit is now expected, even when we know that it can cause problems.

Similarly, while git’s distributed nature certainly adds to its complexity, it’s both fantastically useful and not a source of its worst behaviours. I can sit on a plane with no internet access and still have most features. I can move my repo between cloud providers or host my own. When my broadband or AWS goes down, I can continue working.

Maybe rather than move to a proprietary, cloud-based source control system — which is what the author of the first piece is really advocating — we should remember what we gained when we moved last time.

Git is tricky. But rather than return to a centralised system maybe we should fix git’s user interface. Being able to fix past commits is useful, though we we should be able to do so without messing up our code or, especially, the code repository.

  1. As ever, it was always possible to hack the repo but in my experience this was frowned upon. ↩︎
  2. I do remember a time when someone committed a password. It took a lot of time and expertise to scrub it from the history. ↩︎

The Count of Anti-Crypto

  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

Why Enterprise Software is Bloated

I confess that I’ve stolen the title of the post from elsewhere. My objective here is not to detract from that post, which is great, but to build on a few points that I thought it was going to make but didn’t. To make it clear where I’m coming from, here’s a Tweet that I wrote some time before I read that blog:

People who complain that “enterprise” software is too expensive have clearly never come across the bizarre, arbitrary and nonsensical policies and rules these companies have. It’s not unusual to have two customers with contradictory policies.

Alex’s post assumes that bloat is unnecessary and could be optimised away with better engineering. There are always counter-examples, but, in general, this is not my experience.

The key is to realise two facts:

  1. Large companies have lots of rules and procedures
  2. Large companies have a lot of leverage over software companies

My favourite rules and processes are always about corporate security:

The game of cat and mouse begins: I need to send a file to a client, but which method will actually make it through their corporate security? So far I’m down 2–0 but I’m not giving up yet.

Corporate security is focused very much on stopping Bad Things from happening. Undoubtedly that’s one part of the job. The part that usually gets forgotten is to allow people to do their jobs securely. Without these “safe routes,” the security is making everyone’s life harder and increasing costs but without improving security.

Here’s a lightly fictionalised example. A client has a production outage. We need to see their log files to diagnose the problem. Dropbox, Box and Google Drive are all blocked. They don’t have a corporate file share. It’s not possible to email them, because the logs are large and ZIP files are forbidden. We can’t screen share, since they blocked Zoom (our tool) and corporate policy means they can’t open a Team’s call with outside people. There is a special dispensation for this, but it’s only available for client-facing staff. And, in any case, needs to be applied for in advance. In the end, we went Old Skool, zipped the files and renamed them with a “TXT” file extension and that worked.

There’s a lot to unpack here. First: the security measures didn’t work. Despite the obstacles, we managed to transfer the files. It just took multiple well paid people a lot of time to figure out. There was no known supported tool available to facilitate this use case which, let’s not forget, was an outage of one of their production systems, something that customers pay them actual money to be able to access.

As ever, the individual rules make some sense, but together they make a system that doesn’t work for anyone. It annoys staff, adds delays to tasks and in many cases does not work anyway.

Let’s circle back to the original question: why is enterprise software bloated?

The short answer is that vendors need to be able to support enterprises despite all that unique processes. A task, like copying log files, that should take minutes might take hours. Ultimately that needs to be paid for.

Many of the processes and procedures are unique to an individual enterprise. This means that the vendor has no option but to write custom software to accommodate them. These changes get folded back into the product and every other customer gets a copy of them, but hidden behind a feature flag.

Multiply this by every customer and you end up with a vast number of options, the majority of which are not used by most customers. It’s a bit crazy. It’s bloated, hard to keep track of and hard for the vendor to test.

If everyone recognises the problem, what is the solution?

Some companies just lay down the law: this is the right way to do something; take it or leave it. You can do this for consumer software or if you have millions of customers. There’s only so much negotiation you can do with Microsoft for your Windows or Office licence.

Companies that do this for “enterprise” software tend not to be very successful. There’s a reason that Google Cloud is a distant third, well behind AWS and Azure.

You can make “consultingware,” that is, software with a core that it heavily modified for each customer. At a certain point you don’t even have a product any more, with disadvantages for both the vendor and the user.

Or you can make a single product with switches that enable or disable all these esoteric options. Either way, all your customers end up paying extra for the privilege.

In the end, as long as big companies continue to customise their environments in mutually incompatible ways, “enterprise software” is going to be expensive and bloated.

Generalist Software Engineering

I greatly enjoyed Graham Lee’s series of posts about specialisation versus generalisation in software engineering1, 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 experience2. 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 should say that this is largely a preference. I don’t like Windows but that’s not an objective criticism. I do joke about it from time to time3 and I do admit the limits on my knowledge, but I don’t refuse to work with it!

Sadly, being a long-time Unix user is not a career.

I started my career at a “pure” consulting company. Each client I worked with wanted to do something different and I ended up using varied technology stacks. This was great from a “generalist” point of view. I flitted from Uniface to PL/SQL to Perl to Oracle Applications4, but beyond abstract concepts like “problem solving” I didn’t get anything like a transferable skill. The obvious path would have been management but that wasn’t where I wanted to go. I saw friends and colleagues specialising, and earning considerably more money for the privilege.

I appreciate that I’m likely leaving money on the table, but I stumbled on a solution that works for me: being part of the field engineering team of software vendors.

Being in the field team means that I work directly with customers and they end up wanting to do all kinds of things. In a year I can work with dozens of use cases, satisfying my need for novelty. At an end-user, I’d be looking at a small number of use cases the whole time.

At the same time, there is also a degree of specialisation. By working with the same product all the time, I can become The Expert in it and some adjacent technologies. For example, I’m pretty good with Kubernetes and Java these days. I need to write code and sketch out software architectures. My knowledge has to be deep enough to demonstrate credibility but I don’t have to build production code. Additionally, I can bring domain expertise. I wouldn’t sell myself purely on my banking knowledge, but it’s a nice value add.

This may not be the solution for you. There may even be better options for me that I’ve not found yet! But I thought it was worth documenting my experience, since most of the articles I’ve seen are for more traditional “software engineering” or management roles. Other positions are out there if you know where to look.

  1. Though I wasn’t able to write anything about it in a timely manner! ↩︎
  2. Maybe second tier too, but in this case I mean there are at least two layers. ↩︎
  3. There’s a Dilbert cartoon I use occasionally. This from before Adams went off the rails. ↩︎
  4. Whether you’d want to make a career out of any of those technologies is a different story. ↩︎