3 ms·

> "When I review code from more junior developers or even tenured developers, I find a tendency to either overengineer or overcomplicate solutions" The article

> "When I review code from more junior developers or even tenured developers, I find a tendency to either overengineer or overcomplicate solutions" The article then launches into recommendations about requirements gathering and writing down your thoughts (functional specs anyone?) which kind-of sounds a little bit like the waterfall method to me. I believe the waterfall method has a bad reputation for overengineered and overcomplicated solutions. We have come full circle, again! No matter the methodology there seems to be this behavior in the industry that as soon as some code does the job, regardless of how terrible it is, it must not be touched again and we must move on. Whether it was over-engineered because of bloated requirements gathering or because it was hacked into some sprint period the end result is the same. My recommendation is this: Don't discourage people from refactoring code that already works. Good code will survive refactoring or even rewrites.

brunokiafuka 2y ago
I agree with your point that code should be refactored. The main idea of the article is to encourage developers to take some time to think before writing code. Even if you have the functional specifications for a feature, you might not have a clear idea of how to implement it. Taking some time to think and plan your approach can not only improve your initial implementation, but also simplify the process of refactoring later on.
RaftPeople 2y ago
> The article then launches into recommendations about requirements gathering and writing down your thoughts (functional specs anyone?) which kind-of sounds a little bit like the waterfall method to me. I believe the waterfall method has a bad reputation for overengineered and overcomplicated solutions. We have come full circle, again! That's not really waterfall, it's just normal analysis and design. The trick is to identify when you have enough domain knowledge that the analysis and design time is valuable/optimal, or to identify that you don't have enough domain knowledge and need to iterate to gain the knowledge.

brunokiafuka 2y ago

I agree with your point that code should be refactored. The main idea of the article is to encourage developers to take some time to think before writing code. Even if you have the functional specifications for a feature, you might not have a clear idea of how to implement it. Taking some time to think and plan your approach can not only improve your initial implementation, but also simplify the process of refactoring later on.

RaftPeople 2y ago

> The article then launches into recommendations about requirements gathering and writing down your thoughts (functional specs anyone?) which kind-of sounds a little bit like the waterfall method to me. I believe the waterfall method has a bad reputation for overengineered and overcomplicated solutions. We have come full circle, again! That's not really waterfall, it's just normal analysis and design. The trick is to identify when you have enough domain knowledge that the analysis and design time is valuable/optimal, or to identify that you don't have enough domain knowledge and need to iterate to gain the knowledge.