Prefer simplicity to complexity
Complex solutions cost more to build, harm user experience and hinder scalability.
80% of the software engineers and product owners know that. But why do we still make the mistake over and over again? Because we don't know how to build a simple solution.
To learn to build a simple solution, we can look at how to build a complex solution and then avoid those practices. As Charlie Munger's favourite saying, "Invert, always invert".
Complex solutions have a nickname called over engineering in the software development world. And there are two main ways to over engineer a solution:
- Building a product with lots of unused or unimportant features. One good example of this is Microsoft Word. What's the percentage of features do MS Word do you need to use frequently? I bet it's less than 20%. Over engineering in the product features level makes the product more expensive to build and maintain. And very often confuse your users.
- Building a product in a complex way. How to build a product in a complex way? Here are three practices:
- Make your program work overly hard to accomplish something relatively simple. How many times your program calls "select * from xyz" and then you cherry pick the columns from the result set you need? How many times you recreate an HTML page right after you display it? You get the point?
- Make your user work harder than it's necessary. To make your user work harder than required, put in some unnecessary fields for the user to field in for the sack of completeness; cram in some odd features for the sack of flexibility. If 99% of the users don't care about exporting the blog into pdf, why do you want to build it?
- Make it harder for your fellow engineers to understand your code. This comes in two favours: You either design your system in a over complicated way or you didn't implement it properly. Good engineers understand that we should strive to produce programs that everyone can understand. The true hallmark of a great engineer and expert in any field is the ability to solve a complex problem in simple ways. One simple way to test if your design or code is hard to understand is to invite engineers from different team and of different levels in the company to review your system. The good news is that it's never too late to learn to design and implement simple systems. And the pay off for you and your organization will be huge.
In summary, to achieve a simplest solution to a software engineering problem, we should recognise the above traps and try to avoid them proactively.
SRE / Cloud Architect
9 年Simplicity is definitely preferable. But I feel the main reason, why most employees(esp seniors at big corporate) create complex things is due to poor trust. i.) Create dependency, else position is at stake. ii.) Have to always show doing something or other (doesn't matter whether useful or not), else get questioned. iii.) Do all automation, next min his job sacked. To an extent, I support employees as Management has higher role in creating trust, fairness and healthy atmosphere.