Simple in design and simple in implementation

Introduction

Software simplicity is a prerequisite to reliability.

Every time we say "no" to a feature, we are not restricting innovation; we are keeping the environment uncluttered of distractions so that focus remains squarely on innovation, and real engineering can proceed.

Laymen explanation

A smaller project is easier to understand, easier to test, and frequently has fewer defects. But do you want your software to be smaller always? What about adding new features to add value? Do you know, adding any unused feature bloats your code? A software bloat may lead to end of life of the software itself.

Technical explanation

Software systems are inherently dynamic and unstable. If we stop changing the codebase, we stop introducing bugs. If the underlying hardware or libraries never change, neither of these components will introduce bugs. If we freeze the current user base, we’ll never have to scale the system.

For the majority of production software systems, we want a balanced mix of stability and agility. At the end of the day, a software team job is to keep agility and stability in balance in the system.

Essential complexity and accidental complexity

Essential complexity is the complexity inherent in a given situation that cannot be removed from a problem definition, This is the called simplest approach to solve a problem correctly
Accidental complexity is more fluid and can be resolved with engineering effort. This happens due to complex unnecessary design choices and/or complex unnecessary implementation approach.
For example, writing a web server entails dealing with the essential complexity of serving web pages quickly. However, if we write a web server in Java, we may introduce accidental complexity when trying to minimise the performance impact of garbage collection.
Software team should thrive to zero down accidental complexity

Software bloat

Adding new features create software bigger and at the same time it can lead to bloat if it tends to add accidental complexity
Every line of code changed or added to a project creates the potential for introducing new defects and bugs.
A smaller project is easier to understand, easier to test, and frequently has fewer defects.
We should perhaps entertain reservations when we have the urge to add new features to a project.
Some of the most satisfying coding I’ve ever done was deleting thousands of lines of code at a time when it was no longer useful.

Why Code not in use should be removed

"What if we need that code later?" "Why don’t we just comment the code out so we can easily add it again later?" or "Why don’t we gate the code with a flag instead of deleting it?" These are all terrible suggestions.
Hundreds of lines of commented code create distractions and confusion (especially as the source files continue to evolve), and code that is never executed, gated by a flag that is always disabled, is a metaphorical time bomb waiting to explode, as painfully experienced by Knight Capital, for example (see "Order In the Matter of Knight Capital Americas LLC" [Sec13]).
Source control systems make it easy to reverse changes and so, it is best to delete the unused code at the first place.
It facilitates simplicity in coding by allowing readability to new person, reduced if-else cases

UX impact

Writing clear, minimal APIs is an essential aspect of managing simplicity in a software system.
UX is not same as UI for end-user
UX is about experience of any user consuming your module/API. For example, application coder is the user for library and application programmer experience is UX of library.
In software, less is more! A small, simple API is usually also a hallmark of a well-understood problem.

Object-oriented approach

The ability to make changes to parts of the system in isolation is essential to creating a supportable system.
As a system grows more complex, the separation of responsibility between APIs and between binaries becomes increasingly important.
A well-designed distributed system consists of collaborators, each of which has a clear and well-scoped purpose.
Object orientation and design pattern provides tool to achieve above

Release cadence

If the release is performed in smaller batches, we can move faster with more confidence because each code change can be understood in isolation in the larger system.
It is much easier to measure and understand the impact of a single change rather than a batch of changes released simultaneously.

SRE/DevOPs processes

SRE’s experience has found that reliable processes tend to actually increase developer agility: rapid, reliable production rollouts make changes in production easier to see. As a result, once a bug surfaces, it takes less time to find and fix that bug. Building reliability into development allows developers to focus their attention on what we really do care about—the functionality and performance of their software and systems.

KISS principle

The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore simplicity should be a key goal in design and unnecessary complexity should be avoided.

Tips for simplicity thought

Work hard to get your thinking clean.
Challenge and question your logic more often!
Ask “why?” to yourself and your colleagues.
Always try to apply YAGNI, KISS, DRY principles keeping in mind the balance.
Always keep in mind how easy other people will understand your approach. Think about newcomers as well.
Forget about your ego and make clarity your priority.
Think about software-development as a team effort, not an individual one.
Think about complexity as a liability.
Always choose the simplest technology you can to finish the job

Reference

https://landing.google.com/sre/sre-book/chapters/simplicity/

https://tech.kartenmacherei.de/simplicity-in-software-engineering-is-not-simple-979cf098e4b1