4 ms·

Complexity is a fact of the world we live in. The human body is extremely complex, but all organs and systems in the human body work in harmony and with astound

Complexity is a fact of the world we live in. The human body is extremely complex, but all organs and systems in the human body work in harmony and with astounding efficiency. We need to stop fighting complexity in software and embrace it instead. The goal shouldn't be to pursue simplicity at the cost of ignoring complexity of the domain being modelled, but to acknowledge that we're modelling a complex system, and design it such that subsystems work together in harmony. This article in particular touches on an important point which resonates with me. It's what I call "displacement oriented design". I view a code base as a puzzle that grows in size over time; you can't grow a puzzle just by adding to it and leaving all other pieces intact. As you expand the size of the puzzle you need "displace" some of the existing pieces, reshape them, and fit them with the new pieces.

nchelluri 6y ago
I agree with some of your points and disagree with others. The human body is exceptionally awesome, but also so very fragile. I think we can do better with well-thought-out design, and a part of that that I embrace is the value of simplicity. My thoughts can be best said with a quote (especially the part about a complexity budget): > I used to tolerate and expect complexity. Working on Go the past 10 years has changed my perspective, though. I now value simplicity above almost all else and tolerate complexity only when it's well isolated, well documented, well tested, and necessary to make things simpler overall at other layers for most people. For example, the Go runtime is relatively complex internally but it permits simple APIs and programming models for users who then don't need to worry about memory management, thread management, blocking, the color of their functions, etc. A small number of people need to understand the runtime's complexity, but millions of people can read & write simple Go code as a result. More importantly, Go users then have that much more complexity budget to work with to build their actual application. I would've never built Perkeep had I needed to fight both its internal complexity and the complexity imposed on me by other contender languages/environments at the time. > > All that is to say, simplicity is not only refreshing, but it also enables. Go made me feel productive in a way I hadn't felt in many years where everything just felt like it was getting more complex. Ever since finding Go, I've been regularly hunting for other technologies that provide simplicity as a feature. https://bradfitz.com/2020/01/30/joining-tailscale https://bradfitz.com/2020/01/30/joining-tailscale
- khaledh 6y ago
  I agree on the distinction between internal vs. external complexity; this particularly resonates with me: "the Go runtime is relatively complex internally but it permits simple APIs and programming models for users...". I probably should've made it clear that the external interface of a system (whether it's a UI or an API) should be simple and abstracts away the internal complexity. To go back to the human body analogy, while the internals of the human body are complex, the external interface is extremely simple: you eat to get energy; you sleep to get rest; you use your reproductive organs to reproduce; etc. You don't have to learn how the internal systems work to operate your body.

nchelluri 6y ago

I agree with some of your points and disagree with others. The human body is exceptionally awesome, but also so very fragile. I think we can do better with well-thought-out design, and a part of that that I embrace is the value of simplicity. My thoughts can be best said with a quote (especially the part about a complexity budget): > I used to tolerate and expect complexity. Working on Go the past 10 years has changed my perspective, though. I now value simplicity above almost all else and tolerate complexity only when it's well isolated, well documented, well tested, and necessary to make things simpler overall at other layers for most people. For example, the Go runtime is relatively complex internally but it permits simple APIs and programming models for users who then don't need to worry about memory management, thread management, blocking, the color of their functions, etc. A small number of people need to understand the runtime's complexity, but millions of people can read & write simple Go code as a result. More importantly, Go users then have that much more complexity budget to work with to build their actual application. I would've never built Perkeep had I needed to fight both its internal complexity and the complexity imposed on me by other contender languages/environments at the time. > > All that is to say, simplicity is not only refreshing, but it also enables. Go made me feel productive in a way I hadn't felt in many years where everything just felt like it was getting more complex. Ever since finding Go, I've been regularly hunting for other technologies that provide simplicity as a feature. https://bradfitz.com/2020/01/30/joining-tailscale https://bradfitz.com/2020/01/30/joining-tailscale

khaledh 6y ago
I agree on the distinction between internal vs. external complexity; this particularly resonates with me: "the Go runtime is relatively complex internally but it permits simple APIs and programming models for users...". I probably should've made it clear that the external interface of a system (whether it's a UI or an API) should be simple and abstracts away the internal complexity. To go back to the human body analogy, while the internals of the human body are complex, the external interface is extremely simple: you eat to get energy; you sleep to get rest; you use your reproductive organs to reproduce; etc. You don't have to learn how the internal systems work to operate your body.