Software Architect: The Best Job in America
money.cnn.com
money.cnn.com
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.
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.
Incidentally, this is more-or-less the same reason we have architects for real-life buildings.
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.
This will result in an inconsistent mess, most likely.
If your architect is a decent programmer himself and has sufficient experience, then there is no reason why his design should be thrown away.
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.
It will not, when developers have a habit of sitting together and talking thru the architecture they're going to implement.
This, and readiness to throw bad parts away and only let passable ones live.
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.
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 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?
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.
A software architect is usually a senior programmer or computer scientist who makes high level tech decisions.
At least, that's how I have always seen these titles used.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.