Category: performance (Page 1 of 1)

Spectre attack: why is it unpatchable?

Everyone is now talking about the CPU security problems that are now being fully disclosed: they’re dubbed Meltdown and Spectre. Meltdown is a problem that mainly or entirely affects Intel CPUs, but Spectre is a problem that affects all designs.

I haven’t seen any “explain it like I’m 5” on the Spectre paper yet, so here’s my take. Sadly, it’s not 5-year-old level, but I’ve tried to make it a bit more accessible. If you want a lot more detail, the Google blog has code.

Read More

“Troubleshooting Agile”, a new podcast, and some notes about Ownership

I just listened to “Troubleshooting Agile”, a new audio series from CTO Craft contributor Douglas Squirrel and his podcast partner Jeffrey Fredrick. The first edition is on blameless culture, which I think is a great starting point: it’s very difficult to develop, and taking baby steps toward that in a team which doesn’t have it often feels wrong.

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

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

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

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

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

Some notes on Serverless design: “macro-function oriented architecture”

Over the past couple of days I’ve been engaged in a Twitter discussion about serverless. The trigger for this was Paul Johnston‘s rather excellent series of posts on his experiences with serverless, wrapped up in this decent overview. First, what is serverless? You can go over and read Paul’s explanation; my take is that there isn’t really a great definition for this yet. Amazon’s Lambda is the canonical implementation, and as the name kind of gives away, it’s very much a function-oriented environment: there are no EC2 instances to manage or anything like that, you upload some code and that code is executed on reception of an event – then you just pay for the compute time used.

Read More

On Hiring A-Players

“Steve Jobs has a saying that A players hire A players; B players hire C players; and C players hire D players. It doesn’t take long to get to Z players. This trickle-down effect causes bozo explosions in companies.” ― Guy Kawasaki A few times recently I’ve bumped into what I call the “A-Player Theory”. This is a close relative of the “10x Engineer Theory”, and in its usual formulation states that only the best want to hire their equals or betters: everyone else, for whatever reason, hires down.

Read More

Page 1 of 1