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.