Was just about to put that link.
On a personal note, I find it very true. However, I find that while not influencing happiness on the long run, salary does determine the acceptability of a position (good people tend not to gravitate to lower-than-average paying jobs). Once you're "hooked", it becomes more about A-M-P then salary and bonuses (not that those hurt :) ).
The article (the one inside) simply says that one size doesn't fit all.
Agile (or, as I like to call it, short and iterative waterfall with priority management and pipeline solution), fits some scenarios well, but not others.
It fits startups because it's quick to release. It fits non-scientific products (or non-algorithm heavy products) as features can usually be contained in a single sprint or easily broken into deliverables. It fits huge products on maintenance mode when most of the development are customer features and issues.
However, it doesn't fit algorithm-heavy products (algorithms are usually "one-go" and require a sustained effort), it doesn't fit big products during intense development (architecture can't be ignored or it'll crumble under the product weight), it doesn't _always_ fit corporate environment (because of "impedance mismatch").
[very personal opinion, flame-shield on]
It fits average developers since it maximize oversight, reduce the time an error has to propagate and forces the work to be split into manageable, chewable parts.
It doesn't fit great developers ("distinguished", "level 4", "star"...) because, just like any other artificial framework, it hinders creativity and the free flow of code. On the other hand, a great developer is also measured by his/her ability to ship - which negates the need for such artificial systems.
Long term isn't the only kind that exists. Short and mid terms are fine as well, as long as you find a way to monetize fast and early. Just be aware that the party may be over at any moment and, when it is, exit gracefully and before the crowd starts yelling for the already absent DJ to play just one more song. Use that time to find a different party to join to, one that's just starting.
A software architect job is about interfaces between modules. An architect job is to design interfaces that are aligned with the product direction and technical capabilities (both of the product and the people developing it) and tell a consistent story, both syntactically as well as semantically.
Without such a person, each pair of developers, no matter how good an engineers they are, will have to develop their own language that is bound not to match those that are developed around it. This adds to the burden of each developer as he (or she) has to use APIs developed by different such teams. Consistency is key.
Because the architect has to see the big picture to do his job, it makes sense that he's also the look-ahead guy. Because he defines interfaces and modules, it makes sense that he gets to evaluate new technologies - so playing with rabbitMQ really is part of the job description.
This kind of job tend to require a working knowledge of the product internal, otherwise APIs can get completely incompatible with capabilities. As such, it attracts good developers that also think "strategically". Because many architect still love the code, you usually see such a person wearing two hats - the classic architect one but also the "lead developer" one - so code reviews, cleanup work and super important (but small) modules tend to be part the architect work, even if not in the job description.
Lastly, the architect must have soft skills. The job requires a lot of human interaction, considerably more than a developer job does. It also requires a much closer interaction with "management", the architect understands the aforementioned big picture.
Is the architect "better" than any developer? No. It's a complimentary role. Is this role always needed? No, but as a project gets bigger and start having more modules, interfaces tend to get hairy without a guiding hand. So why do architects make more? Supply and demand. Not everyone has the ability or the will to think "big picture" all the time. It's tiring, it's complex and you tend to think about balances (how will this affect the future? How much risk? How many man-hours? What's the alternative? How to phase development?) instead of "code purity".
Disclaimer: I'm an architect but I also do a lot of "lead developer" parts. And while the definition tends to get fuzzy around the edges (and some interfaces are made ad-hoc, without that guiding hand), I see the best results when I follow the above recipe (which, sadly, means a lot less coding than I actually like to do).
TL;DR: architecture is about interfaces between modules, not content of each module. Usually architects also wear "lead dev" hat because they like it.
