The Libra Association de-cloaked today. With Facebook amongst the initial backers, this is being seen – fairly or not – as the Facebook cryptocurrency. The reputation of the system, and potentially the take-up, may end up being harmed by that alliance. However, I’m slightly more interested in another question: is it likely to be any good as a digital currency?
Category: forecasting (Page 1 of 2)
For those who aren’t from the UK, the “High Street” is what we call the shopping parade in a typical town or city. It lies at the heart of the town, quite different to a mall, and is more of a European concept. “Cascade failure” is what we say when one part of a system causes another part of the system to fail, often like a set of dominoes falling. Putting two and two together: I believe that the UK High St is in such a failure mode right now, and that over the next five years we’re going to see some very rapid changes.
My estimable Twitter-pal Paul Johnson has put together a very reasonable thread about his thinking on serverless costs (ie. AWS Lambda, in this case). He makes a great case for the design of functions being done in such a way as to allow cost efficiency improvements, and I think the point on architecture is generally well-made. However, there are a few aspects of this which I think are generally not well understood, and Twitter is much too short a form to get them in. Hence this post.
Sam Altman has published a thoughtful piece about what was previously called the Singularity, which he now refers to as The Merge. I’m not sure these concepts are quite the same – the traditional Singularity was less a statement about humanity than a theory that, at some point, the improvement of intelligence of machines is sufficiently fast that it becomes pointless to predict the future. “The Merge” for Altman is about the point at which human intelligence might start accelerating – which assumes the machines will want to bring us with them. Not quite the same.
However, Altman believes The Merge has already started. I’m pretty convinced it hasn’t, but I think what is interesting is identifying which signs might be indicative or not.
Gosh, I wish I was at re:Invent. Personally, I don’t like the States much (the place is great; getting through the airports is an exercise in frustration) and while I’ve never been to Las Vegas there isn’t much that ordinarily attracts me to the place. But, to have so many incredible people in one place – amazing.
For those – like me – not there, what do the announcements today mean? I’m not going to focus on the tech so much, but more on the additional options and architecture that is becoming available. Let’s look at a strategic level.
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.
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.
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!
Back in 2010 I wrote a post about Canonical’s business direction, in response to something Bradley Kuhn had posted. Both he and I were worried about Canonical becoming reliant on an “open core” business model – worried not just from the perspective that it would dilute the principle of Ubuntu, but that frankly every time I have seen this executed before it has been a dismal failure.
The posts are worth re-reading in the context of Mark Shuttleworth’s announcement today that Ubuntu will be dropping a number of their in-house technologies and, more importantly, abandoning the explicit goal of convergence. I would also say, read the comments on the blogs – both Bradley and I found it deeply strange that Canonical wouldn’t follow the RHEL-like strategy, which we both thought they could execute well (and better than an open core one).
Of course, our confusion was – in hindsight – obvious. We weren’t seeing the wood for the trees. The strategy has since been spelled out by Simon Wardley in his rather good talks; one example is here:
It’s well worth to take the time to watch that and understand the strategy against RedHat; but it’s pretty easy to state: “Own the future, wait for it to come to us”. Let’s see why this is important.
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.