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.
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.
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!
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.
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.
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.
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.
The news about plans for Symfony 4 has got a number of my dev team a bit excited about the possibilities – although, so far, there is precious little information about the new tool, Flex, and exactly what “composition over inheritance” will mean in practice.
One similar solution that this reminds me strongly of is Django, and its approach to “apps” – although this isn’t necessarily highlighted, a composition-type system ships with Django and comes with a number of both positive and negative implications.
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.
Advisory CTO to a portfolio of start-up and scale-up companies. I specalise in
taking businesses through periods of extraordinary technological change,
often navigating tricky waters of enterprise sales and regulatory compliance.
This is my personal site, where I write primarily about software architecture: how
to build better software, faster, and more securely.
