Hacker News Reader

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.

A coding architect sounds like a great idea. I'd love to meet one and hire them.

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.

This is pretty much the definition of "senior developer" at my company. I didn't know that was abnormal.

Yeah, It's pretty much the definition of what I do every day.

That sounds like a regular lead developer, but I agree a good lead dev is worth more than any software architect.

So, let's take the other side of this.

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?

software architects are a company anti-pattern

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.

A systems analyst is (usually) someone who is only semi technical and functions as a bridge between management , customers and technical people.

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.

> Everyone codes, and everyone architects.

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.

In my professional experience I've met architects that don't code, or even remember how. Very sad.

Even worse, in my experience I've yet to meet an architect who does know how to code.

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.

Yes, I hinted at that. The architect should also code on the same project. Or at least read the code of that project.

> This will result in an inconsistent mess

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.

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.