Why I don't believe in software architects

http://www.mikhanov.com/2010/01/26/why-i-dont-believe-in-software-architects-120

by smikhanov • 16 years ago

47 53 16 years ago

modoc4• 16 years ago

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.

smikhanov4• 16 years ago

I'm sure there are places like that, I've worked at one (Rational Process - shudder)

Thank you for your honesty :)

The bottom line of my post was "beware of the advertise SA positions, they tend not to offer what is usually expected from an advanced position like that".

I also think that a key to being a good SA is to keep writing code, no matter what happens. Looks like this is exactly the case for you.

modoc4• 16 years ago

I absolutely agree that if you like coding, don't ever stop. It will also make you a better architect.

In my experience, large companies who use Rational will have their architects buried in Rose building UML and writing 150+ page docs all day. Smaller and/or agile/XP companies will be looking for a super experienced coder, who can mentor, and look at the big picture, see the business drivers, etc...

Ideally this sort of thing can be figured out early on in the interview process. "How do your other architects spend their time?" etc...

hello_moto3• 16 years ago

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.

modoc4• 16 years ago

:) 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:)

bmelton• 16 years ago

I'm in almost the exact same boat, though I find that much of my job is in just predicting pitfalls, and in anticipating when things won't work.

As a federal contractor for an agency that prefers to use COTS/GOTS software, there is a surprisingly great need for having a developer that can look at a given piece of software, intuit how it works, probe its sales and development teams to say "Well, this claims to do Kerberos authentication, but it really does GSSAPI, and hence, won't work with your existing OpenSSO implementation."

I also code a lot, mentor other developers, etc., and yes, it IS a great role.

japherwocky4• 16 years ago

This is much closer to the role a real architect plays in a real architecture firm.

Sketch out the big picture, take care of the trickiest details, wrangle your underlings into doing the rest.

gaius• 16 years ago

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.

lucifer• 16 years ago

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.

blasdel2• 16 years ago

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

delano• 16 years ago

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.

smikhanov4• 16 years ago

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

What are your reasons, BTW?

arethuza3• 16 years ago

One reason might be that "real" architects get a bit upset at the use of it in the software world.

japherwocky4• 16 years ago

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.

arethuza3• 16 years ago

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.

smikhanov4• 16 years ago

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.

arethuza3• 16 years ago

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.

Maro• 16 years ago

Isn't that the job of a manager: delegate the technical decisions to the best and brightest teammates? I would think the software architect is the "default" choice.

drtse4• 16 years ago

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.

smikhanov4• 16 years ago

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

Silhouette2• 16 years ago

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_baker3• 16 years ago

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

joezydeco• 16 years ago

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.

hga5• 16 years ago

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

coffeemug• 16 years ago

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.

j_baker3• 16 years ago

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.

blasdel2• 16 years ago

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.

Why I don't believe in software architects

Related Stories