Alex Hudson

Thoughts on Technology, Product, & Strategy

Page 2 of 17

Academia is apparently unmanageable

There’s a great blog post doing the rounds today, titled “Every attempt to manage academia makes it worse“. Going through a number of examples of metric-based assessment, the conclusion is that standard management practice applied to academic work results in obviously worse outcomes.

At the heart of the argument is an interesting contradiction – that it is possible to assess academic work and show that under a specific regime the results are less good, while simultaneously it is impossible to assess the results of academic work in such a way as to improve it. However, it’s possible to accept a slightly weaker form of the argument – that the practice of measuring while science is being done negatively affects the work in a way that appraising the results post-facto doesn’t. I’m not in a position to really know whether or not this is genuinely the case for academic work, but I’m seeing people apply the same argument to software development, and I truly believe it doesn’t apply.

Read More

Brand & Culture: it’s all about Action

There are a lot of people with strong thoughts about brand and culture, and how the two relate to each other. From conversations I’ve had with others, I thought it high time to put my perspective down in writing.

I have a lot of time for this HBR article, “Brand is Culture, Culture is Brand“. It is absolutely correct to say that you cannot build a brand if your business culture does not / will not support and live that brand, and this is a fault seen so commonly. Business rebrand frequently; and it’s very common to see immediate push-back because the way the business operates doesn’t fly with the new brand at all.

However, I think things have to go deeper than this.

Read More

Habitus: the right way to build containers

So, after my previous slightly ranty post, I’ve been trying out a few different tools and approaches to building containers, attempting to find something which is closer to my idea of what good looks like. One tool stands out from the rest: Habitus.

(Not to be confused with Habitat, an annoyingly similar project with an annoyingly similar name. I have no idea which came first, suffice to say, I had heard of Habitat before and discounted it as being irrelevant to my use cases – and therefore almost overlooked Habitus during my research)

Habitus provides just-enough-Make to bring some sanity to the Docker build process, with the following killer features:

  1. ability to order container builds by expressing a dependency from one to another
  2. first-class support for artefacts created during the container build process, which can be extracted and used as input for later builds
  3. management API to provide build-time secrets into the containers

Read More

The ongoing poverty of the Docker environment

I spent a few hours this weekend attempting to re-acquaint myself with the Docker system and best practices by diving in and updating a few applications I run. I wrote up an article no long after Docker’s release, saying that it looked pretty poor, and unfortunately things haven’t really changed – this doesn’t stop me using it, but it’s a shame that the ecosystem apparently has learnt nothing from those that came before.

Read More

A short review: The Agile Team Onion

This is a quick and pithy review of Emily Webber’s free e-book, “The Agile Team Onion“. At about 20 pages of content, it’s a concise enough work itself – I personally appreciate the laser-like focus on a single subject; in this case, it’s thinking about the various factors that affect agile team make-up, sizing and interfacing with other people and teams.

Read More

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” – first principle, Agile Software Manifesto (my emphasis)

Deadlines, estimates, predictions

Project management is always guaranteed to bring out some strong opinions, and a recent Twitter discussion was no different – but, while the core discussion on Twitter was great, it really deserves a much longer-form treatment. Paul Johnston wrote up his thoughts about getting people to talk about predictions instead of deadlines – and much of it is hard to argue with, but I have a bit of a different perspective.

Read More

Brexit confirms: storytelling is dead

This is not a post about Brexit; this is about conversations. Storytelling rose in the 80’s as a key marketing tool – phenomena like the Nescafe “Gold Blend” adverts demonstrated how the ability to tell a story could convincingly engage consumers en masse. Truth be told, this was nothing new – the “soap opera” is so-called because those ongoing serial dramas used to be sponsored by soap manufacturers. But, the key insight by the storytellers was that creating a story around a message you wanted to communicate (rather than simply being associated to or referenced by the story) was very powerful.

Now, Nescafe coffee had only a tangential bit-part within their famed serial adverts, and indeed broadcasting on television is a remarkably expensive way of telling a story – so in fact, the technique didn’t really start to take off until the early 2000s, with the advent of the internet. Of course, big names continued to tell stories in the way they had – Guiness being the more modern exemplar – but now smaller organisations could do it; they felt it built relationships with their consumers.

There is a lot to be said about discerning what is storytelling and what isn’t. Critically, a story ought to have an arc – a beginning, middle and end at least – but at a deeper level ought to have a structure which creates emotional engagement. Shakespeare was a master of the five-act structure, and most blockbuster movies to this day retain a very similar make-up. Advertisements alone do not lend themselves to that level of sophistication, but people started applying storytelling in many different areas of business – although seen as a marketing tool, it quickly leaked into sales, the boardroom, investment decks and beyond.

Many people get benefit from story-thinking without necessarily having a huge amount of structure. The process of thinking editorially about their message, and trying to frame that in the form of a story is difficult and restricting. In a similar way to writing a Tweet, the added restrictions make you think carefully about what you want to say, and it turns out these restrictions actually help rather than hinder – a message has to be much more focussed. However, those restrictions (while helpful) are not the power of storytelling – more the power of subediting / thinking (which, is seems, it less common than you’d think).

People have said before me that storytelling is dying – Berkowitz’s piece on becoming storymakers rather than tellers is well-cited. It’s a very marketing-oriented perspective, and there’s lots to agree with, but I think it’s dead wrong for digital-native organisations.

Politics is an awful lot like marketing and product development in some key ways; in many ways, it actually resembles the market before software-as-a-service:

  • highly transactional nature (votes instead of money)
  • very seasonal sales periods, often years between sales
  • competitive marketplace for a commodity product
  • repeat customers very valuable, but profit function dependent on making new sales on the current product line

Not just that, but crucial is the engagement of the “customer” (the voter) in an ongoing fashion, to ensure that the party is developing policies that they believe will be voted for. Interestingly, in blind tests, the Liberal Democrat and Green policies rate very highly – so we can see that while the product is important, market positioning is critical to ensure customers have a specific formed belief about your product.

Within continuous delivery thinking, the digital organisation is concerned primarily with conversations to drive the brand rather than positional or story-oriented marketing. However, what was particularly interesting with the Brexit debate: this conversational engagement was writ large across the whole leave campaign.

Things we can note about the campaign:

  • meaningful engagement on social platforms like Facebook and Twitter. Of course, campaigns have done this before (Corbyn would be another example), but while others have been successful at deploying their message, Leave were highly successful in modifying their conversations quickly
  • a stunningly short period of campaigning. Who knows why this happened: the Scottish referendum on independence was over a period of 18 months. The UK Brexit debate was complete in 4. There was no way a campaign could hammer home messages; each thing they said had to be well-chosen and timely
  • absolute control over the conversation. While Leave conversed freely with their own supporters, they meaningfully achieve air superiority in terms of the conversation in the debate. Their messages were the ones discussed; they created the national conversation. People are shocked by how “untrue” many of their statements were: but people can recall them readily. I doubt many could recall anything Remain said other than vague threats about the economy.

The speed of the conversation here was crucial. They adapted in a truly agile fashion, and were able to execute their OODA loop significantly more quickly. In the end, it was a tight contest, but it really should not have been.

Storytelling is a blunt instrument in comparison. It’s unresponsive, it’s broadcast, and it’s not digital native. Its time is up.

Containing incestuousness

Having droned on a little the other day about duplication in Stackanetes (in hindsight, I had intended to make a “it’s turtles all the way down” type jibe), I’ve been delighted to read lots of other people spouting the same opinion – nothing quite so gratifying as confirmation bias.

Massimo has it absolutely right when he describes container scheduling as an incestuous orgy (actually, he didn’t, I just did, but I think that was roughly his point). What is most specifically obvious is the fact that while there is a lot of duplication, there isn’t much agreement about the hierarchy of abstraction: a number of projects have started laying claim to be the lowest level above containers.

It comes back to this; deploying PaaS (such as Cloudfoundry, which I try to hard to like but seems to end up disappointing) is still way too hard. Even deploying IaaS is too hard – the OpenStack distros are still a complete mess. But while the higher level abstractions are fighting it out for attention, the people writing tools at a lower level are busy making little incremental improvements and trying to subsume new functionality – witness Docker Swarm – they’re spreading out horizontally instead of doing one thing well and creating a platform.

I don’t think it’s going to take five years to sort out, but I also don’t think the winner is playing the game yet. Someone is going to come along and make this stuff simple, and they’re going to spread like wildfire when they do it.

Stackanetes

There’s a great demo from the recent OpenStack Summit (wish I had been there):

OpenStack is a known massive pain to get up and running, and having it in a reasonable set of containers that might be used to deploy it by default is really interesting to see. This is available in Quay as Stackanetes, which is a pretty awful name (as is Stackenetes, and Stackernetes, both of which were googlewhacks earlier today) for some great work.

I’m entirely convinced that I would never actually run anything like this in production for most conceivable workloads because there’s so much duplication going on, but for those people with a specific need to make AWS-like capability available as a service within their organisation (who are you people?!) this makes a lot of sense.

I can’t help but feel there is a large amount of simplification in this space coming, though. While “Google for everyone else” is an interesting challenge, the truth is that everyone else is nothing like Google, and most challenges people face are actually relatively mundane:

  • how do I persist storage across physical hosts in a way that is relatively ACID?
  • how do I start resilient applications and distribute their configuration appropriately?
  • how do I implement my various ongoing administrative processes?

This is why I’m a big fan of projects like Deis for businesses operating up to quite substantial levels of scale: enforcing some very specific patterns on the application, as far as possible, is vastly preferable to maintaining a platform that has to encompass large amounts of functionality to support its applications. Every additional service and configuration is another thing to go wrong, and while things can made pretty bullet-proof, overall you have to expect the failure rate to increase (this is just a mathematical truth).

CoreOS in many ways is such a simplification: universal adoption of cloud-config, opinion about systemd and etcd, for example. And while we’re not going to go all the way back to Mosix-like visions of cluster computing, it seems clear that many existing OS-level services are actually going to become cluster-level services by default – logging being a really obvious one – and that even at scale, OpenStack-type solutions are much more complicated than you actually want.

 

 

Page 2 of 17