3 ms·

3. Simplicity Fighting complexity is a never-ending cause. Solutions should be as simple as possible. Assume the next person to maintain your code won’t

3. Simplicity Fighting complexity is a never-ending cause. Solutions should be as simple as possible. Assume the next person to maintain your code won’t be as smart as you. When you can use fewer technologies, do so. This is the one I appreciate more and more as I age. Because frequently, I'm the next person looking at my own code. And there's no better gift to your future self than well-written, easy-to-understand code that is straightforward to maintain.

castlecrasher2 6y ago
>Assume the next person to maintain your code won’t be as smart as you. It's especially easy to assume this because I've often gone back to code I made a year or even months ago and barely understand it.
- deleted 6y ago
  [deleted]
jjice 6y ago
At a previous job, I was the only person to document architecture structure and design choices in a document in each repo I worked on. They turned out to be very helpful for the new employees we took on over my time there. While that's a great plus, the real reason I wrote those was for myself because there is no way in hell I'll remember how to deploy this app to a new EB instance.
- trentnix 6y ago
  That describes my motivation for writing documentation perfectly. In my last job, I wrote documentation so I could quickly get back into the context of the different problems I was working on. Context switching was a real challenge in that environment and I referred to my own documentation frequently. And sometimes, writing documentation helped me better understand the problem I was working similar to the idea that teaching a topic is a great way to learn.
koonsolo 6y ago
I came here to say the exact same thing, but I want to extend it a bit more. I've seen some developers, including myself, looking at some code and complaining "who the hell wrote this mess!", only to find out in repository history it was themselves. lol.
- trentnix 6y ago
  ...every day of my life!
astrobe_ 6y ago
I somewhat disagree with the way he connects simplicity and cleverness. I once had to explain the behavior of a particular subsystem. It was governed by a bunch of simple rules, but their combination created a complex behavior. This was similar to social insect colonies, where components (eg. ants) are driven by relatively simple rules, but the whole system exhibits remarkable "emergent behavior". What takes cleverness is to anticipate, predict, understand,explain the global complex behavior from the simple rules. If someone can predict what comes out from cellular automatons like in the game of life, I am amazed. Simple is not easy (no, sorry Rich, following your simple advice is not that easy either). Simple is not always easy to understand, even less so easy to do. That's why complexity tends to accumulate. At the risk of being wronged, I would say that being comfortable with complexity is a form laziness. I belong to the messy type of person. I believe I am that way because I can rely on a good long term memory: because of that, I can yield to laziness and not put away things where they belong when I should. Being able to handle complexity is a great quality, but not being discomforted by complexity is like not being ashamed by your messy home. When you make the effort to really simplify, under the favorable circumstances (like in hobby projects, where you can afford to move goalposts a bit), you can make complexity collapse - not by its own weight, for once. I understand that the author emphasis teamwork and communication so he gives this kind of John Wood's "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live" justification for fighting complexity, but preventing complexity from collapsing by its own weight, crushing a product in the process, is to me on equal grounds.
- zmmmmm 6y ago
  > I would say that being comfortable with complexity is a form laziness I love this, and your comment in general!
- Arelius 6y ago
  I think an important continuation of this same thought however is that since complex systems can emerge out of simple rules. And since reasoning about the behavior of entire systems (emergent or otherwise) is an essential element of being a programmer. It true that over simplification of the elements and generalization can actually result in a much more complex and difficult to reason about system, just as you point out about the game of life. I guess my point is that sometimes the systems model essential complexity, and by trying to over simplify and generalize elements of that system, you may make the system as a whole more difficult to understand and reason about.
ww520 6y ago
Yes, simplicity is so important. I often adopt the stand of designing and writing software that I could forget. The intent is such that when I come back to the code I've written, it'd better be understood easily. That means keeping things simple, keeping things clear, keeping things consistent, and keeping things well documented. Simplicity helps a lot.
ankurdhama 6y ago
The the idea of simplicity in software engineering is one of those hand wavy stuff that the conventional wisdom is full of. The simplicity (or the complexity) depends on what you want to do (requirements). If the requirements themselves are complex then expecting the code to be simple just doesn't make sense. Also piece of code would look simple to a person who has been working on it for long time and has the background knowledge vs a person who is new to the system. Another thing to remember is that software systems are built incrementally i.e for each new requirement the developer have to figure out "how to implement this new requirement in this given code base with minimal changes" and this eventually will lead to complexity (unless you want to do big refactor on each new requirement).

castlecrasher2 6y ago

>Assume the next person to maintain your code won’t be as smart as you. It's especially easy to assume this because I've often gone back to code I made a year or even months ago and barely understand it.

deleted 6y ago
[deleted]

jjice 6y ago

At a previous job, I was the only person to document architecture structure and design choices in a document in each repo I worked on. They turned out to be very helpful for the new employees we took on over my time there. While that's a great plus, the real reason I wrote those was for myself because there is no way in hell I'll remember how to deploy this app to a new EB instance.

trentnix 6y ago
That describes my motivation for writing documentation perfectly. In my last job, I wrote documentation so I could quickly get back into the context of the different problems I was working on. Context switching was a real challenge in that environment and I referred to my own documentation frequently. And sometimes, writing documentation helped me better understand the problem I was working similar to the idea that teaching a topic is a great way to learn.

koonsolo 6y ago

I came here to say the exact same thing, but I want to extend it a bit more. I've seen some developers, including myself, looking at some code and complaining "who the hell wrote this mess!", only to find out in repository history it was themselves. lol.

trentnix 6y ago
...every day of my life!

astrobe_ 6y ago

I somewhat disagree with the way he connects simplicity and cleverness. I once had to explain the behavior of a particular subsystem. It was governed by a bunch of simple rules, but their combination created a complex behavior. This was similar to social insect colonies, where components (eg. ants) are driven by relatively simple rules, but the whole system exhibits remarkable "emergent behavior". What takes cleverness is to anticipate, predict, understand,explain the global complex behavior from the simple rules. If someone can predict what comes out from cellular automatons like in the game of life, I am amazed. Simple is not easy (no, sorry Rich, following your simple advice is not that easy either). Simple is not always easy to understand, even less so easy to do. That's why complexity tends to accumulate. At the risk of being wronged, I would say that being comfortable with complexity is a form laziness. I belong to the messy type of person. I believe I am that way because I can rely on a good long term memory: because of that, I can yield to laziness and not put away things where they belong when I should. Being able to handle complexity is a great quality, but not being discomforted by complexity is like not being ashamed by your messy home. When you make the effort to really simplify, under the favorable circumstances (like in hobby projects, where you can afford to move goalposts a bit), you can make complexity collapse - not by its own weight, for once. I understand that the author emphasis teamwork and communication so he gives this kind of John Wood's "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live" justification for fighting complexity, but preventing complexity from collapsing by its own weight, crushing a product in the process, is to me on equal grounds.

zmmmmm 6y ago
> I would say that being comfortable with complexity is a form laziness I love this, and your comment in general!
Arelius 6y ago
I think an important continuation of this same thought however is that since complex systems can emerge out of simple rules. And since reasoning about the behavior of entire systems (emergent or otherwise) is an essential element of being a programmer. It true that over simplification of the elements and generalization can actually result in a much more complex and difficult to reason about system, just as you point out about the game of life. I guess my point is that sometimes the systems model essential complexity, and by trying to over simplify and generalize elements of that system, you may make the system as a whole more difficult to understand and reason about.

ww520 6y ago

Yes, simplicity is so important. I often adopt the stand of designing and writing software that I could forget. The intent is such that when I come back to the code I've written, it'd better be understood easily. That means keeping things simple, keeping things clear, keeping things consistent, and keeping things well documented. Simplicity helps a lot.

ankurdhama 6y ago

The the idea of simplicity in software engineering is one of those hand wavy stuff that the conventional wisdom is full of. The simplicity (or the complexity) depends on what you want to do (requirements). If the requirements themselves are complex then expecting the code to be simple just doesn't make sense. Also piece of code would look simple to a person who has been working on it for long time and has the background knowledge vs a person who is new to the system. Another thing to remember is that software systems are built incrementally i.e for each new requirement the developer have to figure out "how to implement this new requirement in this given code base with minimal changes" and this eventually will lead to complexity (unless you want to do big refactor on each new requirement).