Blog

Crisis? What Crisis?

Leave a comment

Empty shops, rising prices, the laughing stock of Europe, our place in the world in question, people out of work and fuel shortages. But that’s enough about late 2021, I decided that I wanted to learn more about the Seventies, the decade that brought, well, me, the Winter of Discontent, power cuts, the three day week and shocking fashion sense. There are a few books that cover the same timeline, but I decided on “Crisis? What Crisis?”[affiliate link] by Alwyn W. Turner.

The book is in roughly chronological order, with occasional jumping around to make certain aspects make sense.

Despite being such relatively recent history, there are surprising volumes of material that are shocking, or at least uncomfortable. I know the name Enoch Powell and the phrase “rivers of blood,” of course, but even then the more detailed background is both depressing and familiar. The parallels with the modern anti-immigrant movement are obvious.

On the other hand, it made the rise of Margaret Thatcher more understandable to me. I’m not a fan of her politics but you can appreciate the desire to shake things up. Having said that, I thought her victory in the 1979 election was assured so it was fascinating to read that it wasn’t, and that had the election been called just a few months earlier things might have turned out differently.

Those looking for a change with Thatcher may not have realised what they were letting themselves in for. I guess I’ll have to read the next book about the Eighties to find out.

Looking back, the Seventies is often seen as a “lost” decade, which is why it’s nice that the book concludes with the upsides that we often don’t consider:

For most of the country, for most of the decade, times were really quite good. In retrospect, the 1970s can look like a period of comparative calm and stability. It was still possible for an average working-class family to live on a single wage, very few were required to work anti-social hours, and housing was affordable for most.

Almost by definition, I can’t say how complete the book is but I do get a much better feeling for the decade than I had before, which makes it worth the read.

Opinion

Ops is undervalued

I made the mistake of suggesting that there was a blog to be made from this tweet. This is that post.

People still underestimate the value in (Developer|Operator) Experience when building platforms and honestly it’s kinda shocking to me.

If you want to win mindshare you need to make your tools actually usable. If you don’t want to lose it you need the same.

First: I agree with the sentiment. Maybe not to the same extent as Danielle, but I fight the same battles in my day job. I wanted to say this now because, on reading the rest, you may think the opposite. What follows is an explanation of why this is a common situation. I don’t mean it as a justification.

In summary, making software work for ops teams is not a focus either for software companies or internal development teams because of at least three reasons:

  • It’s not a business driver
  • Ops are not the buyer
  • Engineering is run by developers

Naturally there are exceptions to these rules. Every company is different. These are observations, not rules.

Working at the “coal face” it’s easy to forget, but people don’t buy software. They buy a solution to a business problem1. These days, that solution is often software but you don’t buy a new product because it’s cool2.

A driver might be to get a report generated more quickly, or to provide a new service to paying customers, or to reduce the costs of some infrastructure3.

But, you argue, the ops team are the people who keep the system up and running. How can this new system generate reports or deliver a service if it’s not running reliably or has not been provisioned correctly?

You’d be right. Sadly, organisations are often not structured to recognise that fact. The IT teams tasked with making everything run smoothly are frequently in a completely different reporting hierarchy from “the business.” I put “the business” in quotes as I hear it described that way all the time, but it’s this us-versus-them philosophy that brings many issues, including how ops get sidelined4.

With “the business” and “ops” being in separate reporting structures, one or the other has to sign off on the purchase of new software (unless it goes way up the organisation) and that’s always going to be “the business.”

The buyers normally consult the ops team, but ultimately they’re going to put their own needs first. Objections that the ops team have will end up in the business case, but likely in an appendix that no one will ever read.

This makes no sense because, as we all know, most of the expense of a system occurs after go-live. But monitoring, management and deployment are not things at the top of mind of developers and business users.

But even in the IT organisation, the ops team frequently don’t get the attention they deserve either. Anecdotally, this is because IT leadership come from the development team. Their outlook on IT is therefore skewed towards making things rather than keeping them running. I see the same challenges for testing teams. Or, indeed, the lack of testing teams.

This lack of buy-in from the ops team is endemic. I see it in companies buying and using software. I see it in companies that make and sell software5.

At this point, what I would like to be able to do is say, “And the solution to this terrible problem is…” Sadly there is no easy answer. Saying “You should listen to your ops team” is both obvious and unhelpful. Making tools useful for the ops team to get mindshare is a good way to get your software on a shortlist but maybe not enough to clinch that sale.

  1. I’m talking here about software used in a business of course, but the difference between this and personal use isn’t as great as you might initially imagine. You buy a game to solve the “problem” of boredom. Very few people buy software because it’s software. ↩︎
  2. You might buy it because this, specific solution is cooler than the other options. ↩︎
  3. That is, even in the case where it’s the infrastructure that is being improved, the business case is not “make the ops team more efficient” but “make the cost of operations lower.” ↩︎
  4. There’s another blog in how toxic “the business” as a concept is. This isn’t that blog. ↩︎
  5. This is a chicken and egg problem. Do software companies fall into this trap because they’re run by developers? Or is it because they’re selling to companies who have already fallen into the trap? ↩︎
Blog

Little Book of Humanism

While there is nothing wrong with “The Little Book of Humanism,” it wasn’t for me. Some people need to see aphorisms or testimony about their chosen faith. If that’s you, if you’re a humanist, then this book fits the bill. Similarly, if you’re Humanism-curious, then this book might fill in some gaps in your knowledge.

None of the sections span more than a few pages and it’s filled with quotes and stories by people who were publicly Humanist or at least espoused the same values. The vignettes cover life from birth to death and everything in between. Some I’d heard of before, others were new to me. It’s longer than I was expecting, though it’s easy to dip in and out; there’s no need to read the whole thing beginning to end.

I don’t think I need these stories or quotes. This says more about me than the book. I was never religious, meaning I have no need to replace a sacred text. And I have never found other people’s testimony persuasive1. But if hearing about other people with a similar outlook gives you the warm fuzzies, or if you’re curious about what Humanism means, then this book might be what you’re looking for.

  1. I always found it odd that many believers go straight to testimony as a way to convince you that their particular brand of faith is the right one. Is it that the approach works or is it that people enjoy talking about themselves? ↩︎
Blog

Code- The Hidden Language of Computer Hardware and Software

While I have more than enough books on my “to read” list, I am always up for suggestions. “Code” came up in a Twitter conversations about computer hardware. I noted that one of my favourite courses from my Computer Science degree (in hindsight if not at the time) was where we went from “What is electricity?” right up to a pretty much fully working CPU. “Code” was recommended as it covers the same ground.

If you’d like to refresh your memory or you never took such a course, this is great introduction to how computers work.

It’s a book of two halves.

The first half starts with the foundations and principles. It starts with the concepts, like Morse Code, before building up from relays, to logic gates, to half-adders, to a complete, working CPU.

That bit is great. Clear steps and descriptions. I was reminded of many things that I first picked up at university and learned some details that I’d either completely forgotten or had never internalised at all.

After you get a working CPU the book largely turns into a history lessen, albeit from the year 2000. It talks about the rest of the computer but, out of necessity, in significantly less detail.

I found this second part to be weaker, though this may be because I’m coming at it from 2021 rather than 2000. These last sections have dated much more than the earlier, CPU-bound section and I wonder if the book had been about building just the CPU rather than the whole computer it would have dated better?

Having said all that, while weaker than the first half, it’s still well written and easy to understand.

Even if you skim the later sections, what quickly becomes apparent is that a computer has layer upon layer of abstractions. You may not understand every layer in the same amount of detail but knowing that they exist is, I think, useful as a software developer.

I can’t help but recommend this book to anyone interested in the subject.

Blog

The Computers That Made Britain

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.

Tim Danton’s “The Computers That Made Britain” is the story of a few of those machines.

He covers all the obvious ones, like the Spectrum and the BBC Micro, and others that I’ve not seen the stories of before, like the PCW8256.

While it’s called “The Computers That Made Britain” rather than “Computers that were made in Britain,” I would argue with some entries. The Apple II is certainly an important computer but, as noted in the book, they didn’t sell well in the UK. Our school literally had one, and I think that’s the only one I’ve ever seen “in the wild.” Sales obviously isn’t the only criterion, but the presence of these machines presumably pushed out the New Brain and the Cambridge Z88 (among others). Since this book is about the computers than made Britain, I would have liked to see more about them and less about the already well documented American machines like the Apples and IBMs.

The chapters are largely standalone, meaning you don’t need to read them in order. I read about the machines I’ve owned first, before completing a second pass on the remaining ones. They’re invariably well researched, including interviews with the protagonists. Some machines get more love than others, though. Talking about the Spectrum, it finishes with a detailed look at all the subsequent machines, right up to the Spectrum Next, though curiously missing the SAM Coupe. But the Archimedes gets nothing, even though there was a range of machines. Did they run out of time or was there a page count?

But those are minor complaints for an otherwise well put together book. Recommended.

It’s published by the company that makes Raspberry Pis, which you could argue is the spiritual successor to the Sinclair and Acorn machine. You can download the book for free, but you should buy it! The above link is for Amazon, but if you’re near Cambridge you should pop into the Raspberry Pi store and pick up your copy there instead.

If this is your kind of book, I would also recommend “Digital Retro” and “Home Computers: 100 Icons that defined a digital generation,” both of which are more photography books than stories.

Blog

I’m a Joke and So Are You

“I have read just about enough about a large enough number of things to be wrong about nearly everything.”

It took me a long time to read “I’m a Joke and So Are You” by Robin Ince, but you shouldn’t take that as a reflection of the book itself. Instead, it’s more about timing and other distractions.

If you’re familiar with Ince’s work on the Infinite Monkey Cage, the structure of the book should make sense. The theme is “What makes comedians a special breed?” He asks comedians and scientists about various aspects, throwing in thoughts, quips and stories of his own,

He starts with childhood and meanders through many aspects of life from “the self” to imposter syndrome, finishing with death.

While it’s not earth shattering, with no huge reveals that make you reevaluate your life, it’s an entertaining and occasionally thought-provoking read.

Photography, opinions and other random ramblings by Stephen Darlington