>Al,
>
>>I think most would agree with all of this. About your first point, "solving problems", how much of our time these days is spent addressing business problems, versus "solving problems" related to/caused by/inherent to the complexity of the technology involved?
>
>Naturally, I can't speak for anyone but myself. I spend most of my time solving problems that involve the "business issues".
>
>As for the technology end, one thing I try to do when confronted with something I'm unfamilar with is to write code (objects) that I can use later in some way. For example, I once had to design an object that could interact with both Lotus 1-2-3 and Excel depending on what the user had installed. What I did was first determine what had to be done regardless of the server. Next, I identified specific utility that I needed to do with both. From here, I was able to both write the code and create the interface. Note that the syntax required for the actions to be done by the spreadsheets was still unknown to me at the time. I had, however, been able to create the interface for inter-acting with them. I then created a class defining the interface and two sub-classes of it, and then proceeded to get down to the "nuts and bolts" of make each behave as desired.
>
>Since then I've been able to re-use these classes, even though I don't have a clue as to what's going on in them since the interface tells me (by the method names) how the object should react.
>
>Is this what you were driving at?

Well, it's certainly an elegant approach to the problem, from a technical standpoint. But I can't help noticing, nowhere do you say anything about what you were actually doing with the spreadsheets i.e. what your users were concerned about.