Hacker News new | past | comments | ask | show | jobs | submit login
Being a Software Architect (coderwall.com)
168 points by bitsweet on July 6, 2012 | hide | past | web | favorite | 108 comments



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.


This may be terminology. Chris' blog post clearly was attacking that part of the problem.

The issue is that many people put 'architect' in a slot over 'developer' and that is wrong, it should be a slot beside 'developer.' I've interviewed lots of folks who said "I want to be an Architect!" and asked them what they thought that meant. Far too many of them it was some sort of 'decision maker without deliverables' kind of job (who wouldn't like that). But that isn't what architecture is about, it's about knowing that you need a bathroom near the dining room, or that a flat roof doesn't work where you get a lot of heavy snow, or using a database to hold what is essentially log data, or encryption as a part of the data structure layout. I always think 'systems analysis' rather than 'software architecture.'

When Sun was merging SunOS and System V we dealt with "Systems Engineers" from AT&T who were writing "Requirements Documents" but they had no clue how those requirements were affecting the underlying system. Most of the folks at Sun held them in great disdain, and their coders were not "allowed" to decide issues on the requirements. That was both sad and dysfunctional.

The trick is that some people are better at seeing the trees, and others are better at seeing the forest, and a few can both see the forest and point out which trees are out of place. Cultivating all of them for your team is a good idea, the product will be better for it.


"[architecture is] about knowing that you need a bathroom near the dining room, or that a flat roof doesn't work where you get a lot of heavy snow, or using a database to hold what is essentially log data, or encryption as a part of the data structure layout. I always think 'systems analysis' rather than 'software architecture.'"

And I would argue that I expect every member of the dev team to be able to realize those things. Perhaps not right away (you're not birthed from the womb knowing proper database indexing) but absolutely as a person moves up the developer ladder they are expected to know and implement proper architecture.

_Not_ expecting those things merely turns a developer into a fancy sort of typist that does exactly what they're told (implement this spec). And it's been my experience that those sorts of programmers (and the companies that birth them) produce pretty boring, uninspired, miserable to use products.


I think you may be under valuing good developers. I worked with a guy once who wrote brilliant code, artful, efficient, and very few bugs. But he couldn't 'architect' anything. His completely functional code which met the need when written ran up against changes in the future (which looked obvious in hindsight but they weren't to him) which necessitated re-writing huge chunks. That he wrote quickly was a blessing and had covered up this guy's lack of architectural 'vision' by his super human ability to rewrite the whole thing from scratch. You pair this guy with someone who sees the matrix and you're golden, you rely on him to provide the architecture and you're doomed to fail.

I don't know what it is that differentiates folks this way, but if you meet enough developers you'll come to see it too. And someone who writes solid code but can't see the architecture is just as valuable. Someone who can do both, you're golden, but finding and keeping those people is hard if not impossible at times.

"_Not_ expecting those things merely turns a developer into a fancy sort of typist that does exactly what they're told (implement this spec). And it's been my experience that those sorts of programmers (and the companies that birth them) produce pretty boring, uninspired, miserable to use products."

Don't conflate cause and effect, if they implement the spec accurately and you get a boring uninspired product, then the spec was boring and uninspired. You suggest they should rebel and say "Hey, if I do this it will lead to a boring and uninspired product!" but not knowing what you don't know can be killer here. If you are managing a team putting out boring product kick your 'vision' people in the ass, if the product is great but just can't reliably work, have a talk with the folks putting concept to code. That is what I mean when I say cultivate a team that has all the skills rather than trying to find the "unicorn" who can do it all.


Being able to write large swaths of code from scratch quickly to spec and with few errors is very valuable in software companies that want to move quick. Especially when experimenting or prototyping.

But if you are building a larger, longer lasting product with even a modest sized team you will run into trouble quickly.

Not many developers practice throwing their code away and taking a different approach when requirements change. If every release the codebase changed completely other developers wouldn't be able to keep up. This is especially true if this developer is working on the basic arcitecture of the program.

You can't re-write everything every release. Planning has its merits. So if the developer was we-writing it every time, but came closer to a better, more permanent solution each time, then he is learning and evolving and this practice will slow down.

However, if he is simply producing low-quality code and cheap tricks to ensure proper behavior, while it works now that talent doesn't scale well and will impact the performance of other team members.

You want to promote code stability - and this isn't held in the state of the codebase and passing tests as much as it is the net effect of developer behavior over time. I agree that we all can't just go to the unicorn store and solve our problems. But be conscious of the side effects you buy when you start thinking about it as managing a team and not building one.

*edit: Matt Rogush said it better


I see your point - this guy wrote some nice code that didn't consider "the future". I'd suggest that in a well-rounded team, there should've been a number of people who he either paired with (if you believe in that sort of thing) or code-reviewed his work that should've caught that, right? You implied that would've fixed it but never happened... That's interesting.

Anyway, if this fellow continually didn't "learn", didn't "grow" - at least ask someone to review his work, then I would council him that this needs to change or he's more of a liability than an asset. Enlightenment is knowing your weakness and if, for some crazy reason, you can't do that - then you're not really a "good developer", right?

Sure, you can sorta solve the immediate problem in front of you but you're an apprentice, or mid/junior sort of a person - and I expect you to mature out of it. If you don't? Not a good fit.

I'm not talking about mythical unicorns that do everything exceptionally well - just that the team should consist of folks that can generally do what is considered "Architecture" - and it should come within the team rather than someone outside of it.

I consider labeling someone as "Architect" as suboptimal - "Oh, I don't have to worry about architecture because we have The Architect to do it for me".


I consider labeling someone as "Architect" as suboptimal - "Oh, I don't have to worry about architecture because we have The Architect to do it for me".

100% agreement. I too have problems both when an individual wants to label someone as 'the architect' and or when someone demands the title. It can be a hint that the person has issues around technical disagreement (I've seen it most commonly in folks who could not reason to a position and so wanted authority to say "just do it this way." and be done with it) Every team will have a 'natural' architect which will be someone who can both engage in disagreements effectively, and they can see why things are going the way they are going, in addition to the how.

Anyway, if this fellow continually didn't "learn", didn't "grow" - at least ask someone to review his work, then I would council him that this needs to change or he's more of a liability than an asset. Enlightenment is knowing your weakness and if, for some crazy reason, you can't do that - then you're not really a "good developer", right?

In this particular case, writing code quickly was considered more valuable than architecture. But that illustrates another problem, which is often folks get mixed messages about this. Early on in your career writing code cleanly, quickly is a huge win, you get great reviews and promotions. But if you realize that you don't "see" it, when it comes to how the system goes together, well suddenly your conflicted, "Am I this great person or a fraud?" and you may respond in a number of ways. Yes, if it goes on long enough without mentoring you become a liability, if you get slapped down because you utterly failed the 'vision' test that can cause massive depression. Good mentoring is essential here.

So this is where we may just agree to disagree, when you write "I expect you to mature out of it. If you don't? Not a good fit." I caution that you might find yourself throwing a great developer under the bus someday with this approach. Your mileage may vary of course, usual disclaimers Etc. Not everyone can be a good architect, not everyone can be a good developer, but not being good in one does not preclude one from being good in the other.


"So this is where we may just agree to disagree, when you write "I expect you to mature out of it. If you don't? Not a good fit." I caution that you might find yourself throwing a great developer under the bus someday with this approach. Your mileage may vary of course, usual disclaimers Etc. Not everyone can be a good architect, not everyone can be a good developer, but not being good in one does not preclude one from being good in the other."

Good arguments; that very well could be. My data is different, but obviously our mileage may vary. Plural of anecdote is not data, and all that. :)


"I see your point - this guy wrote some nice code that didn't consider "the future". I'd suggest that in a well-rounded team, there should've been a number of people who he either paired with (if you believe in that sort of thing) or code-reviewed his work that should've caught that, right? You implied that would've fixed it but never happened... That's interesting."

But but but.... YAGNI. There's a constant struggle between building something that might (or perhaps even 'probably will') be needed in the future vs getting something out on deadline now. And had the guy in question built stuff to be configurable and extendable for future work, but constantly missed deadlines, he'd probably have been regarded much differently. Even when those configurability issues are found to be of much use later on, I've found that it's often not valued enough at the time it's built that way.


I like software architects.

While every member of the team may be capable of strategic thinking in general, not every member of the team actually has sufficient domain knowledge to chart everything out.

Building some data link avionics software that needs to be DO-178B Level C compliant and operate within the parameters specified by the EuroControl Link 2000+ initiative? Not every hacker off the street will be able to come up to speed on the implications of all of that in short order. Someone with fifteen years experience in the same or similar technologies will be able to plan the system and guide the more novice programmers.

But it likely depends on what software you're building. If you're building web applications that cull together lots of common-knowledge ideas, then having an experienced individual plan it out for you might not be as needful.


I don't dislike Software Architects (I've only worked with actually brilliant people with the SA title), but I think there's a strong truth to this:

"The SA/Dev stratification is an anti-pattern."

A good architecture is a good high level organization of the code. To be a good architect, you have to be a good developer. And you cannot be a good developer without being good at software architecture. So as far as I can tell, the only actual reason for the SA/Dev divide is to have titles to give to people. Titles are essentially something an organization gives to people in order to keep them happy. And to me, "architect" seems like a fancier title than "developer", if only to sound better to strangers at a party.

I'd like to hear people's opinion of this. In my organization, there are two career paths, one for "architects" and one for "system developers". They are presented as equally valuable roles. Are they actually distinct roles, or only a useful invention for the organization? Moreover, is this distinction actually valuable?


There's another side to being an architect that many incredibly brilliant developers I know can't do, and don't want.

What I'm talking about are the soft skills - stakeholder management, risk management, conflict management, politics, negotiation, and so on.

There's an overview here: http://wwww.wittenburg.co.uk/Presentations.aspx

You don't need to be "an architect" to be good at these things, but an architect should be good at these things.

Not having or even wanting these skills is not a bad thing, it's just that we're different, and good at different things.


If there is a need for a separate position to do that - the softer side - what does that have to do with software architecture?? The best solution to the problem doesn't really care if the VP of Marketing is sad that they weren't involved.

However, I do agree that role is important but from what I've seen it's typically the job of a VP Eng, CTO, Scrum Master - "Management-y" types.


I respect your view, so up-voted, and yet disagree. I think anybody, regardless of role or industry can be more effective with those skills. And technical ability aside (note, that is critical), architects in particular should (in my opinion) be good at this stuff.

[Edit] Just saw you've an MBA. I now understand your thinking.


Well, I absolutely agree that the softer side is huge in just about any career. But if we're centralizing the softer side into a defined role (as you seemed to do with the "SA"), then I'd say it "better" lives somewhere else, as the other "technical" SA stuff is distributed to the team.


The usefulness of the Architect role may also depend on the size and topology of the organization. I work in a Very Large Enterprise Company, and our group's architecture team has to make sure not only that our group's systems/projects are well-designed, consistent, maintainable, scalable, etc, but also that they interact nicely with the MANY other geographically-, pyramidally-, and budgetrarily-distrubuted groups, that we aren't duplicating effort, that the lines of responsibility for a given system integration make sense, that we have the same vision for the trajectory of the overall enterprise strategy, etc.

This means our Architects have to collaborate/negotiate/politick with many other groups' architects (and the occasional program manager), while having both the 100,000' perspective on the entire company's organizational structure and systems, as well as the fine-detail nuts-and-bolts of the workings of our own group's systems so we know what complications may arise in interactions with other systems.

NB Our group director has a far-higher-than-normal grasp on these details (others are not so lucky!) but the level of cross-enterprise collaboration is more than he has time for.

Some of this sounds like it'd be the work of a Systems Analyst (which is what we use the SA abbreviation to mean), and that's true, but there are plenty of actual architectural and technological considerations as well: infrastructure issues, build/release coordination, enterprise schema maintenance, shared libraries/technologies (example: which of the four ESB technologies should we use for this project? Oh, really, you want to give us a flat file from the mainframe but wrap it in <xml></xml>? Argh.)

We also must keep a close ear to the product management/BA group and the stakeholders so we make sure our vision is in sync with the business's needs.

So you could say our architecture group is a mix of internal technical leadership, R&D, development of key moving parts (in our case, integration code), mentorship, systems analysis, negotiator, integrator, etc.


Although I agree with your strategy of hiring, it sounds like what you are saying is "hiring non architect-quality people is an antipattern". Okay, well obviously bad developers make a bad team.

Even on a good team, there are more and less experienced developers. I don't see what's wrong with calling the most experienced ones "architects" if that's what they want to be called, as long as it's clear that it isn't an excuse for the other developers to ignore higher level goals and design.


It's a role that any senior engineer should be able to take. And yes, every senior engineer should be architect-quality, but in some projects, it's useful to ensure that at least one person is tasked with the sole role of keeping an eye on the system as a whole, able to keep the entire platform in their head, and do the dirty work of documenting and cleaning up rough edges. In some cases, the architect can blaze the trail ahead a bit so that everyone else can focus on shipping code, rather than spinning wheels evaluating technical options.

If possible, it's a rotating role, with each senior engineering having to do duty as an architect just as he or she would do duty on devops.

Maybe you're working on a project that doesn't need that level of overhead. Maybe it's small enough and the system is simple enough. But at some level, the amount of architectural work becomes big enough that its worthwhile having someone on it fulltime.


I agree with this. Not everyone is a software architect. It should be the goal of the development team to turn every developer into one.

In my mind, the role of a SA is to make the right decisions until everyone else can do it on their own, but enable and teach along the way.

* spelling


I don't like them also.

Even more - I hate this title.

And I'm a SA at my current employer.

But Chris talk about right SAs - programmers with strategic thinking responsible for architectural decisions.


Who said there must be only one?


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


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.


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


If you were asking an "honest question", wouldn't you be expecting to get some further information from the answer? I don't see anything.

It just sounds the usual "Did you even read XXX?" rhetorical question. I'm not even against rhetorical questions. It's simply annoying when "honest question" becomes nothing but a emphasizer in the fashion of the common misuse of "literally" or a "justifier" ("I think you're idiot" is out of line but in our world of touchy-feely-ism, "I honestly think you're an idiot" is OK)

Edit: Instead of just "taking a shot" by saying, "did you read the article", I'd suggest saying why you don't think the comment reflects the article. Otherwise, your post says little more than a downvote.


Absolutely. And you lost me from the first point:

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

This implies the SA is not a member of the engineering team. Or if they are, they're "special" in a way the rest of the team isn't. And that I whole-heartedly disagree with. Most of the other things I expect every member of the team to do, anyway.

So if your point was to say - "Everyone in the dev team needs to be the SA", then yes, you're right. But that's not how it reads.


I agree. Reading through this list, I wonder what we would lose by replacing "software architect" with "lead developer" or even just "really good developer". It seems like the list would retain its meaning, without the potentially muddying effects of a word (architect) that comes loaded with all kinds of preconceptions.


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

The IQ of a team is equal to the IQ of its dullest member divided by the number of members. Ergo the only way to have good systems architecture is for a handful of smart people to do it. These people are the architects.

The development of the IBM System/360 is a famous example of why this matters. They first tried to design the system by having a few hundred decent engineers do it in distributed fashion. The resulting design was so poor it had to be thrown away. The second try had a small team of architects plan the system while everybody else sat on their hands. It worked spectacularly well.

P.S. If you think this does not apply to you, there is a good chance you have delegated a lot of your system architecture to small outside teams. You do not need your own data access architect if you are using, say, PostgreSQL.


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.


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.


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!


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.


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.


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.


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?


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.


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.


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


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.


I like that.


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.


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

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.


Probably because the number of people with "software architect" on their business cards greatly outnumber the number of "enterprise software systems that span multiple divisions and locations of an enterprise with 30,000+ people in 100 countries".

It's the 95% of useless bureaucrats that can't tell good working software from a print out of a diagram most developers have a problem with.



This sums it up nicely too: http://bredemeyer.com/


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.


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.


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


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


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.


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.


What do you mean, a silly name? There are lots of different types of engineers, whose skills lie in different places. Some are great at debugging, some are great at algorithms, some are great at plugging together API's, some are great at program architecture.

Those last ones are just called architects, just like there are back-end and front-end and database engineers. What do you have against a name?


In my opinion, an skilled engineer is not necessarily an artist. A great architect is an artist. That why it does makes sense to do the differentiation. And each one will excel at different roles.


HR has taken to calling low-level programmers "engineers" for some silly reason which makes the term meaningless. "Software Architect" is the new term for what used to be called a "Software Engineer", the one person in charge of the design of the whole system. In ten years the ads will probably be calling for "Software Architects" with two years of experience, and we will need another new word to describe the job of the software engineer / architect / ???.


all levels of developer are "skilled engineers". The purpose of having names like junior, senior and so on is to hash into the job title some notion of their experience level.

This might be silly to you, but since you're a mathematician, I am rather surprised the reason for names is not obvious.


>> Those people that, when facing difficult design problems, can often come up with brilliant abstractions. That are so clever, that feel like art.

This folks!


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

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.


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.


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.


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


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.


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


s/Architect/Engineer/g

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


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


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


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.


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


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.


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.


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.


For the arrogant detractors, sometimes a well placed "I fucking told you so" wakes them up like a fresh pot of coffee.


Gloating has the connotation of making others feel bad. "Bragging" is more in line with emphasizing your successes without disparaging others.


btipling raises a valid question, stop down voting and instead post a reply.


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)


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.


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


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


Which is why they're worthless if that's what you have them doing.

I was chief architect for a startup and my job was basically filling in for everyone else wherever I could. I did all the documenting no one had time to do. I took every task I could off of the senior engineers so they could focus on shipping code. I tried to be that guy that had the whole system in my head, meaning I had to watch all the commits, regularly build, run, test and debug the system.

The most typical software architecture work I did was prototyping, but in this case, it was generally evaluating a set of clearly practical options so that we wouldn't waste everyone's time trying to make a decision. Again, this was so that the engineering team could actually get sh!t done instead of arguing about useless technical bikesheds. Any prototype had to be the sort that the developers could directly use as a seed for building the next feature on the backlog.

To me, that's what an architect is about. It's the job that any good senior engineer should be able to do and should absorb, as much as possible, all the crap that keeps those senior engineers from being as productive as possible.


bingo


I've seen the Software Architect role defined in many different ways. Some are the ones you've described, some are "paper only" architects who never code, but theorize to some unknown end.

The ones I've see that are most productive are the ones who more closely match the description in the article. They aren't above anyone, but they are supposed to be some of the most technically knowledgable people in the organization. Too that end, they have some of the most demanding jobs in the group and have to do more and understand more than a Senior Developer, who may only be well versed in one language or have the depth of understanding at all levels of the stack that an architect should.

Architects at my current employer will be called on to write production level code in more than one language, have the charge to watch over the commits and have the responsibly and authority to fix problems they see. They also end up being the janitor sometimes, pulling wires in the server room when the network engineers are short handed. It's a system that works pretty well.


I'm main Architect in my current company now.

And I hate this title - I've seen too many so-called architects who can't distinguish SOAP-call and MQ-message.

Q: You have WebSphere Process Server - do you use BPEL for your scoring workflows?

A: What is BPEL??


I don't think this is for your point, but here's a counter-example: A large company uses 100 widely different technologies, and obviously no one can be an expert or even slightly knowledgeable about all of them. However when you're a SOFTWARE ARCHITECT [oooh!] it seems like there's an expectation that you should be an expert at everything. As soon as you're not (e.g. your example), you're seen as incompetent. In this case there's an unfair expectation.


Of course.

But 100 really widely different technologies is A LOT.

My specialization - telecom industry. I'm dealing with families of technologies and they are not so plentiful. Messaging is messaging, DB is DB, application servers are application servers. Backoffice-frontoffice-mediation-billing remains the same in essence even if you change every component.

I think that I can become good (after 2-3 years) in banking software or manufacturing.

I think it almost impossible for me to become proficient in something like game production, high performance computing, many others


Ouch - this hits a little too close to home being from the architect camp myself (hell - I even spent the last week dicking around with rabbitmq! - talk about coincidence!)

Anyway - as I'm sure other comments will allude to, one of our jobs is to take the time-out from frantically delivering features to investigate new technologies/techniques and distil them in a 5-minutes-or-less style format to the rest of the team. Ideally, organisations should allow all members of the software team to participate in this activity, but it seems that when push comes to shove and clients are waiting for stuff to "get done" this kind of activity is one of the first to fall by the wayside.


Yeah, that's what they all say. Problem is, all the ideas for change come from people who aren't software architects.


ok, now it's obvious you're just trolling.


If someone finds an employer willing to pay them a SA salary for the above job description, there's no way I'd fault them for taking that job and working it for the rest of their careers.


Agreed. But that doesn't mean I have to, like, respect them.


they have to earn your respect by helping you succeed at your job.

you don't have to respect anyone.


I left IBM when I had the chance. You should too. Don't worry, the immediate pay cut is worth it.


No, my company is awesome. They treat us very well. There's just one or two posers who are institutionalized enough to have this job, that's all. They are harmless, really.

Hell, I'm probably just speaking out of envy since I'd totally take the $150k they're (probably) making to dick around with NodeJS or whatever.


I wasn't trying to suggest that IBM is a terrible company. I worked there long enough, and in multiple offices in vastly different parts of the country to know that unless you are over 40 years old and have established your career to the extent you are happy with, finding another company that will give you a better overall experience is more important than waiting around simply because you're comfortable (I was definitely comfortable).


Uh, I was trying to say I work for someone way smaller than IBM and way cooler and who treats their employees way better. The architects aren't really representative of the workplace culture in general.


Sorry - didn't know of many companies that played around with enterprise message queues and had "brown bags"


Are you currently hiring?


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


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.

Why can't your developers lift their heads up? Are they just lazy and don't care, or are they overloaded and discouraged from trying new things by the development process and company structure?


Very interesting perspective. I was a developer for over a decade before my path recently started moving towards architect. I find the opposite in my environment than what you are explaining.

We have so many developers working on different projects that someone needs to suggest/enforce some consistency across implementations otherwise you will have 30 projects, each developed in the favorite technology of each team and face resource problems when it comes time for support and maintenance.

To those with more negative leaning comments I would point out that not all development shops are the same. A software architect at my old 8 person startup would have been silly but I don't see how it would be possible to run development and operations of an airline or major finance company without people in this role.

Some of the systems in large IT organizations are vast and span multiple departments and integrate in many ways with multiple other systems.

The expectation that developers should perform their design/dev/test responsibilities while deciding/enforcing consistency across the organization as well as worrying about vendor contracts and negotiations while simultaneously acting as technology's face to the executive office is in my view an unrealistic expectation.


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


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?


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.


I've been working as a software developer professionally for 20 years and I only came across bloom filters a few weeks ago.


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!


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


Those aren't basic at all, and I'm not sure why the commenter considered them so. As we all know, junior engineers have very limited exposure to a small area of tech, that's the very definition. It might just happen to be that the dev just finished a CS degree and is great at some of these algorithms, but that doesn't translate into a wide spectrum of technologies, which is only found in people with many years experience.

I was the one that actually picked those, just out of thin air to illustrate my point.

This I feel pretty confident that if they were the best solution to a problem I was having, I would find them through research. is exactly my point. How would you know that a bloom filter might be the best solution unless you know of it's existence in the first place. An architect's role is to suggest areas of research to junior engineers, who very likely may only have some vague memory from algorithms class.


It's not about the ability to research alternative approaches, it's knowing when it might make sense to do so.

an "architect" [sic]


> How very cynical indeed.

I got a real kick out of this part, thanks. I'm imagining a scrawny, somewhat aged nerd-type but with a monocle flying off his face. Hilarious.

Anyway, this is pretty much the same thing architects always say, but where I work the ideas for technologies they play with come from "normal" devs like me. Like, RabbitMQ wouldn't even be on their radar unless someone less experienced told them about it.

I know how the "adding value" thing can come off like hard-nosed cowboy coder nonsense. But in truth, we lowly plebeian devs are capable of writing code and keeping apprised of new tech at the same time.


A good architect doesn't pretend to have a monopoly on ideas or trending technologies. Their job is to make sure that the really good ideas aren't ignored and get adopted more broadly.




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: