- The underlying technology, blockchain, might have uses but a currency isn’t it
- 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?
- 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
- Much of traditional financial services is not centralised either. There’s no “exchange†for currency trading, for example
- 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
- Decentralisation is supposed to democratise trading. Except, trading in crypto is surprisingly expensive. And, just like traditional finance, quickly gets complicated
- And it’s slow
- Many of crypto’s biggest promoters are economically illiterate
- It’s basically a pyramid scheme
- 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
- It’s almost like they don’t understand traditional financial markets
- They says it’s progressive and about freedom, but it entrenches existing hierarchies, if anything, more effectively than the existing systems
- 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
- 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:
- Large companies have lots of rules and procedures
- 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.
- Though I wasn’t able to write anything about it in a timely manner! ↩︎
- Maybe second tier too, but in this case I mean there are at least two layers. ↩︎
- There’s a Dilbert cartoon I use occasionally. This from before Adams went off the rails. ↩︎
- Whether you’d want to make a career out of any of those technologies is a different story. ↩︎
Radical Candor
“Radical Candor†is one of those phrases that I’ve heard and wondered about. Is it another vacuous management phrase? Does it mean anything? I saw it in the library and thought I’d find out. I’m cynical about these things but it doesn’t mean I’m closed minded!
The pitch is “Be a kick-ass boss without losing your humanity†which sounds positive but I don’t manage people at work. Even if it contained genuine insight, would there be anything I could use?
The book starts with a description of what “Radical Candor1†is and finishes with how to apply the theory, an approach that I prefer to “How To Win Friends and Influence People†where the story is scattered throughout the text.
The examples vary in how useful or relatable they are. Some I was nodding with recognition. Others were some way out of my experience.
There’s an example early on where the author says “Um†too much in a meeting and her boss immediately offers a speech coach.
How many people get that experience?
I’ve never been offered a coach, not even when my failings have been much more significant than the occasional “Ummâ€! Have I been working for the wrong companies or have I been in the wrong jobs?
I guess the idea is that if someone who name-drops half of Silicon Valley can use “Radical Candor,†then so can you.
But much of the rest of the book did work for me. The idea of building trust and then providing rapid, honest feedback seems (self evidently?) like a good thing. I could imagine past conversations where I could apply the advice. I understood some cases where I’d done a good job; others where I’d missed.
I don’t think you need to be in a management position for this book to be useful. Anyone in a job where there’s an element of leadership might get something from it.
Do you need to go on a training course or read the full book to get the gist? Unlikely. But is there some value here? Absolutely.
- I’m going to use the American spelling as that’s the name of the book, but I can’t say I’m happy about it. ↩︎
Adventures in iCloud Mail Hosting
How does switching email hosts disable your Bluetooth headphones? Read on to find out.
As many people did recently, I got The Email from Google telling me that my Apps for Domains (Legacy) account is going away and that I should either pay up or move away.
I’m not averse to paying. I use email a lot and I have my own domain, so I appreciate that I’m not a typical consumer. But I do object to paying Google because it feels like they’re double-dipping: both data mining my information and billing me for the service1.
In short, I’m not going to stay with Google.
Since I already pay for iCloud — as part of the Apple One bundle — moving my email there would be the obvious choice. Being able to use your own domain is a recent feature, part of iCloud to use their current branding.
Unfortunately the documentation isn’t great. And there are technical gotchas. Let’s walk through my experience.
Step 1, enter your domain name. Okay, check.
Step 2, enter any existing email addresses. I entered my main address and it told me that it wasn’t allowed. As others have noted, the system does return useful error messages, however those are not displayed on the screen! I was left guessing, which is incredibly frustrating.
I figured – partly luck, partly a process of elimination – that the email address was associated with another Apple ID. I logged into my other Apple IDs and removed references to my address, but to no avail. It continued to reject me.
The difficulty is that I’ve been using Apple’s web services for a long time. I have accounts that date back twenty years, before iCloud, before MobileMe, before your Apple ID even needed to be an email address. My main email address predates even that.
Luckily Apple has a “find your Apple ID†tool that tells you the Apple accounts that an email address is associated with. It turned up two accounts that I have no recollection of ever creating. One was a pre-email address account with a very bizarre name. It was an odd reference, but one I recognised so it was certainly me!
I requested that those two accounts get deleted. At that point, the “add domain†screen allowed me to continue.
My hope for step 3 What was to add some email aliases. The way I had my mail set up at Google was with a single mailbox but with multiple aliases. In practice, most of the aliases were just “wildcard†addresses, that is, if it found an address it didn’t know it would send it to the main mailbox. I knew that (bizarrely) Apple’s iCloud didn’t do that. I’m not totally happy with that but, for the way I use email, it’s not an absolute dealbreaker.
Except. You can’t have aliases. I can create an alias to my iCloud address, somethingelse@icloud.com, but not somethingelse@mydomain.com.
This is a problem. Over the years, I’ve removed almost all of the aliases, but one I use almost every day is the one attached to my Apple ID!
I go through my last few months of email – that was a fun afternoon – updated my address at a handful of companies so that the only remaining required alias was the one for my Apple ID.
I have payments and purchases and subscriptions for the entire family associated with this account. I know that in theory I can change the ID but in practice it fills me with dread.
If I’m to move my email, however, this is a necessary step. That it’s the one remaining required alias and that it might make things easier moving to any other email provider pushes me to attempt it.
It wasn’t as difficult or as problematic as I feared. All the work I did previously, removing all traces of the “old†Apple IDs, meant that the change largely Just Worked.
For the next day I found myself signing into all my devices again. The most surprising was when I started listening to a podcast and two minutes later my AirPods suddenly stopped working. I tried turning them off and on again – all the usual diagnostic tools – but couldn’t get them going. I was stood in the middle of the street so I didn’t want to get too in depth.
When I got home I realised they stopped working because they were connected to my Apple ID. I re-paired them with my phone and the audio immediately started to play. Of all the things I expected to stop working when I changed the account, my earbuds were not on the list!
As I write this, it has been about three weeks since I “flipped the switch†and moved over to iCloud email. My Google account is still live – I can switch back if something is utterly broken – but I have not done so. I guess it’s possible that I’ve missed some emails, but I would have no idea if I did, of course!
Despite the initial teething problems I’ve written about above, it’s been working well since then. It even supports push email rather than polling periodically. Not critical, but a nice feature.
Would I recommend it? With reservations. It’s not going to work as a replacement for Google for some people. And both the software and the documentation needs work. The feature set is limited, the backend supports more detailed diagnostics than the front-end and the documentation assumes that you don’t have a mess of Apple IDs like I do.
Let’s hope that Apple work on this. Sadly, I don’t think it’s going to be an overnight thing. There are a bunch of issues here, many of which appear to be a consequence of decisions made years ago.
- The argument may well go that they do not data mine paid accounts but I have no ability to verify that. Google have done enough dodgy things with data that I don’t trust them. Pick one. ↩︎
Cloud Without Compromise
A couple of years ago I did a conference talk called “On Cloud Nine: How to be happy migrating your in-memory computing platform to the cloud.†I wish I’d had “Cloud Without Compromise†back then. It covers much of the same ground but, as you’d expect in a book rather than a forty minute conference talk, in much greater depth. More importantly, it puts some concepts into context much more clearly that I did, either by explaining it better or by giving it a good name.
One of the main takeaways of the book, something that is mentioned throughout, is the mantra “Cloud is a capability rather than a destination.†In my talk I hint strongly at that but never made it explicit. I always felt that “the cloud is just somebody else’s computer†didn’t fully encapsulate the magnitude of change but wasn’t able to articulate it concisely. Well, here’s the line to use.
This book took a long time to read. Not because it’s badly written or exceptionally long but because every few paragraphs I had had to stop and think about the implications, how the subject applied to my recent work or research a new tool that I had not come across previously.
There have not been many technical books I’ve read recently that have had this impact. Naturally not everything was new to me, but even then rephrasing a concept or putting it into context can be immensely useful.
It is also very approachable. There’s a nice appendix on some of the more technical aspects, there are some nice anecdotes and even a little humour.
“You’re the most unromantic person I know.â€
If there’s a criticism, it’s that some parts read as an advertisement for IBM and RedHat. The last chapter in particular, which is about automation, could be a White Paper for Ansible. Sure, the focus of the book is on hybrid cloud, where the other big vendors are pushing their own agenda, but the OpenShift advocacy would be less signifiant were it not for the fact that a couple of the authors work for IBM. On the one hand you have to write what you know. On the other, shilling your employers products in what’s supposed to be a vendor neutral book sits awkwardly.
For what it’s worth, the advice does not appear to be incorrect but I wish there had been more discussion about competing products or they’d stayed clear of talking specifics at all.
Overall, though, “Cloud Without Compromise†comes highly recommended.