I really like what Joel writes about Architecture Astronauts (thanks for sending, Alex K.!). Sometimes it does feel that way.

"When you go too far up, abstraction-wise, you run out of oxygen. Sometimes smart thinkers just don't know when to stop, and they create these absurd, all-encompassing, high-level pictures of the universe that are all good and fine, but don't actually mean anything at all.
These are the people I call Architecture Astronauts"

I do like to see myself in both sides of this argument though. I really like hearing and reading about architecture, but sometimes it does feel a bit... waste of my time? I mean - I can learn about messaging or the next version of RSS all I want, but what I'd really like to do is build that new application I wanted that can use plugins, or setup my data so that I can use it without thinking about it too much. The thing is, sometimes that architecture thing really is needed. Its needed in those special edge cases where you really wouldn’t be able to do anything without knowing it first.

In his interview, Juval Lowy talked about the value of having a great architect and how, in the right moment, it can save a lot of money and time for the company. Juval implicitly acknowledges the fact that there are Architecture Astronauts out there, that can take the theory and apply it to really complex systems. He admits that there are only a few hundred people architects in the world capable of this (the real Astronauts) and that its wise to just hire one of those instead of making your developers learn it all by themselves because they're not going to do a good enough job at it.

Financially, you could say that Architecture Astronauts are making their own economy. their own little "We know best" economy that, god willing, will stay theirs because no one is smart enough to actually learn this stuff on their own. Think auto-mechanics; You go in, you pay a hell of a lot  of money, and in the end you think you got what you paid for (Alien artifacts).

It feels like pretty grim view. Here we are, all trying to learn all this architecture stuff, but we should just give it all up because someone already knows it all. By the time we learn it, there’ll be much more to learn and we'll always find ourselves with the shortened of the stick.
I think that's wrong. I think that view only applies to less than 2% of the world's software. Very little applications demand this sort of commitment to design and architecture, and less than 2% are actually able to provide such means to achieving this architecture anyway. The rest of the world should still use "good enough" architectures and try to keep up with what's going on. Yes - there will always be absurdly ugly and un-architected systems, but have you stopped and thought about how many of the systems you're using today are absurdly ugly on the inside? Practically all of them. And the world functions. And even sort-of-well. Every once in a while it malfunctions, but mostly we're doing ok.

Yes - we lack the ability to upgrade them, or inter-connect them, or they are hard to maintain or any other of the bad things that ugly applications can do for the average developer/maintainer. Frankly, I don't think that situation will change in 10 or 20 years. In 10 or 20 years, people will still have to build amazingly large and useful applications, using today's technology such as .NET, web services and so on. The same developers who did the job yesterday, will do the job tomorrow. Calculate the fraction of developers who actually sit there and write great, maintainable code and see how amazingly, all those "new" systems will  be hard to maintain, debug and deploy just as much as (if not more) the systems of yesterday written in COBOL. I've certainly seen my share of bad code in the past years (including 2004) which can certainly leads me to believe this. So, taken the following points (facts?)

• Bad coders and builders will forever exist in software. 
• Bad coders usually find their ways into gigantic firms which hire by the volume, not the quality
• Gigantic firms are usually the ones who end up trying to build the world's largest and most dependable software
• Given an amount of developers, and a factory like approach to building, you can build any functional software product, with any level of scalability or dependability, it just may take more time than you though, or you would have to do it several times to get it right
• Gigantic companies have no problem of entering contracts that they *know* they will not be on schedule
• Gigantic companies do have the money to hire great architects
• Gigantic companies may sometimes be too mindless to actually hire a great architect
  

We can most surely tell we're going to end up with

• Software that is well architected (if they hired the great architect)
• Software that is not well architected(if they are mindless)
• Software that is ugly and unmaintainable (you bet!)
• Software that works for its purposes(you bet! it may have takes a few more months/years but they will do it eventually because they are a gigantic company and they have to finish their billion dollar contract. And if they don't some other gigantic company will)
  

So, where are we?

I think that, in spite of my best feelings about great architecture (as those of most of the readers), the *quality* of software will usually be low. Also, most software will *not* have a great architecture, but will just work. And sadly, there will always be ugly and unmaintainable code to maintain/convince the boss to rewrite.

How do we change this? There are two levels to this issue. The first one is *quality* and on that front we're doing better, but we still aren’t even 5% of the way there. Agile methodologies, test driven development, XP, Scrum; all those are great ways to start re-thinking and implementing the quality we would *like* to see in our software. The second issue is architecture. Yes, the world makes us go more and more in the way of distributed systems. That on its own is a great motivator to start thinking about architecture. But its not enough. Good architecture requires good architects. The question becomes two other questions: Will we need more good architects? and how do we create new ones?

Will we need more architects?
Well,  we'll certainly need more people with more knowledge about architecture and building systems correctly, but that doesn't mean we may need more architects in the sense explained thus far. Most applications will do just fine with a little more knowledge about architecture, design patterns, OO and such. Having Juval Lowy visit every 3 man months project in the universe would lead to one sure thing - a complete halt of the world's software development efforts. It would simply take to much time to build software, even the simplest one, and it won't work. Ad-hoc software will always exist and even in its ugliest, most nasty throw-away form, it will continue to be valuable.

How will we create new architects?
There will be more applications that need "real" architects, but not in a life-altering, industry altering way. We will need to find a better way to educate developers about architecture and design. Today's methods just don't do justice to what we really need. It still won't mean no ugly code, but it will ease the pain a little and enable the next generation of software, that uses the new paradigm of distributed architecture, to walk through the door and start making the world a better place in their own little way. Things like an architect's workshop are a good starting point, but we'll have to find less costly ways to train our developers to learn the most important things. The amount of articles in magazines and on the web regarding these issues is rising, and its only a matter of time before someone finds a way to pre-chew this stuff so it can be easily taught to developers in a way that costs less time and money but brings the same results.