It seems like every time I turn around I find someone else describing
their product, API, architecture or service as beautiful or elegant. I
believe the use of these terms in tech was pioneered by Apple Inc. or
more specifically the late Steve Jobs. Jobs and Apple have been the
defacto gold standard for design since the first iPod was released and
have inspired generations to think about design as a first class concept
in not only products and services but also APIs and architectures.
One word that is constantly associated with the perception of elegance, cleanliness and beauty is simplicity / simple. Simple design is not an excuse for poor design but rather a concerted effort to directly meet a need as efficiently and effectively as possible and without unnecessary elements. A simple product does exactly what it promises, no more, no less.
Developers and architects often try to over-engineer solutions for several reasons. Over-engineering is typically motivated by a need to;
Some benefits of simple design are:
Simple is easier to debug and fix. Because there are fewer moving parts, there is less that can be broken and when something does break, its easier to find it and fix it. A consequence of this ease is a system that is much cheaper to build and maintian when compared to a complex project. The simplicity of the design or architecture also results in stability. There is less to refactor. As the French writer Antoine de Saint-Exupery said "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away".
Simple is more performant. As a result of booting unnecessary features, abstractions, tasks, frills, etc. from a design the product is made more performant. The less an application does, the fewer CPU cycles, memory and I/O it needs. Applications should get a user from A to B as quickly as possible without putting roadblocks in the user's way.
Simple is more communicable and approachable. This results in a design or product that is easier to pitch to stakeholders and easier to get buy-in on. This enhanced communicability promotes dialogue and feedback and makes it easier for others to champion your product. Approachability makes a product more appealing to users.
To be balanced it should be noted that simplicity sometimes comes at the cost of flexibility. For example, a GUI interface may provide more simplicity than a command-line interface but it may do so at the cost of flexibility. Another instance in which this shows up is in the offering of myriads of options and configurations versus offering only one or two. Flexibility is often a response to complexity. In an effort to handle the messiness of the real world we often turn to creating products that can adapt, accept multiple inputs, have multiple configurations, etc. If a need for flexibility is present, it should always be balanced with the need for simplicity. Here are some thoughts on how to combat complexity and simplify your design:
One word that is constantly associated with the perception of elegance, cleanliness and beauty is simplicity / simple. Simple design is not an excuse for poor design but rather a concerted effort to directly meet a need as efficiently and effectively as possible and without unnecessary elements. A simple product does exactly what it promises, no more, no less.
Developers and architects often try to over-engineer solutions for several reasons. Over-engineering is typically motivated by a need to;
- code for the future
- build a system that targets multiple uses / users
- try to take every possible solution into consideration
- impress management or other developers.
Some benefits of simple design are:
Simple is easier to debug and fix. Because there are fewer moving parts, there is less that can be broken and when something does break, its easier to find it and fix it. A consequence of this ease is a system that is much cheaper to build and maintian when compared to a complex project. The simplicity of the design or architecture also results in stability. There is less to refactor. As the French writer Antoine de Saint-Exupery said "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away".
Simple is more performant. As a result of booting unnecessary features, abstractions, tasks, frills, etc. from a design the product is made more performant. The less an application does, the fewer CPU cycles, memory and I/O it needs. Applications should get a user from A to B as quickly as possible without putting roadblocks in the user's way.
Simple is more communicable and approachable. This results in a design or product that is easier to pitch to stakeholders and easier to get buy-in on. This enhanced communicability promotes dialogue and feedback and makes it easier for others to champion your product. Approachability makes a product more appealing to users.
To be balanced it should be noted that simplicity sometimes comes at the cost of flexibility. For example, a GUI interface may provide more simplicity than a command-line interface but it may do so at the cost of flexibility. Another instance in which this shows up is in the offering of myriads of options and configurations versus offering only one or two. Flexibility is often a response to complexity. In an effort to handle the messiness of the real world we often turn to creating products that can adapt, accept multiple inputs, have multiple configurations, etc. If a need for flexibility is present, it should always be balanced with the need for simplicity. Here are some thoughts on how to combat complexity and simplify your design:
- Strive to do only one thing. If you have to do more than one thing, break your product into modules. Microservices architectures and other design patterns are prime examples of this philosophy in action.
- Communicate clearly. Your application should clearly and succinctly state its purpose and deliver that. Implicit understandings and side effects should be eliminated.
- Eliminate unnecessary things; steps, frills, options. You Aint Gonna Need It.
- Design from the user's perspective. This is probably the most important item on the list. Take off your designer / architect hat and think like a user. What would I like to see? How would I like to interact with this system?
- Always hide complexity unless it is required. A simple design does not have to pretend that complexity does not exist, but it can hide it and make it available upon request by the user via a "more options" button or flag.
