
Being a Software Architect - bitsweet
http://coderwall.com/p/lbda2q
======
MattRogish
I don't like Software Architects.

What is implicit in the SA role is that the rest of the dev team is full of
dummies that can't think strategically or architect big parts of the system.

This naturally leads to the SA producing ever higher and more complicated
abstractions that the simian developer tries to implement, poorly, and the SA
becomes an irreplaceable high priest -- inflating their salaries and
prominence and depressing the salaries of the rest of the team.

Where I work, every developer is expected to be "architect-quality". Sure,
more junior folks don't have the experience, but they're expected to have the
_capacity_ for strategic, high-level thinking. As they mature, they take on
more and more architectural decisions. If they can't do that, then we've hired
the wrong person.

Ultimately, that's the only way I know how to scale dev teams and produce
amazing software. The SA/Dev stratification is an anti-pattern.

~~~
chriseppstein
Did you actually read the link before commenting? Honest question.

~~~
jfoutz
It's a clever list of aphorisms. None of the qualities you desire are actually
defining features of the SA, though.

Who on your team is not a student? who is not a mentor? who should gloat when
they are right? who does not understand the most precious parts of the system?

I think your list is less about A Software Architect and more about people who
take pride in their work.

~~~
chriseppstein
I think you're starting to understand my points then.

------
roguecoder
The "writes code" part is key to actually using software architects
productively.

The times I have seen architects be productive additions it was essentially a
job title for "a super-senior-developer who interacts with everyone." The
times I have seen an architect be unproductive or a hinderance it was a job
title for "someone who spends all their time telling other people how to
code." I've even seen architects who were never coders: since I believe high-
level design decisions are intimately linked to low-level design decisions the
idea baffles me.

~~~
jonstjohn
I agree. Reading through the comments I see that many people say that every
develop should be an architect. Although I agree that developers should be
able to think in terms of the larger picture, in my experience, certain
developers either have more experience or are more capable of seeing how
things fit together.

Some developers are better at the micro, others at the macro, and ideally
you'll have one or two that can do both well. Personally I think it is good to
have somebody who can work across teams and software areas to keep track of
the bigger picture.

------
mcgwiz
I don't like software architects.

I'd much rather have a team full of A-type engineers that will stop at nothing
to force their individual vision into a project.

We can trust that every top-notch developer has the whole project's welfare at
heart, and not just the part that they own and whose success impacts their
performance evaluation. Ergo, a totally flat team of aggressive rock-star
engineers is destined to build their constituent parts in a homogeneous and
consistent fashion.

A team of engineering ninjas are bound by a higher power to perfectly
coordinate their coding style, core patterns, API design, conventions vs
configuration trade offs, third-party dependencies, feature preference, etc.,
in a way that resonates precisely with the needs of the business and the risks
of the industry.

In short, all world-class engineers are business-savvy, have no conflicting
interests, never have unresolved disagreements, and are also telepathic. And
since all the engineers I work with are obviously world-class engineers,
having a single point of accountability and a single vision of quality around
is an insulting slap in the face!

~~~
imechura
This is brilliant sarcasm! I have worked with several of these A-List teams /
"democracies". They are a perfect storm of nothing ever getting done because
agreements cannot be made on a single issue.

------
NiteCoder
I've worked in places where "architect" was nothing more than a title given to
senior developers to soothe their egos so they didn't notice they were
underpaid. I've all seen architects who didn't code, preferring their ivory
towers of UML diagrams. Neither of these types are effective.

A real software architect is a force multiplier: you help teams be more
productive through your contributions, be it design, code, mentoring or
leadership. Rather than being the team showboat, a good architect is the guy
that helps everyone else be even better at their jobs.

------
gouranga
I see lots of vitriol here. I think there are a lot of bad experiences,
probably I imagine from the ivory tower architects that you get from big
consultancies and the like.

I am a _proper_ solution architect. I'm there to serve others with my
extensive experience, nothing more. I am always there in the shadows to keep
the cogs oiled, provide canned and well tested ideas, stop things that
shouldn't happen, start things that should, make sure communication is made
and most importantly spend time teaching and helping people. I'm also there to
do the risky horrible jobs that no one else wants to be responsible for.

You're supposed to be more a spiritual guide than a facist dictator.

I will say that there is no place for me in an organisation with less than 10
hands on engineering staff.

------
locacorten
Reading throught the comments, it's amazing to see how much damage the cowboy
culture of our community has produced. "Every engineer should be an
architect." Ha, ha, ha...

This also goes hand-in-hand with "Everyone can be a programmer" mantra that
everyone likes to repeat. Go teach pointers to 20-year olds and you'll realize
how most people can't be programmers.

I don't understand where this culture is coming from. I definitely can't fix
my car; when I see my mechanic, he doesn't tell me how I should go learn how
to fix my car. I'm confident he's much better at fixing my car than I am. The
same is true with other professions -- lawyers don't tell clients to go
interpret laws on their own and dentists don't tell people to go remove teeth
on their own. What is it about our community that we ingrained into our youth
that "writing code" is the thing that everybody must do?

------
mindcrime
I don't get the hate for software architects. Would you try to build a
skyscraper without an architect? No? Then why is having one a problem for a
large software system?

Sure, if you're building something small, one person can be architect and
general contractor and electrician and painter, etc. But the idea of division
of labor is usually seen as a good thing. Not sure why we hackers should see
it any differently. If you're building enterprise software systems that span
multiple divisions and locations of an enterprise with 30,000+ people in 100
countries, ya know... you probably do need somebody who's job is to look at
the big picture, see that the pieces being assembled fit the needs of the
firm, and that the pieces work together in a clean and elegant way.

Having an architect, where needed, doesn't denigrate or devalue the role of
the developers at all. It really is a different role that needs to be filled.

~~~
astral303
Division of "labor" is counter productive in development, because in immortal
words of Jack W. Reeves, "Code is Design." Say anything else (UML) and you're
deluding yourself. So non-coding architects are effectively only HALF-
designing the system.

Read this article and weep, for it was written in 1992 and 20 years later, is
still rings true, even though there was no UML at the time:
[http://www.developerdotstar.com/mag/articles/reeves_design.h...](http://www.developerdotstar.com/mag/articles/reeves_design.html)

The problem with non-coding architects is that they are _isolated_ _from_
_learning_. They have an incomplete feedback loop, and are isolated from the
repercussions of their decisions. This at first makes a non-coding architect
useless and then makes him actively wrong. This is especially true in systems
as complex as enterprise systems.

Because code is design and because building the design is free (in comparison
to building a bridge), you need to actually translate your mental design into
the real blueprint--the code. If you are isolated from that, then it's like
sketching blueprints. You may be consistently wrong on some aspect of it, but
you'll never know.

If skyscrapers could be built and torn down overnight, I bet you money
architects would build the skyscrapers without the same rigor of blueprints,
look at the result and say "Nah, move this a foot over!" and build again.

The correct equivalent for building construction workers is the _compiler_.

------
jusben1369
Anybody fairly handy can build a garden shed. If someone showed up calling
themselves an "garden shed architect" and stood off to the side directing
traffic I'm sure the "builders" would find it and them to be a complete waste
of space. (wait cheesy pun alert?)

However, how many of us would like to get into an elevator ready to shot us to
the 100th floor knowing that there was no architect on the project as all the
builders decided that was an unnecessary title and those functions could
easily be handled by the GC?

Amazon, Heroku etc has made it much easier to build garden sheds - there's a
lot more garden sheds around per large building than there used to be. So I
suspect if you believe the SA title to be completely unnecessary it's most
likely because you're building sheds not buildings. Doesn't mean we still
don't want and need them for those larger buildings.

~~~
joe_the_user
Yes,

But there is a difference between software construction and building
construction.

The difference is that for software, anything that would normally be
"construction work" in another field is _or can be_ done in an automated
fashion. Thus it can be argued that all programming is done at the "design" or
the "architecture" level. That isn't to be say that the software architect
position is alway illegitimate. But gives one an idea why, in contrast to sky-
scraper construction, some people might legitimately want to dispense with
architect as a distinct position.

------
swalsh
I think of the role of Software Architect as almost a code accountant, keeping
technical debt in check.

~~~
ctdonath
Good.

AND the SA holds an overall vision of what that accounting entails. An
"obvious" change in module A may have severe repercussions in module B, which
neither developers for A nor B may see in a timely manner. Without "code
accounting" with a _vision_ \- and an informed experienced one at that - 'tis
too easy for over-confident short-sighted developers to go crashing through
other sections of code, leaving something which may work but degrades
performance & maintenance, and which is so pervasive and hard to fix the team
must just live with it.

AND the holder of that vision must be able to articulate it, in documentation
& code & conversation, in a manner which keeps the team cohesive, informed,
and upbeat.

------
wormphlegm
This sums it up nicely:
[http://dilbert.com/dyn/str_strip/000000000/00000000/0000000/...](http://dilbert.com/dyn/str_strip/000000000/00000000/0000000/000000/00000/1000/800/1890/1890.strip.gif)

~~~
Spearchucker
This sums it up nicely too: <http://bredemeyer.com/>

~~~
modarts
From the site:

"Meta-architecture: the architectural vision, style, principles, key
communication and control mechanisms, and concepts that guide the team of
architects in the creation of the architecture"

I think poe's law applies here; I honestly can't tell if this site is a parody
of the "software architecture" discipline.

------
nzonbi
The definition of a software architect varies. In general, mainly refers to
those that are responsible for the higher level design of systems.

In my opinion, a great system architect is a great developer, who also have an
artistic flair. Those people that, when facing difficult design problems, can
often come up with brilliant abstractions. That are so clever, that feel like
art. Not only in development, but also in related aspects, like UI.

Those great abstractions will increase the productivity of everyone using the
system, and in the end can accumulate to very high amounts of value.

~~~
stephencanon
You have described a skilled engineer. Why do we need to call her a silly
name?

~~~
dack
Why is "skilled engineer" better than "architect"? They are all just names -
and it seems that the main reason people avoid the word "architect" is just
because it has been abused in the past (and for some companies, the present).
Maybe that's valid, because using the term may inadvertently make someone
think that you're bought into the "no coding, but telling other people how to
code" mindset.

However, I don't think "architect" is a silly name on it's own - it's just
another piece of vocabulary we use to describe a certain role. It's no
different to me than "VP" or "Janitor" or "Test automation engineer".

~~~
codeonfire
Architect, chief engineer, principal, fellow. These all mean 'put out to
pasture'. These are supposed to be positions of leadership, but with no direct
reports there is no one forced to follow. Developers who already have to deal
with the business bureaucracy are not going to listen to someone because of a
fancy title that does more politicking than development.

Plus architect gives the image of a scarf wearing drama queen who throws
tantrums.

~~~
mikeflynn
In my experience that architecture roles can definitely mean that at a lot of
companies (the pasture part specifically, but I would like a scarf). To some
degree it's natural to let the role end up like that, but as the person in the
role, you have to work to make sure you're still involved with all teams even
if you don't have any direct reports.

------
specialist
I met Grady Booch at the kickoff meeting for the Society of Software
Architects (or some such). OOPSLA 1998 in Vancouver.

I asked Grady Booch "What is software architecture?"

He answered "Software architecture is what software architects 'do'."

At that point I stopped caring.

Until I found the book Design Rules: The Power of Modularity.
[http://www.amazon.com/Design-Rules-Vol-Power-
Modularity/dp/0...](http://www.amazon.com/Design-Rules-Vol-Power-
Modularity/dp/0262024667)

It is the sole source I've ever encountered that had anything useful,
actionable, insightful, informative, rigorous, etc.

Alas, I've never been able to synthesis Design Rules' methodology into any of
my efforts.

Because what I do is _software craftsmanship_. I've designed some awesome
stuff (and a lot of crap). But nothing rigorous, repeatable, explainable.

For a few years, I bought every software design book I could find. Some of
them actually good. But the ones claiming to be about "software architecture"
are really describing software craftsmanship. Describe as in descriptive, vs
prescriptive.

From memory, Design Rules states that architecture is the set of visible
design choices in a product. The entire thesis of the book, backed by oodles
of case studies and data, is that deciding where the lines between subsystems,
the interfaces, and the allowable parameters for those interfaces, is
architecture.

PS- Just read the OP. Nothing actionable. Move along.

------
dbattaglia
The name plate on my desk says "Software Architect", and honestly I feel kind
of silly repeating that when people ask what I do. I usually just tell them 'I
write software'. That said, I've worked in a bunch of different C#/.Net/SQL
Server shops (IT depts, educational, shrink wrap apps, advertising), and I can
see in some of these places why the role can be necessary. Not because .Net
demands these over-architected enterprise uber-solutions, but because a large
amount of developers in those places just don't seem to care about what
technology choices and design methodologies are out there. And there's nothing
wrong with that, so long as there are some there who are thinking beyond the
next sprint, regardless of what their job title is officially.

I'm also pretty sure the role itself means different things depending on the
scale of what the company is doing. At my current job (a recruitment
advertising company w/ some very large clients), we have a lot of traffic and
only moderate development resources in-house, so you really need to depend on
proven technologies to prevent the whole thing from falling apart. So part of
my job is making sure we are using the right technology where we need to and
only rolling our own when it makes sense.

------
Spearchucker
Agree with everything he says. Except for the part that I don't.

 _A software architect creates a vocabulary to enable efficient communication
across an entire company._

That needs to be done with caution, because in a small team/organisation it's
absolutely correct. In a large organisation it's just a non-confrontational
way of saying "We need an enterprise architecture." That ends up becoming an
IT dictionary whose value is to IT alone [1]. And IT serves the business. Not
the other way 'round.

If you're doing this in a large organisation, do it for a project, and not for
the organisation. It's right up there with the architect that sees an
enterprise service bus as a silver bullet. Aka a unicorn.

Edit: [1] Unless you're HP Services, IBM, ATOS, Cap Gemini or some similar
systems integrator, because if you're one of them you're in the business of
selling billable hours, and an enterprise architecture is an awesome way of
billing to eternity without even having to deliver business value.

------
sbochins
This is a nice ideal to have. Unfortunately I have never had the pleasure of
working with the architect the OP described. I would say the ones I've dealt
with have had some combination of: arrogance, stupidity, lack of technical
knowledge, lack of creativity, and arrogance (did I say that already).

------
biroran
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.

------
thatusertwo
A software architect I worked with before thought he was gods gift to
programming, every time something worked out it was his work, when it failed
he always blamed the 'process'.

You should change the title to 'Being a Good Software Architect'.

------
leothekim
s/Architect/Engineer/g

None of these characteristics should be stuffed in an architect role. Every
engineer should possess them.

------
kylek
Terrifying and silly to think that anyone cares this much about titles

~~~
cranklin
True. But regardless of the official title, somebody still plays the SA role.

------
Produce
The same could be written of managers and leaders. They exist to serve those
they work with, not the other way around. Our society just doesn't seem to
understand this.

------
krollew
"A software architect lives to serve the engineering team -- not the other way
around."

I thought they are supposed to serve people who are going to use software.

------
cjdrake
I liked the article. Forget about whether the word "architect" is used by some
as a pretense--the author is suggesting essential qualities of a leader. Teams
need direction; this seems to me like good advice for a person to provide
direction to other peers effectively.

------
btipling
Is it really bad to gloat when right? When people are right, let them gloat.
Why does that matter? As long as they aren't trying to make the people who
were wrong feel bad about it.

~~~
scott_s
_As long as they aren't trying to make the people who were wrong feel bad
about it._

But that's precisely what gloating implies.

------
andrewcooke
this smacks of _noblesse oblige_.

("how to live safely in a science fiction universe", apart from being a pretty
good book in its own right, really takes this apart)

------
j45
I liked the article.

I'd like to apologize with some liberty to the sentiment in this thread who
deny someone has value because they can't see it. If I may go out on a limb,
I'd like to try and apologize for what I feel is being trivialized, but to me,
is non-trivial.

I'm sorry every piece of software looks like CRUD and Reports to SA's.
Nothing's special like Pagerank special, no matter how many magical automating
unicorn wands of libraries and frameworks and methodologies we try to make it
seem magical with. Domain knowledge, and experience, on the other hand, seems
generic, but it's understanding how the data works, plays, interacts, and
exists in all it's states.

I'm sorry if some developers forget that software only answers one question,
"Where is everything at?" in different ways for different users, and it's made
to be more than it is. We're not out to trivialize anyone's work, however,
this point is a rallying point, not something to feel insecure about on
anyone's part.

I'm very sorry for all the failed software projects that are inherited for
wanting to use the latest, greatest, untested, unhardened. They have
compensated well for letting me teach customers how you shouldn't build a
house without a blueprint just because you can build a shed without one. No
agile mega global waterfall method will get around having to understand the
world people face when they use computers in their day to day life. No one
cares what we code in, or how we coded. It's up to us to do well, but most
importantly, reach a goal for a wider audience without getting hung up on
ourselves. I love the latest and greatest tools, but I know better than to put
it into production somewhere to be kind to the future me.

I'm also really sorry to myself that I might have learnt some skills I may
never use or enjoy using, like overseeing a full cycle ERP implementation.

It did help tremendously, though in being able to find and connect the dots in
intricate relationships between data and be able to put a picture together
that makes sense for everyone beyond me.

SA's existing do not mean anyone is a dummy, or smarter. It just is, what it
is. Trivializing what anyone does is a pretty close minded, harsh judgement
for the intelligence and open-mindedness here. Just because one person can't
imagine a position having value, doesn't mean the value can't exist.

Architects get thrown down more wells than they deserve and smart developers
are always open to learning from the rattlesnake biting the other person. It
goes both ways. Great architects listen, listen, listen. They provide the
foresight that today can't always show. Good architects code. Most I know
thrive on Proof of concept coding things.

If there's SA's that don't stay current (meaning, they don't keep hacking with
new stuff), that's something that can be faulted in anyone.

We can look at it the same way with developers.. having a legion of coders who
have not yet had a relationship with a code base for more than a few years
don't really learn the reality of being kind to your future self in code,
thought, and trivialization of what anyone does.

Maybe some part of this is from having been online for almost 2 decades, and
building web based software for over a decade. If I'm off, I apologize and ask
for your tolerance.

Our coding isn't special. Frameworks come and go. All glorious languages
worshipped today were made in the 90's. Any code that is 2 years old is
legacy. So, what is your legacy?

Mine is writing code that can outlast and not need me anymore and can be well
structured and maintained without me. Why? So I can go solve the next problem.

Connecting a need to technology and making ourselves invisible is what I
really enjoy doing, but maybe it's just me.

------
woodholly
Read Cringley's Accidental Millioniares book for lots of background on the
"Software Architect" idea, particularly at Microsoft.

------
moron
Huh.

Where I work, Software Architects are people who get paid lots of money to
dick around with "new" technologies like RabbitMQ. Then after spending
seemingly weeks implementing a trivial proof-of-concept app with the new
thing, they present some slides and Visio diagrams at a brown bag nobody
attends, and the rest of us ignore them so we can keep building things that
actually provide value. Then they go on vacation to Aruba (probably).

~~~
dr42
How very cynical indeed. Speaking as a software architect, sometimes it's
important to get people to lift their heads up from the day to day _adding
value_ and look at new technologies. Many times developers are so focused on
the bug/feature du jour, that they aren't aware there are other ways to do
things, possibly better.

Having been a developer for a long time, the thing I have found is how much
technology repeats itself, and how at its core, its all very much the same.
The same algorithms I have used, like bloom filters or priority queues for
example, have application in social networks and 3d rendering engines etc.
Having done most software paradigms, an architect us supposed to know which
ones work, and when they work.

I haven't written slides or visio in years. Nor have I been to Aruba :)

~~~
stephencanon
I would hesitate to hire a junior engineer who didn't understand basic
subjects like bloom filters and priority queues and when to use them. I
certainly wouldn't hire one who didn't know how to research alternative
approaches on her own, without guidance from an "architect".

~~~
nathan_long
I'll bite. I consider myself a decent developer (but then, who doesn't?). I
don't know what you mean by "bloom filters" or "priority queues" without
Googling for them. I feel pretty confident that if they were the best solution
to a problem I was having, I would find them through research.

Why did you pick those as "basic subjects" for a "junior engineer"? Are they
important to your particular area of work?

~~~
stephencanon
I'm a micro-optimization and numerics guy by trade (mostly I write math
libraries); they are almost completely irrelevant to my area of work.

Priority queues should be covered in a competent introductory data structures
course. Bloom filters are marginally more obscure, but I still expect a good
candidate to have come across them at some point. They're so widely used that
it's pretty hard to avoid learning about them if you've done any significant
amount of work or just spend time reading HN (they come up in someone's blog
every month or so).

Note that I said "would hesitate to", not "wouldn't hire". If someone were
otherwise a strong candidate, but happened to not be familiar with these, I
would almost surely still hire them.

I should clarify that a typical candidate for a junior position on my team is
either coming from graduate school or has 3-5 years experience in industry. I
have correspondingly higher expectations for their background knowledge.

~~~
dr42
This is just not true.

 _Bloom filters are marginally more obscure, but I still expect a good
candidate to have come across them at some point._

Possibly in your area the candidates you get may have come across them, but
then they wouldn't be junior engineers, _by definition._ If you're advertising
for "strong algorithms" candidates then sure, but I bet half the people
reading this have never used or come across any probabilistic data structure!

~~~
ramchip
> then they wouldn't be junior engineers, by definition

I don't think so. My impression is that junior/senior is defined by years of
experience more than technical skills. Having been out of university for one
year now, I know I sure as hell won't get a job as a "senior engineer"
anywhere, even if I could easily implement both these structures.

