Interesting question. With the years I think more and more that this principle is paramount. I knew it was important, like one of many principles to keep in mind but it has kept climbing my priorities lader to reach the top.
My take on how to implement simplicity is the usage of design patterns (when relevant of course) and good practices. They give a common language to all developers. Whatever the complexity of the code I'm reading, some key words used correctly help me understand fast.
It can be somewhat of a paradoxe since a lot patterns are not simple in themselves. But a pattern I've read hundred of times will always be easier than a simpler specific-made solution I'm reading for the first time.
Of course I'm not saying that bending the patterns to match a specific problem is a good idea, it's just a general concern to keep in mind. When you're solving a general problem don't reinvent the wheel.
Another good way is to communicate with the team. Speak about your ideas and see how well they are received by your peers. Stay open minded to alternatives.
The things that make me produce over-complicated code are mostly overthinking and financial/time reality.
I tend to write useless and over-complicated code when I allow myself to consider what could happen on a scale that I dont have a control on. I can anticipate some things, and I should, but some others are just in the universe of possibilities and I should just ignore them. To me that's the difference between anticipating and overthinking. One good example of that is "what will happen if they change from SQL Server to MySQL". Is it a known requirement || Are there concret ongoing talks ? No ? Then it's probably not something that should be considered unless it comes at no cost. In that regard YAGNI helps to KISS.
The other reason comes from just not having time because of budget restrictions or short deadlines. In these conditions I tend to come with the most immediate solution which is alsmot never the best, the easiest or the simplest one. I don't have a solution for that as a developer except communicating with the project manager and try to find the best compromise.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Interesting question. With the years I think more and more that this principle is paramount. I knew it was important, like one of many principles to keep in mind but it has kept climbing my priorities lader to reach the top.
My take on how to implement simplicity is the usage of design patterns (when relevant of course) and good practices. They give a common language to all developers. Whatever the complexity of the code I'm reading, some key words used correctly help me understand fast.
It can be somewhat of a paradoxe since a lot patterns are not simple in themselves. But a pattern I've read hundred of times will always be easier than a simpler specific-made solution I'm reading for the first time.
Of course I'm not saying that bending the patterns to match a specific problem is a good idea, it's just a general concern to keep in mind. When you're solving a general problem don't reinvent the wheel.
Another good way is to communicate with the team. Speak about your ideas and see how well they are received by your peers. Stay open minded to alternatives.
The things that make me produce over-complicated code are mostly overthinking and financial/time reality.
I tend to write useless and over-complicated code when I allow myself to consider what could happen on a scale that I dont have a control on. I can anticipate some things, and I should, but some others are just in the universe of possibilities and I should just ignore them. To me that's the difference between anticipating and overthinking. One good example of that is "what will happen if they change from SQL Server to MySQL". Is it a known requirement || Are there concret ongoing talks ? No ? Then it's probably not something that should be considered unless it comes at no cost. In that regard YAGNI helps to KISS.
The other reason comes from just not having time because of budget restrictions or short deadlines. In these conditions I tend to come with the most immediate solution which is alsmot never the best, the easiest or the simplest one. I don't have a solution for that as a developer except communicating with the project manager and try to find the best compromise.