Simplicity is a technical decision

Complexity can reflect correctly handling edge cases and maintaining business rules. However, it can also reflect solving the solving the wrong problem entirely — introducing solutions for perceived problems without evaluating the short-term and long-term cost of each solution against the cost of the corresponding problem. Once introduced, the influence of this unnecessary complexity can quickly spread across requirements, processes, tools, and code.

Unnecessary complexity can grow further as teams introduce mismatched practices, tools, libraries, and patterns across a loosely-governed system. Without firm guidance, a simple system will implicitly be taken as an opportunity to add solutions and solve perceived gaps. Some of these solutions will add too much complexity. As a maintainer of a software system or leader of a team, you should be willing to respectfully say no to these.

More proactively, you can make simplicity an explicit decision. Just as you might document an architectural decision, such as a decision to adopt a given solution or a comparative analysis of tools, document a decision to adopt none of the above with the same confidence as any other technical choice. Simplicity is a deliberate technical decision.