There is a colleague of mine who starts proposing solution as soon as a problem is described to him. This is a natural phenomenon not only for him but also for many others and ‘others’ includes 2 types of people.
- Who knows deep about the architecture; have knowledge of all the flows and algorithm used and can give great insight by putting their suggestions.
- Who starts thinking about the solution as soon as problem is stated and not try to find the actual cause first.
This man belongs to second category and start thinking about the solution without completely understanding the problem, investigating about the root cause, thinking about side-effects of proposed solution (hack in most cases) and thinking of a better way to solve it actually.
The goal of this post is not to bash a person but the process of solving the issue at hand. One, who belongs to the second category above should first think about the actual problem and then start thinking of solving it. A good developer is the one, who doesn’t write more code but the one who writes code to address actual problem.
Debugging is a process, which require a deep digging in to the material you have, finding the root cause and then start thinking about its solution. We can see the actual behavior as shown in following chart.
But actually, these people start thinking to fix the bug ASAP and expand the VIOLET pie to the GREEN rectangle as the goal. Which is the worst thing we can do and can devastate the system. Due to this:
- Hacks come into the picture; rework is being done again and again
- People need to clean up their code; less productivity
- Understanding doesn’t develop
- Every time a problem happens you need to start all over again
In short we can say that one can never convert from category 2 to 1 (as described in the beginning). If you want to lie in the first category, follow above pie chart step by step. If you are not following percentages (approximately) as given, you are not doing in right.
Basically debugging the problem in ‘Problem Space’ is as necessary as fixing the problem in ‘Solution Space’.
PS: I found a very nice example of the side effects of this behavior here.
I believe one should not ignore the importance of a 'quick-n-dirty' solution (not necessarily a hack). Often (and this becomes more often than not in case the project is big and complex), acquiring deep knowledge about the architecture and all the flows and algorithms takes time. If I am to consider only the two classifications you alluded to, a person who's not very new to a team can't be trusted to "solve a problem"; which is not a very good opinion to have for someone who's spent quite some time (but definitely not enough to understand everything, so to speak) on a certain project. True, there are pit-falls with quick-n-dirty solutions; but that's exactly why you regress. I'm not downplaying the importance of understanding by debugging here, all I'm trying to say is that its probably wrong to expect to learn aplenty in the amount of time you typically have to respond to CSRs, and that quick-n-dirty solutions are not as bad as sound, especially when they do work!
As for the link you shared, it sure was amusing, but IMHO, it was over-confidence that killed the cat. A minor code review and regression would have caught the issue much earlier. Of course you can say that Stefan was unwilling to have any, but isn't that why mentors are there in first place? I'd totally agree with a commenter who said "I think this problem has [sic] at-least two nuts"
@Actinium: I do agree with you but as you said "especially when they do work!"
Also there are times when you need to put an instant solution or hack and that is justified. But making that a habit is not a good idea.
@akash: rightly said! looking for a quick solution isn't wrong...what's wrong is to have undue confidence on it.
same issue, but in a different context...
Why the Best Solutions Are Always Temporary Ones