Alex Hudson

Thoughts on Technology, Product, & Strategy

Improving the metaphor of technical debt

RedMonk published a great article today on the incompleteness of technical debt as a metaphor. This touches on a number of points, the best one I think is that for many people in business, debt just isn’t a “bad per se” thing. Technical debt, more often than not, is.

I completely agree with the analysis. Presenting technical debt as risk is a more accurate picture a lot of the time. While it’s potentially even more accurate to relate them to other financial instruments (my favourite is the “uncollateralized technical debt obligation”), it’s much more difficult to relate to.

I’d like to share the simile I use.

Read More

Pokémon Architecture

Millions of words are expended on software architecture. Fashions come and go; some patterns last a long time, others are a flash in the pan. One day, Model-View-Controller is all the rage. The next, it’s Model-View-ViewModel. So on and so forth – the next new architecture is the One True Way or a genuine silver bullet, until it’s not, at which point it’s legacy, technical debt or code smell.

Developers talk too much about architecture. In the future tense, it’s always what the next architecture is going to enable them to do, what problems it will solve. In the past tense, it’s usually about what the architecture prevents them doing, why the architect was bad, why it’s the wrong pattern, etc. Static architecture design is the wrong thing to think about, and here’s why.

Read More

A defining time in deployment: thoughts on Istio

Last week I gave a lightning talk, ostensibly on Kubernetes / docker / prometheus, to a motley crew of London CTOs. I rarely give talks these days, so of course I ran over massively. There’s so much I’ve learned, and my teams have learned, attempting to force a discussion like this into a lightning format feels trite (in retrospect).

There’s a key reason for this. In my talk, I called it the “Cambrian explosion period of Ops”: there are a multitude of tools available, more are being developed all the time, and there’s a huge amount of overlap.

I don’t want to try to predict when we’re going to hit “peak Ops tools”. Serverless is a way off from hitting most mainstream teams yet; it’s still a novelty right now, will grow very quickly around 2020 and will probably be dominant by 2025. So, we can’t be that far off the peak – and another sign of this is that we’re beginning to see real consolidation.

Read More

Initial impressions on Symfony 3.3

I wrote a couple of times previously about Symfony 4, particularly the architecture and use of Makefiles. It’s now at the point of being testable, so I took it for a short spin.

One comment for Linux users: your operating system will probably need an upgrade. I’m a Fedora user, and the stable release only includes PHP 7.0. Although that’s recent, it’s not good enough. Thankfully Fedora 26 has been in alpha a little while, and the beta is due at the end of this month. It was an easy upgrade, and includes PHP 7.1.4, a new enough version.

Read More

Articulating the ATOM approach

It’s interesting watching history repeat itself. There are a number of fashions that come and go in technology: thin client computing comes back every twenty years or so, for example. In the 80s, Unix was very big – it faded a bit in the nineties but then came roaring back with Linux.

Another venerable bit of software is coming back into fashion – good old Make. It’s not the perfect tool by any means, and the niche it once had is no longer that relevant. However, I think we’re going to see a growth in its usage once again. Let me explain why.

Read More

Lean versus Agile

People sometimes ask me about the structure of our internal development team, and to what extent we’re truly “agile”. My response is that we’re actually more “lean”. I happily give examples of some of the key working practices we have. I generally don’t explain the difference between “lean” and “agile”, though.

Sometimes, people use these terms interchangeably. I think this is wrong, but understandable. As a JIRA user, I’m used to it offering a Kanban board to run a scrum sprint. This can be a great choice, but it muddies the waters. Let me take this opportunity to explain my thinking then!

Read More

Fedora’s revised mission

Coming up with convincing vision and mission in a corporate environment is never easy – in fact, I think it’s one of the most difficult things you can do. Setting a clear and crisp vision is crucial to create an aligned organisation. Refining down into an elevator-pitch sized statement while avoiding generalisations, platitudes and (frankly) abstract jibberish is practically impossible.

Doing so outside a corporate environment I think is even more difficult – money is at least a straightforward motivation to hang a hat on. One of the best guides to doing this is Guy Kawasaki’s Art of the Start Manifesto, I particularly like the bit about making mantra.

The new mission for Fedora is:

Fedora creates an innovative platform that lights up hardware, clouds, and containers for software developers and community members to build tailored solutions for their users.

Unfortunately a few weasel words have crept in (“innovative”, “solutions”, “platform”), but I love the overall trust of it. The four foundations are pretty close to being a mantra and they’re indirectly reflected in this.

The main thing I find disappointing is that the mission ties in specifically to a few delivery mechanisms. Lighting up containers should be a consequence of the mission, and not be part of the mission, for my money. Containers are very relevant today – but are they going to be relevant in five year’s time?

Fedora is an operating system, the role of an operating system is to create an environment in which software can be allocated the resources with which to run. The end user value in having an operating system is precisely that you can run software easily. Having great support for containers is, right now, singularly important is being able to do that.

Let’s quickly thing about the future, though. Containers are one piece of technology, Kubernetes is a broader one. Day by day, I see more and more investment in k8s – to the extent that relatively soon we’ll need to think about k8s as an operating system in its own right. It’s never going to replace Fedora, and Fedora can run within k8s, but applications that run on k8s need to be quite specifically tailored for that – or even designed for that from the start. The whole story that k8s has is really about resource allocation.

Kubernetes isn’t the last word by any means. The true future is Serverless, which is coming at us at a rate of knots. Should this be part of mission? Right now, almost certainly not – but the mission should be the test. If the mission is about delivery of an environment in which people can run software, Serverless software will become increasingly relevant in that mission in the near future.

The really positive thing about the mission is that it can be used to test ideas. If something isn’t aimed at developers or the community, it likely doesn’t fall into the mission. Replacing legacy Unix is not part of the mission either.

If the redefined mission ends up being useful, it will be because it helps align the community and enables better, more consistent decisions to be taken – everyone will help push Fedora in the same direction. It will be great to see that happen.

Serverless, Put Simply. A big change to software development is coming.

Explaining Serverless technology

If you’re an IT or business leader, you’ve probably heard about serverless. Forward-thinking organisations are planning for servless now, because it’s a big change to how we build software. You don’t need deep tech knowledge to understand why – there’s nothing mystical about serverless. I’m going to explain what this is in simple terms and how it will affect software development practices.

Read More

Brand demolition

It was only just over a week ago that I posted about brand being the net result of action, and in the last few days United Airlines have decided to furnish me with the best example yet.

There’s nothing that speaks more volumes than how a company treats its customers, and while it’s not the case that all their customers are treated this poorly, the fact they will go this low is shocking.

Employees are not “brand ambassadors”; as the agents of your company they are the ones building your brand. Customers aren’t always right, but when they are happy and talk positively about your company, you build your brand. Marketing and advertising help build awareness of a brand, good logos and design will give people an intuition about your brand, but the rubber hits the road when your organisation does things.

So, what is strategy anyway?

It’s always interesting reading how other people view strategy, and Vince Law’s WTF is Strategy? is a very entertaining read. Like a lot of my posts, it’s quite digital product-oriented, but I think these principles are pretty general and should apply for most people.

What is interesting is that one of the examples he uses – taking a road-trip across the States – is exactly an example that I cover early on in “A Practical Introduction to Wardley Mapping“. It’s different in some notable ways – his journey is east-west while mine is north-south, because the goals are totally different – but it’s very insightful that he chose such a similar example to mine to illustrate the point. This also helps point out the differences in our approaches!

Read More

Page 1 of 17