
Why I don't believe in software architects - smikhanov
http://www.mikhanov.com/2010/01/26/why-i-dont-believe-in-software-architects-120
======
modoc
As a software architect for the last ~10 years I have to disagree. His point
seems to be that if you get a job as a software architect you'll end doing
nothing but meetings and creating UML diagrams. I'm sure there are places like
that, I've worked at one (Rational Process - shudder), but there are many
places where they need someone who can provide architect level application
design, who can see the forest through the trees, who can balance the needs of
the business, the 3rd party integrations, and the technology. My current
contract role has me providing architecture (usually just a 1-2 page design
doc, not often UML), mentorship, and coding some of the trickier stuff.

I still code a lot, but I also have responsibility over the whole software
ecosystem and hence some power to decide how things go. I mentor developers,
perform code reviews, and work on process improvement too. It's a great role.

~~~
hello_moto
There should be more people like you.

The biggest problem in our industry is that there isn't enough mentors to tell
the young people that they were wrong all this time.

~~~
modoc
:) I think the biggest problem in the industry is that many of the "young
people" (I'm still young, dammit!) don't really want to learn or be mentored.
Seems like there's a slew of folks in the junior to mid-level developer arena
who got into CS because it was going to make them a lot of money, not because
they love to code. I love it when I'm working with people who love to tinker
with new libraries and APIs, who are working on something neat in their spare
time, etc... They make much better developers than folks with a CS degree who
do what's assigned to them from 9-5 and that's it. I'm not saying you have to
work a ton, but just be interested in the whole tech universe:)

~~~
jerf
I blame the myth that young hackers are somehow strangely more knowledgeable
than their elders because of the putatively ever-changing nature of
technology. I've always been suspicious of this self-serving narrative (in
what other engineering field is this true?), but as I approach what passes for
Old Fartness in this industry (30) now I _know_ it's bullshit.

All the twenty-year-old whizzes I know are experts at taking something like
Ruby on Rails, trading in the quality of the underlying framework to put
together a hack-job very quickly, and then promptly getting themselves stuck
in a morass that they can't get out of because they don't even understand why
they are in a morass. Hand these people something with a lot of technical
assets they can borrow against and yeah, they can toss something together
fast, but that's hardly "better" then what I can do now, which is actually
_produce_ technical value.

(Mind you, I'm not saying that's necessarily a bad thing. There's a time and a
place for that. What _is_ a bad thing is that the developer won't understand
the tradeoffs they just made, and probably didn't make the tradeoff after a
sober and careful balancing of the costs and benefits, but did it because it's
all they know.)

Anyhow, my point is that thanks to that mythology, a lot of younger people
don't think they _can_ be mentored by the old farts they think know nothing in
this rapidly changing technical environments. The old farts (at least the ones
who have ten years of experience and not one year of experience ten times)
have learned that frankly, the tech world _isn't_ changing that fast
(different languages, different APIs, pretty much the same messes). There's
plenty of mentoring to be done, but you gotta accept that the mentors are
going to tell you some things that may shattered your treasured conceptions of
the programming world....

~~~
alexgartrell
Though I agree that there's a lot of value in what more experienced people
have to say and that people my age should seek out knowledge from you, there
are a couple things that are also important to remember.

Many of us "20-year-old whizzes" don't do what you describe at all. In fact,
as a Systems programmer, it's not incredibly likely that you know 'better than
me' what the implications of what you're doing are at an Operating System
level. I know 20-year-olds who have contributed source to Linux, Chrome,
Firefox, and a number of other Open Source projects. Folks who have worked in
industry for 2-4 summers in a row already. 20-year-olds who have gone to
Silicon Valley and done the startup thing. (I can go on with this BS forever)

But all that 20-year-old ego stuff aside, it's also important to remember that
this is a field that is routinely _dominated_ by disruptive thoughts, ideas,
and personalities. All of your experience becomes a hindrance when you start
to follow your old steps to the "right solution" every time. For that reason,
it's also important that you look to the "20-something whizzes" for insights
and ideas that may surprise you and that you actually consider what they say.

~~~
Silhouette
Ah, the Dunning-Kruger effect at its finest. :-)

Please ask yourself this: even if you do know 20-year-olds who have done
impressive things, why would you think that such talented and/or hard-working
people will not be able to achieve still more impressive things at 30, when
they have roughly an order of magnitude more useful experience? What about at
40, when they have had time to see through several long-term projects?

Or look at it the other way around: do you really think none of the successful
older developers today also contributed to volunteer projects during school,
worked summer jobs, or tried a start-up straight out of college?

It is true that disruption of routine is sometimes important for the industry
to make progress, but it says a lot that you chose the word "dominated". Our
industry isn't "dominated" by disruption at all. On the contrary, it is
dominated by people who make useful products, using untrendy but tried-and-
tested tools and techniques, that get real work done.

Every now and then, something truly original or a genuinely creative
application of an old idea comes along, and that can become a great success.
But for every one of those, there are a lot of ideas that stink and go
nowhere. And guess what? Many of those ideas come from the young people who
are convinced they're on a winner, because they are too inexperienced to know
better, where more experienced developers might have seen similar ideas fail
before and know an idea was doomed before wasting any time on it. Conversely,
despite your rather odd assertion that broader experience somehow implies
being set in one's ways, IME those who have been around for a while are much
better at spotting opportunities to fill useful niches or change the rules in
a significant way, and are much better at making practical, pragmatic
decisions to take advantage of those opportunities.

YMMV, but I'd bet a substantial chunk of money that in ten years' time, you'll
be on my side of the argument. :-)

~~~
nickpleis
I certainly am.

I was a fairly quick riser in my career. I started programming at 12, had a
commercial game (value-ware CD) published at 17. Wrote a book at 21. I was a
lead architect at 24, with a development team of around 30 folks at a fairly
successful company. I was quite sure that I knew it all at that point.

I didn't. I just turned 30 and only 6 years later my level of knowledge and
experience is far superior to what it was then. Not just in terms of pure
programming knowledge, but also in terms of decision making. I've become far
more practical and much more adept at translating requirements into something
people can actually _use_.

30 year old me and 24 year old me wouldn't see eye-to-eye on a lot of things.
After leaving that job I've become an entrepreneur. The sum of that experience
makes me far more productive and the quality of what I make is simply better.

24 year old me could a learn a thing or two from 30 year old me. Just as I
hope 30 year old me will need a good talking to by 40 year old me:)

------
coffeemug
_I don’t want to become a pointy-haired boss therefore I’m not going for
management; I don’t want to have anything in common with suits and meetings
and investors and therefore would not go for entrepreneurship_

After some years of this mindset I finally realized that the proportion of
excellent people to mediocre ones is roughly the same in every profession. I
no longer draw the lines between "hackers" and "suits" (a kindergarden
attitude, really), but between excellent people and mediocre people. It's
liberating. You can go into any profession with this mindset and it will be
your own personal playground.

------
hga
One detail from the _Antipatterns_ book:

They claim that only about 1 out of 5 programmers "get" abstraction. To the
extent this is true (and it agrees with my experience in the field starting in
1977 including a dozen years in and around MIT) you can't have "democratic"
design processes, for the "software architects" who _do_ get abstraction will
be voted down and you'll end up with the usual mess of spaghetti (or whatever
they're calling it nowadays).

Hmmm ... another problem I ran into was understanding scaling, O(whatever)
issues. At least one project I declined to join died horribly because the
people in it couldn't grok that their design wouldn't scale to the level
needed for basic customers, let alone big ones (in this case the lead had only
done CD-ROM based applications, so his library code for the DB didn't even
work when they tested 2 clients, but the bottom line was equivalent to trying
to use e.g. the biggest baddest version of Oracle to implement a Google scale
internet search engine).

------
Silhouette
It seems to me that the biggest problem is not software architecture _per se_
, it's when you have a software architect who thinks they are automatically
senior to other members of the team. Software architects are (or at least,
IMHO, should be) co-ordinators, not directors/dictators.

Of course architects need to be technically strong, because they need to be
working with the team leads responsible for each part of the software project.
That means they need to be able to communicate effectively with those leads
and understand the technical implications of what is being said.

But it's a two-way street, and both the team leads and the architects have
their own role to play. The team lead needs to be more aware of the finer
details going on in their area of the project. The architect doesn't need to
know those things, but does need to be aware of how everything fits together.
That includes knowing enough about what each individual team is doing to
identify areas where something new would be useful, or where multiple teams
are doing the same thing and there is redundancy that could be eliminated.

Ultimately, it's all about collaboration. A software architect who only draws
diagrams and produces hundred-page design documents probably isn't very
useful. A software architect who talks to business leaders to clarify the
requirements, liaises between the various development teams to make sure that
they collectively meet those requirements, keeps an eye on testing and on bug
reports coming in from the field, and so on, is pretty much essential to
building large software systems successfully IME.

(Edit: I realise that my final description there was rather broad, and has
some overlap with management responsibilities. Realistically, I think a
software architect is going to have an element of that as part of their role,
just as team leads do within their particular areas. But both are primarily
technical roles.)

~~~
j_baker
Agree. Nothing is worse than an architect who's a closet manager.

~~~
joezydeco
I'll tell you what's worse: an architect that has no experience in your
product field.

I'm currently in an embedded systems company where the chief architect came
from a server-design group. So now everything we do looks like a server. It's
awful on multiple levels.

------
delano
Programmers often neglect the fact that not all problems need to be solved
with more code. More specifically, there are problems that are better solved
at the architecture level. For example, rather than queue jobs in a wonky
static variable, use RabbitMQ or Redis. And instead of implementing search
functionality through Hibernate, consider a separate stack which you can grow
independently of your core application. While you're at it, consider using
Solr instead.

I'm not justifying the term software architect (I don't like it for other
reasons), I'm simply suggesting that if your infrastructure consists of a
single, monolithic application, you need to consider solving some of those
problems outside of your code.

~~~
smikhanov
_I'm not justifying the term software architect (I don't like it for other
reasons)_

What are your reasons, BTW?

~~~
japherwocky
As someone who went through Real Architecture school, I find most software
architects don't deserve the title.

Architecture school is very hard, mentally and physically. The perk is the
weird mystique that society gives us.

~~~
jacabado
As opposed to engineering school? Do you think the problems _real_ software
architects are ought solve are inferior to those whose _real_ architects solve
(if they really do it any better than the software ones)?

If you answer no to the last one you should read the Chaos Report.

~~~
japherwocky
In technical terms, the problems in software are just as difficult as in
buildings, but you don't have to deal with inspectors and building codes and
aesthetics.

(Which is a big part of the reason I choose to work as a coder ;)

I am saying that a top notch architecture school is much more demanding than
an equivalent engineering school, from my experience. I say that having lived
with ME and CS roommates, at U of Michigan, while I was in school.

~~~
jacabado
Oh yes you have. Basel regulations are one of the top drivers of architecture
initiatives in the finance industry.

Talking about aesthetics, Information Architecture, from the data model to
business objects model (or what the users call the fields in an user
interface), even the the names you give to the applications are a big
aesthetic exercise.

An aesthetic exercise where you your audience is the business side, and you
need to appeal to their comprehension.

------
blasdel
I have only found one Software Architect truly worthy of the title: Roy
Fielding (<http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm>)

If you're doing anything _Prescriptive_ , you're really doing design, for
better or worse. Software Architecture is properly _Descriptive_ \-- it's an
explanation of how a system works, and how to make your work fit its
structure. It's not something you should ever be doing up front.

The GoF had a good idea to describe software in Alexanderian patterns, but
they didn't really understand why and for whom his pattern system was
designed, and then they fucked up the implementation in the extreme.

------
drtse4
Fancy job titles and funny job descriptions aside, i always thought that the
ability to perform critical architecture related decisions is something that
_every_ developer should some day achieve, making this "software architect" as
a natural step of the evolution of every developer. And regarding UML, having
seen it misused and misunderstood a lot of times, it's just a tool, the same
ideas can be expressed with other means, what counts is that the content is
clearly explained and correctly understood.

~~~
smikhanov
As I'm saying in the neighbour thread, this was the reason why I wrote this
post in the first place. Something like "hackers, don't be lured by fancy
architect job, just master your own craft, this is more valuable".

------
gaius
Good systems architecture is crucially important - which is why it should only
be done by people who know they can get called at 3AM when it all goes
hatstand.

Not the sorts who wave their hands and draw nonsense diagrams on a whiteboard
and chuck something that _cannot work, ever_ over the fence to the
implementation team and blame their skills when the project fails.

------
arethuza
I tend to believe that the job of an architect is not to make the important
decisions but to make sure the important decisions get made correctly and to
take responsibility for that process and its results.

~~~
smikhanov
This blurs into my vision of top-notch software engineer without the fancy
title, which was the reason I wrote that post in the first place.

~~~
arethuza
In my experience the title is really there to identify who will get shot if
the damned thing doesn't work for fundamental technical reasons.

~~~
Luyt
The developers, who failed to glue the mandated technology together, probably
will be blamed ;-)

------
j_baker
I think that we need to consider the scale of the organization you're going to
work for. Are you going to find a "software architect" in a five-person
startup? If you do, you should run far, far away.

On the other hand, a larger organization with lots of different teams probably
has a valid need for someone to bring in cohesion.

------
lucifer
The practice of architecture is inevitably entangled with one or more
notational and representational systems. This is true if you are architecting
ships, infrastructure, buildings, or software. Complaining about UML is like
complaining about drafting, drafting notation standards, and CAD software.

~~~
blasdel
It's more like there's only one drafting standard, and it was built by and for
the Soviets in the 70s.

