I have been to Japan twice this year. In fact, what impressed me most about Japan is not the cleanliness, good air and courteous service that people often talk about, but the design that is everywhere. The packaging of the product, a guidepost, the signboard of the roadside snack shop, the clothes of the pedestrians, although they are different in shape, quality and use, they always give people a simple, delicate, human nature and a comfortable sense of connotation. I think it is these small and large, omnipresent beauty that has fostered today’s relatively mature Japanese society.




When it comes to design, I have read some books by Japanese designers, such as “Awakening of Design” by Ichimitsu Tanaka, “Design and Death” by Masayuki Kurokawa, “Why Design”, “Design of Design” and “White” by Kenya Hara. The concepts of minimalism, de-decoration and functionality of design proposed by these Japanese design masters and continuously inherited have been deeply imprinted in contemporary Japanese design. And the thing that inspired me the most was what they told us in the plainest language, “That’s fine.”

Today, as a programmer, WHEN DESIGNING systems, I often ask myself: “Is this how it works? If we don’t have to, we don’t need to add this additional feature.” It was under the guidance of “this is just fine” that I seemed to have a deeper understanding of how to program properly.

IT was during my time as an architect that I was in charge of reviewing an IT project for my company. During the review, the project manager devoted the lion’s share of her presentation to the system’s ability to support personalization and the ability to change color themes at will. I thought at that time, the project manager must have failed to understand the real needs and pain points of the users, and the system can change colors, probably there is no bright spot.

As programmers, how many of us have been enamored with the idea of a system that is big and complete, with optional configuration features and customization as cosmetic. While these features seem to add value to our product, are they really what users want most? If we had to go back in time, would we still pay those costs to implement these features?

Great systems don’t happen in a vacuum, and there is no single standard for them, but “just the way it is” can guide us as system designers in balancing choices. What architecture to use, what technology to use, what design patterns to use for this feature, what caching strategy to use, and so on, all required appropriate choices based on the environment, resources, users, and so on at the time. Rather than having a lot of features that the end user doesn’t always feel good about, it’s better to have a feature that really helps the user solve the problem and make them think, “HMM, that’s fine” and then take it a step further, “If only… It will be better “, so step by step to make the ideal product.

Here are some things to avoid in system design and development:

  • Don’t blindly use new technology: New technology implies risks and uncertain costs (mostly due to fixing unknown defects), so in my financial industry, it is rare to choose technologies that are emerging (within 1 year) in favor of mature and steadily evolving technologies or frameworks.
  • Avoid over-design: Over-design is the result of the system designer not understanding the real needs of the users, and then putting on top of the system what they think is necessary. The aforementioned configurability, personalization, and so on are the most typical examples. To avoid excessive design is also very simple, to do more (look at the good system is how to design the similar functionality), more want to (stand at the user’s point of view to think about what they demand what is the real pain points and problems behind), do (don’t just stay on the requirements document, as soon as possible to make to verify the function prototype of demand, Then continuously confirm and improve with the user), speak more (maintain continuous and effective communication with the user at every stage).
  • Not gold-plated technology in the project: gold-plated technology refers to the development of developers in the project development too pursuit of technical perfection, trying to plating a layer of perfect gold shell on the technology, resulting in increased software development workload, project time, and ultimately may lead to the failure of the whole project. We should not deny the programmer’s pursuit of perfection, but we should guide them to understand the concept of “this is just fine” in the project, and help them balance the pursuit of perfection with the practical requirements of the project to make the most appropriate technical solution choice.

In the end, even if you have a good understanding of “that’s fine” and can come up with a better system design, the result is likely to be rejected. You may be dealing with immature project managers, product managers with blind arrogance, and business users with no product thinking at all, for whom the sugar coating (the added features of the system) is always very attractive. You can try to convince them, but even if you fail, you don’t need to be upset because time will prove you right, and you should know in your heart that you are growing older and taller.