>>[snip... parsnip]
>>>>Using the wrong tool can create problems. There are times when I need to use C/C++ and times when I need VFP.
>>>>
>>>>Not employing sound design principles can make things terribly difficult. Using bad methodology can likewise make things harder.
>>>>
>>>>Doing or failing to do proper testing to assure the accurancy of the results.
>>>>
>>>>There may be more. These are just the ones that come to mind off the top of my head.
>>>
>>>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?
>>
>>In a way, this may be the division between applying the business logic vs all other problems. It's hard to draw the line between these two, because usually we try to apply the business rules using the technology available, and the technology is giving us hard time.
>>
>>Take one trivial thing: adding images to reports. Sounds like a technical issue, and it surely was in FPD days. But when a customer wants their invoices to print with a logo on top, it's a business issue.
>>
>>However, there's a bunch of things which are purely technical, some of them entirely in the field of GUI fashion of the day. Off head top: problems with screen savers, virus checkers, OS issues, video and printer drivers, caching, disk sizes, memory requirements, backends...
>>
>>I wish I had at least once taken the time to split those into business vs technical, and totalled the time. I wonder what the result would have been.
>
>I think the correct answer would be "scary".
>
>Then, of course, there's the "party" trick. Imagine you're at a party and you've just met someone who is not a computer person. Explain to them what you've been doing the last day/week/month/whatever.

Al;

A true computer person will not attend parties! :)

Tom