3 ms·

You aren't alone in this, I think it is a relatively common problem. In general, experience is what makes this better. Knowing when to take another path is us

You aren't alone in this, I think it is a relatively common problem. In general, experience is what makes this better. Knowing when to take another path is usually when you see that the problem is over complicated as is. Take a look at the overall goal of the solution, then break it down into stages, steps or simple issues within the larger context. That will usually help you prevent being taken hostage by the problem. Also, sometimes issues are just complicated. I recently worked on debugging an image processing algorithm I implemented for a client. I spent 4 days following one path just to figure out it wasn't the right path at all. In that case the hostage feeling came from the fact it was highly parallel and extremely complex and it just took a lot of time. Even with breaking the steps down to the simplest denominator.

letmeaskthis 11y ago
In that case, I guess the problem is, how do you see that a solution is overcomplicated as quickly as possible to recorrect and use another approach.
- davismwfl 11y ago
  Overcomplicated to me is when I see one method/function etc trying to do too much work. For me that generally means a method/function over 1 screen or 100 lines of code (some exclusions for a switch statement or if/else) is generally trying to do too much. In my experience when you see large methods/functions generally it means the problem wasn't well understood when it was implemented so the coder/designer didn't know how to break it up. I also think many people may hack out a larger method at first to get the concept right then start refactoring, I know I have done this at times. As long as it gets refactored that is all good. Also, when you see an architecture that just doesn't fit the solution. For example, someone is building a distributed system to serve 20 users in a web application. That just doesn't usually make sense and is likely over complicated and is time to rethink. There are always the rare examples where it is necessary but I'd go with the 98% of the time when it isn't. Do you have an example of a problem that troubled you that may help others provide ideas for you?

letmeaskthis 11y ago

In that case, I guess the problem is, how do you see that a solution is overcomplicated as quickly as possible to recorrect and use another approach.

davismwfl 11y ago
Overcomplicated to me is when I see one method/function etc trying to do too much work. For me that generally means a method/function over 1 screen or 100 lines of code (some exclusions for a switch statement or if/else) is generally trying to do too much. In my experience when you see large methods/functions generally it means the problem wasn't well understood when it was implemented so the coder/designer didn't know how to break it up. I also think many people may hack out a larger method at first to get the concept right then start refactoring, I know I have done this at times. As long as it gets refactored that is all good. Also, when you see an architecture that just doesn't fit the solution. For example, someone is building a distributed system to serve 20 users in a web application. That just doesn't usually make sense and is likely over complicated and is time to rethink. There are always the rare examples where it is necessary but I'd go with the 98% of the time when it isn't. Do you have an example of a problem that troubled you that may help others provide ideas for you?