A very good example of why some very good programmers write very bad applications. I have seen the work of a number of people who dazzle me with their code. I get to see it when the client calls me in to determine why it doesn't solve their business problem.

It is important in our business to be able to talk to computers. But talking (and listening) to humans is an equally important skill. As so many messages here on UT have often demonstrated, the two skills often do not co-exist in the same developer. <s>

>Speaking of architecture. I've recently seen a company that is known in their industry for taking an inordinately longtime to get anything done for clients.
>
>I was talking to a couple Java guys I know. One of them mentioned that a feature that was asked for can't be supplied cause the architecture doesn't allow for it. My comment was that makes the architect incompetent in my eyes. His job, in my eyes, is to understand the system in detail. And create an architecture that will allow for any kind of expansion. The head Java guy disagreed with me. And the other guy basically said what I thought occurred. The architect had very little to no knowledge of the business process. And didn't want any.
>
>
>>>We used to tell the kids when they would tell us how easy it was to copy our functionality, "you don't know what you don't know".
>>
>>I don't feel qualified to weigh in on the esoterica of tool advantages but I'd like to make the observation that in solving business problems with computers the real heavy lifting is in knowing *what* to build more than *how* to build it. A solid knowledge of the underlying business problem trumps pretty much everything else in determining success and is the sine qua non of any real 'solution'. I think anyone converting an app who is only trying to 'copy functionality' - as you correctly assess - doesn't know what they don't know. Slinging code is brick laying, it ain't architecture.