Article summary
Software development is complex. It involves managing intricate domain logic and complicated features that evolve. Too much complexity stifles a team’s productivity. That’s why, in the face of complexity, I strive to write simple code. In fact, the more complex a project is, the more I push for simplicity in the codebase.
Unlocking Potential
Consider the time it takes a developer to understand the changes needed to implement a feature. Generally, the more challenging and important it is to get the changes right, the more significant the time-spend.
Conversely, this implies that, when the changes are easier to get right, they can be made quicker. It also suggests that by making mistakes less risky, they also become quicker. I boil that down to this equation: easy + safe = quick. Think of times when you’ve been able to move your quickest. I suspect you knew what to do, felt safe doing it, and could easily confirm that it worked.
Easy, safe, and quick: that sounds great, but how? When something is easy to change, it’s because it’s trivial to identify what it does and how it functions: it’s simple. When there is low risk associated with changing something, it’s most likely because you understand it. When you understand it, you’re confident you can change it in a way that won’t break things. In other words, it’s safe.
Simplicity and safety are at the heart of unlocking a development team’s potential.
Compounding Benefits
Although I alluded to increasing development speed earlier, the benefits of simplicity and safety go beyond that. Unpacking what simple and safe looks like on a software project is a good way to expound on the other benefits. Here’s how I’d characterize such a project: Easy-to-understand code sews confidence in devs that they can make changes without breaking other things.
For the same reason, developers with less experience are more comfortable contributing. Devs understand the ramifications of their changes but also feel that, if something unanticipated occurs, they won’t break things.
Developers who are unfamiliar with parts of code can determine its purpose and the circumstances under which it runs quickly. Diffs in code reviews are palatable and generally more easily reviewable by any team member.
At a higher level, the project benefits from a quicker development cycle. The product experiences more frequent iterations, developers obtain greater project and domain “wisdom.” In turn, ownership becomes more distributed across the team.
Making Things Simple & Safe
Everything described above sounds nice, but easier said than done. There’s an art to making software simple. But, if you pay attention to certain areas, a team can reap the benefits of a simple and safe codebase.
Get the big things right.
Choosing a good tech stack, architecture, tooling, etc., won’t guarantee your project is a success. But, choosing a bad one will probably guarantee it isn’t. Assembling the core pieces of your project and workflow is essential to enabling simplicity. Unfortunately, the ability to make the right selections ranges from obvious to a shot in the dark depending on the feature set. It’s also the hardest thing to change later. Additionally, developers will be more or less familiar with each tech stack, and this has its own implications.
Abstraction is another important one to get right. Since every app will have some level of abstraction, it can be characterized as a Goldilocks problem. Most apps will have some level of application, A basic app that is over-abstracted becomes overly complex and difficult to change. A complicated app without sufficient layers of abstraction becomes difficult to manage and therefore complex. The trick is to match the needs of the application with the appropriate abstraction that can support the feature set.
Lighten the developer’s load.
Developers already keep a lot in their heads. Taking the trivial things off of their plates expands their ability to focus on the problem at hand. Configuring an auto-formatter (that runs on save) is a no-brainer way to make life easier. There’s no need to have devs regularly thinking about indentation.
Another way of lessening a developer’s load is automated testing. It is invaluable to have a reliable way of determining whether their changes are safe or if they’ll break something. Testing for the sake of testing isn’t great, but having a sane automated test suite pays dividends. In my experience, a trade-off is involved here because devs are often the ones writing the tests.
Avoiding manual deployment by using CI/CD adds both simplicity and safety. It makes deployment easier in general and helps the team recover quickly from issues.
Quarantine Complexity, Spread Simplicity
The reality is that every application has some complexity. There are really difficult problems out there that require sophisticated solutions. When facing something like this, the best thing to do is containerize the complexity. This could take many shapes. Ultimately though, the goal is to isolate most of the day-to-day development from the trickiest aspects of working with the complexity
Establish patterns when possible. It’ll be easier for the team to jump into something unfamiliar if it aligns with patterns they already know. Try to make them easy to follow and capable of evolving over time.
Be on the lookout for acceptable tradeoffs that offer simplicity in exchange for time or performance. For example, if there’s an area of code that a lot of developers tend to work in, consider saving significant optimizations for later, and allow everyone to keep it simple.
Additionally, try to ensure the code is reasonably self-documenting. PR review and pairing are good opportunities to norm on what this means in the context of your project. There’s a big difference in the readability of something like:
if(x === “red” && y === “sweet”) { console.log(“It’s a raspberry”)}
// vs
const isRaspberry = x === “red” && y === “sweet”
if(isRaspberry) {console.log(“It’s a raspberry”)}
What are other ways to ensure your codebase is simple and that developers can safely make changes?