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.
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.
This evening’s RedMonk article on linguistic prescriptivism is, as usual, excellent reading. Does it matter what people call things? Is the intent behind the name something significant, which should be respected?
In computer science we “have form” on this subject. The names or symbols we assign to things are very clearly different from the values involved. We might write
1.999..., and these symbols are distinctively different from the concept of two-ness, and indeed in another language we might write a two using very different symbols, like
(() ()). Often this logic gets carried forward into other areas – somewhere else on Twitter, a discussion about Serverless was happening.
It has been just over a week since I wrote that software architecture is failing, which received a level of response I didn’t expect. The reason I wrote the post in the first place was to set the scene for some future posts I want to write: as I said, I don’t think we talk enough about architecture for SMEs particularly, and I want to spend some time focussing on those. This post described the reason why.
However, one thing was very clear: the post overall, and many of the ideas within it, strongly resonate with a much larger group of people than I expected. I want to reflect on that a little, but first, let’s look at some stats.
Everyone wants faster Continuous Integration (CI). The quicker you can get from commit to test results, the better – but there’s a bit of tension here. A CI should start close to “first principles”, so that you know an entire build is good and repeatable. But the more work the CI is doing, the slower it will go.
I’ve mentioned before that I use a combination of stowage and container-based CI systems, and in professional life we’re very heavily invested in GitLab now (which is an excellent system in general). Containers are a good starting point for CI, because they’re very easy to set up, do some work, and then throw away again. Getting clean builds is very straightforward.
Today I released version 0.5.0 of stowage, which brings a few additional small features which really simplifies usage in CI.
On social media right now, strong rumours are spreading that the WPA2 encryption scheme has been broken in a fundamental way. What this means: the security built into WiFi is likely ineffective, and we should not assume it provides any security.
The current name I’m seeing for this is “KRACK”: Key Reinstallation AttaCK. If this is true, it means third parties will be able to eavesdrop on your network traffic: what should be a private conversation could be listened in to.
This has happened before with WiFi: who remembers WEP passwords? However, what is different this time around: there is no obvious, easy, replacement ready and waiting. This is suddenly a very big deal.
I doubt there has ever been a time when software architecture was seen as a raging success. The “three-tier architecture” of the web has held up extremely well and is an excellent place for many people to start. The “12 Factor App” approach has encouraged developers to adopt practices that make deployment and scaling much simpler. Over the last couple of years, though, I’ve noticed developers advocating for architectures I consider to be extreme and limited in utility, foisting highly complex systems into startup environments at great cost. It appears to me to be getting worse.
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.