I think software architects are a company anti-pattern. It seems like such a good idea, one or two big brains putting the whole system together, then a pile of cheaper code monkeys doing the implementation.
On my experience, what you actually get is your one or two "big brains" doing little to no work. They go to lots of conferences, are in a lot of meetings, derail almost all useful conversation, and maybe occasionally produce a UML diagram. The plebes responsible for actually building the system typically throw away the architect's design immediately, because while it's a beautiful, pure design, it doesn't take into account being deployed, running and being supported in the real world. The code monkeys then build a deeply flawed system, but it ships and works.
But at least the architect is great to have beers with during the Friday happy hour.
Skip the architects, make the monkeys do the design. Have them vet it with each other, preferably in a formal setting with your entire engineering team. Everyone codes, and everyone architects.
There is a thing called "a coding architect". It basically means that you're a programmer just like any other, but you have more responsibility on the overall architecture of the project.
Sure, I've seen plenty of these "documentation architects" who don't produce that much value, but that's not the only type of architect out there.
Not a unicorn as one might think. Most of senior stuff in our consultancy shop ware software architect hat at very beginning of software project, and later on do fair share of coding, mostly critical stuff.
At the company I work for, they strive to hire this role (which is what I do). "Architects who code". Definitely the way to go. As a software consultant, I should also note that I have worked with a number of Architects who don't code, and in every case, they took away more than they added.
If you let the monkeys do the design, you get shit on the walls.
Why? Because software systems really do only want one guiding vision for how they are implemented and work--and that's really hard to accomplish when you design by committee.
The monkeys, while they do probably have an eye for things that make little patch jobs easier, are not probably doing global optimization. That's why you end up with elaborate mechanisms for the moral equivalent of pushing a button, when that button should never exist in the first place.
The vast majority of developers are not good at creating coherent, simple systems--a good architect is.
There are a lot of bad people out there failing at this job, but the cost of letting the system develop piecemeal is a great way to put a hard cap on company growth.
Yeah, I really don't like the monkey analogy, but setting that aside for a second, this is exactly why "software architects" exist--good design requires cohesive vision, and that's almost impossible to accomplish when designing by committee. (I have seen it work well, but only with people that had been working together happily for a long time, often with a few design failures before hitting their stride.)
Incidentally, this is more-or-less the same reason we have architects for real-life buildings.
"If you let the monkeys do the design, you get shit on the walls."
Marvellous, this would make a great poster :-)
I also agree: bad architects, per se, isn't a flaw with the architect role itself. Central design, guidance and oversight seems to me pretty much a vital thing in any large-ish system.
That the individual needs to be suitably skilled technically and personality-wise for this to all work well goes without saying.
I have never worked with a System Architect that was more qualified to design the system than the developers were. Inevitably, they design a system that looks good on paper, but is full of moving parts, anyone of which can fail.
It reminds of that children's game, Mouse Trap. It seems like it's going to be really fun to start the ball rolling, but inevitable some part of the paths fails. The guy doesn't fall into the bathtub, the trap gets stuck at the top, etc. In system terms, that means someone's pager is going off at 2am.
In my massive company's IT org, there is a specific architect role and they do everything wrong that you could think of with slowing work down, being disengaged etc.
But in the actual engineering side of the business the software engineer groups are not labeled as such except maybe within a team. Everyone is a software engineer and the level 4 or 5 SWE simply makes design decisions. They review code, optimize stuff, rip things apart, sometimes end up trashing it all, never commit anything, etc. But if they find some major change that needs to happen THEN it flows down for us to implement and commit.
Works incredibly well. But this is at a lower level... say a team of 5-10 people.
I wasn't expecting a full page of hate against architects.
I worked with bad ones, I worked with good ones, but seems the majority is just against the whole concept of centralizing responsibility.
Most common reason I see cited is disengagement and increase in workload because their arbitrary decisions.
What's the opinion on CTOs? The startup culture around here seems to keep those in better consideration, but are they really that different in responsibilities?
This depends on the company processes, business-level goals and challenges, and available resources.
UML
Fuzzy pictures of boxes and arrows. - Leslie Lamport
Unnecessary Management Lingo. - @iamdevloper
A language that was invented first and then people came around to try to get semantics. - Leslie Lamport
...
As usual, I think Lamport gets to the heart of the problem. Expressing things in an imprecise way can be of limited or even negative utility when it comes to actually nailing down code. However, a whole lot of decisions that need to be made in organizations that produce or employ hardware and software systems require knowledge, experience and communication outside of actual system design or selection.
Skip the architects, make the monkeys do the design. Have them vet it with each other, preferably in a formal setting with your entire engineering team. Everyone codes, and everyone architects.
This works if your people have experience and communicate well. Other times, not, like this example I had in London. CTO: "solve X really-stupid problem that my poor architecture that is not accepting of feedback created". Me: "OK, literally just-hired (some are first coding job ever!) type team: 'X is problem, Y is timeframe, Z is general proposed solution in data-oriented terms [always a good start], feedback?'" Result: Shit on walls, followed by gentle coaxing 'here's how to achieve Z, lets do it' and lots of babysitting. We got there, with just a little overtime, averted disaster on the high-penalty very large client contract, and still had time for beer. Conclusion: Guidance is useful, sometimes.
The job title used to be 'systems analyst'. And that job was fairly essential to getting a large system with a lot of moving parts to work together as a whole. For projects of a certain size someone needs to have the higher level overview.
Now, plenty of those calling themselves 'software architects' could not code if their life depended on it, but as an alternative to being put out to pasture analysts tended to be a bit older and a bit more knowledgeable than us 'code monkeys' as you put it, but I learned more from those analysts than I did from my pears about proper software design.
I agree from my experience, especially with open source, that you need a person (or rarely, a junta) applying architecture.
But if that person isn't _also_ one of the coders, getting their hands dirty, their architecture will be no good.
Recently someone linked on HN to a study of succesful open source projects, that found that even the most successful ones only had few -- or often one -- person making most of the commits.
My interpretation of those findings is that it's representing this state of affairs. Although I think there's probably a way to preserve the benefits of a strong hand on architecture without having that person making all/most of the commits -- but they've got to be making some of them, to ground their plans.
As a code monkey myself, I feel your frustration. But I think we tend to undervalue the importance of those "Friday beers". We are selling technical products to non-technical people. People that need to achieve old fashioned trust with someone that seems to be in charge.
If we can be as good at those social relationships as the idiots currently doing it, maybe we can grab some of that power. How to do it? I don't know, but if we're so smart, we should be able to figure it out. I believe we can.
I think we've all been somewhere that had a laughably incompetent "architect". I can think of at least 3 in my own relatively short career, at three different firms. The rest I would describe as... harmless?
And yet I can see the value of having a strong leader in this role, especially on large-scale enterprise projects and similar.
My own limited experiences and the countless anecdotal similar experiences I've read on HN, etc. over the years raises the question of how some of these people get hired. I assume it's because architects are hired by C-level executives and managers, not technical staff. Probably lots of odd coincidences where everyone used to work at the same place...
But I can promise you this: if I am ever invited to sit in on the interview for an architect, those candidates will get nothing but questions about the fundamentals of networking and development from me.
> My own limited experiences and the countless anecdotal similar experiences I've read on HN, etc. over the years raises the question of how some of these people get hired.
I think I clued in to part of that a couple of weeks ago: they tell management what management wants to hear in a language that management understands. This sort of rapport leads to a completely misplaced trust and the associated trainwrecks make for interesting projects from a recovery point of view.
In a nutshell: it's all people and psychology and being antagonistic will more often than not cause you to be ignored, even if you're right and so the bozos get to have their run.
I've noticed the same thing. Management tends to be older white men with MBAs and there's a big culture divide between them and the developers who control their destiny. So what do they do? They go hire a guy about their age with a CS degree and an MBA to be the trusted representative and they pay him more than any developer. It doesn't just happen in software either, I've seen the same thing with biologists at bio tech companies. Some brand new white baby boomer ends up in charge of the biology team that's been there for years all because the white baby boomer boss doesn't want to handle the mostly female and non-white employees.
You always see this at the top of every list of this general ilk. For me, it's true. I do it and I love it. But when I look around the office at my co-workers, I honestly believe 70-80% of people would either just abhor it or be terrible at it. Even though they might complain about it, they love meetings. Love them so much. They get out of a meeting and genuinely feel like they did something productive. These people would be deeply unhappy if they were yanked out of the candyland where having meetings and opinions was what they were responsible for and suddenly were told "Now you have to do something tangible to earn a living." ... In the same way I would be deeply unhappy if I were told I had to go to meetings all day. The point is, this probably is the best job... but not for a lot of people. So it seems misplaced at the top of all these lists.
As a developer, "meetings" and "expressing opinions" is exactly how I picture a software architect's job.
I'm not saying that in a diminutive way, I actually think that interpersonal communication and group work are very important in any human endeavour.
There is usually a fair bit of prototyping work involved as well. There's also a lot of listening involved, as you can't really design a good system without first talking to the people who are going to use the system and understanding their needs. In addition you'll need to listen to the folks who are going to be implementing the system as well so you get a feel for what they are good at and what they enjoy working on.
What I thought was hilarious is that the #2 job, Video Game Designer, had a "Low Stress" rating of A.
It's almost like CNN doesn't know how much gamers hate the people that make games. I would never go back to the video game industry without protections in place to keep ragey gamers from swatting my house, sending death threats my way, or so forth.
It is an unfashionable role right now in good software development organizations. I used to go by the title but tend not to anymore.
Nevertheless, there is still a need for that role in large organizations whether they are called that or not. A typical project or product at a large company has many people over multiple sites involved and/or significantly affected by the project.
Someone with enough technical depth needs to coordinate, make decisions, and be accountable for the overall technical cohesion.
Most developers either aren't interested in spending their time on that or aren't good at it. The ones that are end up playing the role of architect. If they don't have the authority to back it up, either by reputation or granted by title, they will get nowhere when they try to convince other groups all work towards the same vision.
Agree. It is unfashionable, but in the long run, having a unified technical vision for your product breaks down silos and makes products easy to maintain.
Here's the problems I've had with this position:
1) Not innovating. Basically you decided 10 years ago to use Java 1.4.2 and by golly it was good enough then it's good enough now. You have to rock the boat occasionally. And yes, your applications should require a rewrite every 3-5 years.
2) I've worked with too many people that were promoted into the role by time at the job, instead of skill, which is the real anti-pattern.
3) They "don't code." This is ridiculous. Eat your own dog food. If you can't code faster/better than the engineers underneath you, you need to be replaced.
The best architect I've worked with was previously a developer and then developer lead. He kept current with new technologies, development principles/tools and frameworks that were relevant to our stack. He helped with development occasionally and was pretty much the go-to guy for not being able to come to a solution on our own.
Without a deep understanding of the moving parts of your systems, I don't think an architect can be very useful outside of taking meeting time from the development team. They're great for handling bureaucracy in a large environment, however a lot of that role can be done by your manager or their manager.
Unfortunately handling bureaucracy isn't very high on the list of job satisfaction of someone who's role is in draught, he moved onto greener pastures shortly after I signed up.
Honest questions: How to become software architect? What are the relevant qualifications/industry standards? Can any current or past architects on HN share their life experiences? Thanks.
1) Read (a lot) and absorb quality writing on software development. For example Pragmatic Programmer, Code Complete, Designing Hard Software, SICP...
2) Create software (for about 10 years at least) for fun and profit. Assume others must read and understand your code. Write it for them. Also love the code you write. Find the beauty in solving problems elegantly and simply. You'll learn a lot.
3) Teach others how to create high-quality software, most especially focusing on "why". This keeps you thinking about what you're doing and leads to you finding ways to improve.
4) Listen and evaluate honestly when others criticize your choices. Maybe you did do it wrong or you don't have the whole picture. Have strong opinions, weakly held.
5) Repeat.
These aren't qualifications so much as guidelines for when people ask me how I got "so good." My title has been "Software Architect" for the last twelve years.
There's a lot more to it, naturally. Your biggest job as an architect is to extend the reach of the entire development team. Be it by writing libraries and frameworks for the project, mentoring developers, or creating designs and guidelines for developers to work within. Like a building architect, you are responsible for crafting and engineering the space in which people will live and work. For a software architect those people are the users, the developers, and the stakeholders. Your job is to strike the right balance between the three groups.
The reason you see so many posts in this thread deriding software architects is that as an industry we have largely forgotten what software architecture is. B-School and CIO Magazine have been selling executives on out-sourcing so that they don't have to "worry" about that kind of thing (and we're just now recovering from this). Capital "A" Agile came along and sold them another bill-of-goods that doing Scrum would fix all the issues.
For these and other reasons, the title basically came to mean "really good programmer" and was handed out as a simple promotion. But the real software architects are never just that. When doing their job properly, they become the foundation for excellent software development teams, and for excellent software.
Software architects are developers in a past life who don't want to do any real work anymore. They never really liked coding and they're certainly not getting their hands dirty.
That's like saying developers are people who write buggy software for job security. All they like to do is play around with the latest toys and they always make the project late. Those are bad developers.
Good software architects make the entire team more productive, the entire product (or family of products) more cohesive, and make future change easier.
"Benefit to society" whats that all about? Landman and Patent Agent get A's for benefiting society. From what I can see anything software related gets B or less.
Top 10 something lists are far from exact. Second best job in this list is 'game designer'. Obviously this list ignores overtimes, job stability, living cost etc.
On my experience, what you actually get is your one or two "big brains" doing little to no work. They go to lots of conferences, are in a lot of meetings, derail almost all useful conversation, and maybe occasionally produce a UML diagram. The plebes responsible for actually building the system typically throw away the architect's design immediately, because while it's a beautiful, pure design, it doesn't take into account being deployed, running and being supported in the real world. The code monkeys then build a deeply flawed system, but it ships and works.
But at least the architect is great to have beers with during the Friday happy hour.
Skip the architects, make the monkeys do the design. Have them vet it with each other, preferably in a formal setting with your entire engineering team. Everyone codes, and everyone architects.