Feb 292024
 

The natural corollary to trying to manage complexity is a desire to keep things simple. Which is, in general, a good thing to do. Simpler code is easier to maintain, easier to debug, easier to test, and just plain easier. But even though we’re on a never-ending quest to make things “simple,” it’s easy to get distracted by heuristics that aren’t really good proxies for simplicity, and as a result make things more complicated than they need to be.

Read more: Keep it simple, stupid

When talking about simplicity, we need to start with something simplicity is not, and that’s lines of code (more or fewer). To start, let’s look at the case of being overly clever, and using some obtuse 1 or 2 line bit of abstract trickery to do something that can be done explicitly over 5-10 lines of code. Yes, in that instance more lines of code are certainly simpler to understand. But there’s also times where you have dozens of lines of convoluted logic, tons of branching paths that, after some time and thought, can be condensed into a more straightforward flow can reduce the number of lines of code and be simpler. So are 1 of these instances some sort of simplicity paradox? No, but like “best practices,” it’s easy to see these examples to focus on the characteristics of a situation, rather than the principles behind the decisions.

Code simplicity isn’t about the code at all (as counter-intuitive as that may seem) – it’s about the developer having to read, understand, and work with the code. In other words, simplicity is another way of discussing code’s readability – which means emphasizing clarity and focus in the code. By the way, “code” here refers to more than just lines in {insert your favorite programming language here}. It also organization, variable and method names, and meaningful comments (the kind that discuss data state and the applicable business rules).

It’s also worth mentioning that just because something is simple doesn’t mean it isn’t powerful – the 2 terms aren’t mutually exclusive. In fact, you can very often get something that seems like it can do a lot, written by developers who seem to be able to put out new updates with ease, precisely because people put a lot of work in up-front keeping the code as simple as possible. As a result, the codebase is easier to understand (which makes onboarding new developers and reviewing new code easier), and easier to test (so you can develop faster without fear of regressions), letting developers focus their time, energy, and complexity budget on the parts of their problem domain that are actually complicated. And, spoiler alert, the most successful companies are generally the ones that manage to find ways to simplify those complicated parts too.

It’s the “saying ‘no’ a thousand times for every ‘yes'” philosophy Apple used to swear by. More “stuff” adds more complexity, and more complexity is more friction in using your product. That makes your users think more about how to use your application when they should be thinking about the thing they’re accomplishing because they used your application. Now, some products try to solve this problem by doing the thinking for you, and just making something happen automatically. It’s important to understand something – this doesn’t actually make things simpler. If you’re making an honest effort at this then you likely have a bunch of code to collect user behavior, and then use that to try to “predict” what they want to do given any context. And here’s the thing – if you’re right, it’s a slight convenience, but if you’re wrong then your software is actively angering them by doing what they don’t want. How often are you right by the way? Do you have any way of measuring that?

On the other hand, you can offer a simpler experience by letting the user easily tell you what they want, and then doing that. No need to track and capture a bunch of behavior, no need to run machine learning or intuit preferences, just simply following simple instructions. It’s the exact same output, but with a high satisfaction rate because you didn’t over-complicate things trying to think for your users.

There’s a lot of complexity involved in software, but it’s our job to reduce it as much as possible. That includes breaking the problem down into simpler chunks, keeping the logic as simple as possible, making the code as simple to comprehend as possible, making interacting with the software as simple to do as possible, and making it as simple as possible for users to end up in the state they actually wanted (as opposed to the state you assumed they wanted). If we succeed in doing that, our software is just plain better.

 Posted by at 11:45 AM
Jan 312024
 

The key mantra my computer science professors worked hard to drill into us at college was always “Computer science is about solving problems, computers are simply a tool we use to do it.” As fun as it is to meme about the technical interview vs. the actual job, the reality is that we actually do have to figure out how to implement things that make the business money from time to time. When that happens, the ability to work through problems is what separates the successful developers from the code monkeys who can implement pseudo-code off a user story. And given some of the technical interviews I’ve sat in, it’s not necessarily a skill that’s developed when teaching people how to code.

Continue reading »
 Posted by at 11:45 AM
Oct 312023
 

It’s common for online applications to refer to themselves as a “platform” as soon as they have a public-facing API. Facebook is probably the biggest example of this, but it’s a fairly standard marketing tactic (I used to work for a company that did the same thing). Basically you make some public-facing endpoints, and voila, you’re now a “platform” – and developers please build stuff for us, so we can increase customer lock-in. That’s not how this actually, or ever, works – because that’s not how platforms work.

Continue reading »

 Posted by at 11:45 AM
Sep 292023
 

The term “exit” always irritated me when people write about startups. Especially because it only happens when a company is either bought or IPOs. I’m not saying that startups don’t use acquisition (or IPOs if you’re Twitter – never X) as an exit strategy to avoid actually making money, but a lot of times companies do this after they’ve become a profitable, self-sustaining business. Despite that, we still don’t have a clear definition of when non-retail companies stop being startups and start being plain old businesses (even if they’re small), and it needs to be fixed.

Continue reading »

 Posted by at 11:45 AM
Jul 312023
 

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?

Continue reading »

 Posted by at 11:45 AM
May 312023
 

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.

Continue reading »

 Posted by at 11:45 AM
Mar 312023
 

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.

Continue reading »

 Posted by at 11:45 AM
Jan 312023
 

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 »

 Posted by at 11:45 AM
Dec 312022
 

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. 

Continue reading »

 Posted by at 8:00 AM
Nov 302022
 

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.

Continue reading »

 Posted by at 11:45 AM