Hacker News Reader

Comment by MattRogish | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com