These are good things to keep in mind, but there is still a line to walk here. Under-engineering is possible as well, which might be defined as putting something together quickly that only handles the happy path, no tests, difficult to read/understand/maintain, etc. I would say, write solid code that you’re happy to live with for the medium term, but that doesn’t introduce indirection that isn’t needed for current requirements.
It's subjective for sure. The way I think about it is: does this solution introduce requirements into the scope? In an optimal scenario, you shouldn't be able to remove a piece from the system and the system continue to work as desired. There are some holes in that statement too, so perhaps an additional thought is: does the system perform up to its expected measurement? For example, Honda engines are not intended to be built for the user to operate at high speeds, rather the intention is reliability. Overengineering in this case is attempting to create a Honda engine that both operates at high speeds and is reliable.
This article and therefore my comment got me the idea of writing about it.
It's not explicit, but the idea of depending on the context is in the "we" on "Solving problems we don't have".
In your example, Honda doesn't want to support high reliability at high speeds; therefore, solving that problem falls into "Unsolicited Features" in my article.
Good lesson for folks who spend too much time editing and don't publish soon enough: don't let "perfect" be the enemy of "awesome."
Title should be changed to "Don't be bad at engineering". Engineering *is* simplicity.
These are good things to keep in mind, but there is still a line to walk here. Under-engineering is possible as well, which might be defined as putting something together quickly that only handles the happy path, no tests, difficult to read/understand/maintain, etc. I would say, write solid code that you’re happy to live with for the medium term, but that doesn’t introduce indirection that isn’t needed for current requirements.
I was going to say something similar. How do you identify overengineering?
What is and what is not overengineering?
It's subjective for sure. The way I think about it is: does this solution introduce requirements into the scope? In an optimal scenario, you shouldn't be able to remove a piece from the system and the system continue to work as desired. There are some holes in that statement too, so perhaps an additional thought is: does the system perform up to its expected measurement? For example, Honda engines are not intended to be built for the user to operate at high speeds, rather the intention is reliability. Overengineering in this case is attempting to create a Honda engine that both operates at high speeds and is reliable.
Would love to hear what you think.
That is an excellent point. What is considered overengineering in one project, it doesn't need to be overengineering in another one.
I actually wrote a piece on how to identify overengineering: https://frontendengineering.substack.com/p/signs-of-overengineering
This article and therefore my comment got me the idea of writing about it.
It's not explicit, but the idea of depending on the context is in the "we" on "Solving problems we don't have".
In your example, Honda doesn't want to support high reliability at high speeds; therefore, solving that problem falls into "Unsolicited Features" in my article.
I'd love to hear what you think of the article!