If arhitecture is made by brand new rookie straight from university, then I bet architecture is more harmful for developement that useful. If architecture is made by some geek, who have weird fetish to some specific technology and wants to use it, it is likely that it project is going to be disaster. If architect really can't communicate with customers or understand problem space - then it is guranteed to be disaster.
If arhitect have enough experience, knows her limits, remembers that arhitecture is going to change when development progress, leaves enough work space for developers and understand problem space - then it just might be useful. If software team is going to have more than 3 persons, then architecture is needed - even bad architecture might be then better than no architecture at all (assuming that team have champion who smells fast enough bad architecture and have big enough balls to force architecture refactoring).
Personally I prefere prototyping, partial designing and refactoring. Identify components, design most critical component: try different approaches, test their performance, identify limitiations, implement most critical component - and then build other components around it. Design for refactoring, separate components by interfaces and allow only minimal coupling.
This is the internet, where the men are men, the women are men and kids are the FBI.
Think, in the definition of the survey omitted the word "formal".
Without it the question has a little sense for the human beings.
Their main difference from, say, monkeys is exactly this: planing somehow or other every their step.
My English is permanently under construction. Be patient !!
You, we, must decide what is trivial however. If stove pipe, same program that you wrote yesterday, then no. If distrubuted, complex, new, then yes. It seems obvious....Depending upon how many fine projects one has seen fail, I suppose.
OK, I am really ranting here a little: software needs to be designed. However, by the time the word "architecture" kicks in, it is most probably over-designed, and developers will spend most of their time fighting the architecture instead of solving real-life problems for the users.
I agree somewhat, however I have noticed that the use of the word "architecture" in practice often indicates overengineered code. I have seen examples of simple and effective design, but no-one used the word "architecture" there.
I think that may be more indicative of a problem with the developers (lack of maturity and/or focus) vs. the architecture.
Sorry, but if as a developer, I spend most of my time trying to figure out what the heck the "architecture" is trying to accomplish and how to add a simple feature that a customer wants, I say the problem is with architecture, not with developers. If I need to edit various (often undocumented) XML files and (in case of .NET) insert attributes to add a simple control to a dialog, I say the problem is with the architecture. If I need to spend hours trying to figure out how to open a simple file, I say the problem is with the architecture, not developers.
I've seen that problem in at least three companies I worked at - all of them filled with smart people and relatively well organized.
You're right. I misread "fighting the architecture" as "fighting about the architecture". If the architecture forces you to go through hoops to implement something straightforward, that indeed smells like a poor architecture.