The world is full of applications that are big enough that companies need multiple development teams to work on them. No matter how these teams are organized (but I’m going to go out on a limb and guess they’re not completely cross-functional, even ignoring the hard parts). The benefits to organizing multiple software teams is they can operate independently, but the downside is that any best practices learned are hard to propagate across teams. After all, the whole point is they only need to interact with each other to inform each other of service-level changes. So how can all these development teams actually learn (and adopt) best practices?
From the “stuff I screwed up” files – caching was a bad choice
OK, so the phrase “caching was a bad choice” isn’t exactly something you expect to hear about software development. Generally, caching is a good thing – it improves performance by reducing calls to your database or external services, saving time and resources by not re-querying or re-computing. What’s not to love? Well, as with everything else in life, the devil’s in the details, and if you don’t get those right then anything can become a failure.
It’s “Function as a Service”, not “Functions Instead of a Service”
Like just about everybody else who runs software post dot-com bust, I read about Amazon Prime Video re-architecting their monitoring service, and saw all the microservices vs monolith hot takes. For the best monolith vs microservice analysis on the post, I recommend CodeOpinion’s video. What I found more interesting about the post wasn’t the monolith vs. microservice debate (I agree with CodeOpinion – that’s not really the relevant point to the original article), but rather the limits to using Functions as a Service (FaaS)…as a service.
The bigger picture to software
Working in software development, it’s easy to get caught up in thinking the code is everything, and everything must be in service to the code. After all, not only is the product or service we deliver code, but running on the cloud means your operations are now code, infrastructure is code..it seems like literally everything about software has been turned into “just code.” Software has eaten the world, after all, and yet, writing the code is still the least important part of the whole software development process. That doesn’t mean it’s unimportant, mind you – “least” is a relative term – but there’s so much more that goes into building and running a successful application or service than commands and semicolons.
Why you should pave roads
Reading a lot about platform engineering kept reminding me about the concept of the paved road (I’ve also seen the term “golden path”) in software engineering. It’s easy to understand why – if you do platform engineering correctly, then you end up with a paved road. Spotify probably has the best definition of a golden path (emphasis mine): “The Golden Path — as we define it today — is the ‘opinionated and supported’ path to ‘build something’ (for example, build a backend service, put up a website, create a data pipeline).” For all practical intents and purposes, a paved road is essentially the output of platform engineering. But why should we be trying to pave these roads? Shouldn’t we just build a stack and incorporate toolsets specific to each project, app, or service? Surely that way we can optimize for the specific problems each was built to solve, right? Wrong.
Taking the Scott Adams better congressional incentives challenge
Back in December, Scott Adams (of Dilbert fame) posted a tweet commenting on the general dissatisfaction on the budget omnibus bill that had recently passed. It’s a surprisingly interesting problem, because Congress largely sets its own rules, so any change can be just as easily undone or even ignored in the name of an “emergency” or “extenuating circumstances” (which are incredibly easy to find if you don’t want to live by the rules). In other words, how do we convince people to act against their own self-interest without having the direct power to set the rules they’re operating under? I think there’s a potential solution, but it’s going to hinge on several states getting on board.
Why are cross-functional teams so hard to build?
So after taking a brief break to write about Twitter, because that’s everyone’s new favorite hobby, I wanted to revisit part of my central thesis in my posts on platform engineering – that it’s hard to find places with actual cross-functional teams capable of doing everything needed to build and run an application or service from concept to being used in production. I’m not totally sure why this is something that organizations don’t want to do, but I still don’t platform engineering is the solution (or as I’m sure some companies will try to spin it, “compromise”). Continue reading »
Decentralization and aggregation
So apparently there’s this hot new app that just released called Mastodon, and everyone’s leaving Twitter to join that. It’s OK if you haven’t heard of it, it’s that new. Snark aside, people are stumbling onto Mastodon because they’ve been told it’s the biggest Twitter alternative (it probably is), which isn’t really saying much – there aren’t a lot of Twitter alternatives that anyone would really think twice about. It does a good job of replicating the basic Twitter experience, type some things into a box and click the post button to publish. But there are important, non-obvious (to general users) differences between Mastodon and Twitter, and people seem to be struggling with them.
Twitter the (breaking) news app
Elon Musk has tweeted extensively about Twitter and journalism, and what that can mean for the future. I know a lot of people like to complain about his approach to running Twitter, but I think there’s something to his ideas. I once thought that WikiTribune would be the bridge that leads to a new type journalism due to its wiki-style approach. I was clearly wrong, as WikiTribune lasted about 2 years and is now a social media site. Twitter, however, may be able to succeed where WikiTribune failed, assuming it can figure out a business model that keeps the servers on.
Will platform engineering be the mass-reproducible secret to great software development?
When people talk about the “death of DevOps,” platform engineering is brought up as its successor. That’s probably overstating things. The practices associated with platform engineering certainly look like they have a lot to offer, but getting platform engineering right is difficult. And getting platform engineering right is important, because that’s the only way platform engineering is going to work. Otherwise, what you’re going to end up with is a mashed-up team of random engineers desperately trying to keep infrastructure afloat while developers wreak havoc on everything.