Things your mom didn't tell you about iOS
Misalignment and miscommunication are major, often underestimated sources of complexity in software projects. While previous chapters explored complexity within the codebase and within ourselves, this one shifts focus to the social layer: how teams, stakeholders, and individuals interact — or fail to — and how that influences the systems we build.
When we talk about complexity in software, we often focus on technical causes — sprawling architectures, tight coupling, or poorly structured code. But underneath all of that lies a deeper source: human nature itself. The way we think, reason, decide, and collaborate directly shapes the systems we build. This article explores the human side of software complexity, not to eliminate it, but to…
Software is made of boundaries. From functions to classes, modules to services, systems to organizations — every meaningful split in a codebase depends on one thing: the interface.
In software development, abstraction is one of our most powerful tools — it allows us to hide irrelevant details and work with simplified mental models. It’s how we manage complexity: instead of thinking in terms of bits and bytes, we work with concepts like buttons, lists, users, or invoices. The goal of abstraction is to make systems easier to understand, use, and evolve by reducing the amount…
In the previous chapters, we explored how low-level decisions and poor code organization contribute to growing complexity in software systems. These topics dealt mostly with how we write code. In this chapter, we take a step back to look at a higher-level cause of complexity — one that often lies deeper than syntax or structure: the misalignment between the problem and the solution.
How we distribute logic and structure code across a project plays a major role in how complex that project feels. Even well-written code can become hard to work with if it’s scattered, inconsistently organized, or buried in the wrong place.
In this piece, we focused on low-level decisions in code that quietly increase cognitive load: things like poor naming, deep nesting, magic values, etc. These choices often go unnoticed in the moment, but their impact adds up — making code harder to understand, maintain, and extend over time.
This is the introduction for the Complexity series - a set of articles where we will explore the causes of complexity in our projects (not only related to the code) and the ways to minimise it. In this piece we will touch upon what exactly complexity is, how can we measure it and why should we care about it at all. In the
In this article we will be talking about the recent changes related to protocols: opaque, existential and generic types; some and any; runtime and compile-time polymorphism.
In this article we will discuss the problem that can be solved by modularity and how exactly modularity can make you project much better thing to deal with.