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.