Approaching change requests

Lately I have been involved in lot of change requests related to ABAP programs. Such Change requests are usually considered to be very small and hence are expected to be delivered very fast irrespective of complexity involved in the change. I have observed few ways in which developers handle such changes. Lets take an example of changing contents which are getting fetched from a report, one of the safest approach would be to loop again at the final internal table and modify the contents just before sending it for display, is that the good approach? I am not sure if such techniques are result of tight timelines or developer not being interested in finding out what was the original development or the intention is just to get the work done. There could be many other possibilities. But I think both the functional consultant and the developer have great roles to play in handling change requests. There are many occasions where a change request is not properly represented in the functional specification. Let's take a scenario wherein the developer handling the CR is different from the original developer. In this situation it is always good that the new developer gets to know the background of the program and then handle this change. FS author has an important role to play here, until the developer decides to manage everything on his own. The new change should be properly represented with references wherever possible.

I usually don't rush while handling change requests unless I am forced to, depending on the criticality of schedules. Recently, I handled a very tricky change request. I remember I took 4 days of analysis and just one day for coding as I could easily figure out the perfect spot for change after understanding the design of program. I never tried to rush with the program and I am very happy as it has gone through the testing without any defects.
Another scenario crossed by my mind, what if both the functional consultant and developer changes while handling a change request? These scenarios explains the importance of documenting developments as accurately as possible. It's altogether a different story that once development is done, one hardly bothers about documentation, in most of the cases.
These change requests also highlight that the original program is built in a very flexible and maintainable way. I have more than often realized the importance that the basic and original programs should be built in a robust way else with time it will only become worse.