[nullorempty]

> You can't design software you don't work on

In 30 years in software dev, I am yet to see any significant, detailed and consistent effort to be extended into design and architecture. Most architects do not design, do not architect.

Senior devs design and architect and then take their design to the architects for *feedback and approvals*.

These senior devs make designs for features and only account for code and systems they've been exposed to.

With an average employment term of 2 years most are exposed to a small cut of the system, which affects the depth and correctness of their design.

And architects mostly approve, sometimes I think without even reading the docs.

At most, you can expect the architects to give generic advice and throw a few buzzwords.

At large, they feel comfortable and secure in their positions and mostly don't give a shit!

[WillAdams]

John Ousterhout has been addressing this one class at a time at Stanford for a while now, and has scaled up to a book:

https://www.goodreads.com/en/book/show/39996759-a-philosophy...

Video overview at:

https://www.youtube.com/watch?v=bmSAYlu0NcY

[octorian]

The last time I worked on a project that actually had all these roles, "architect" basically meant someone who sat in meetings all day and played very little role in the actual software development of the project.

There were plenty of times where it would have been useful to have someone providing real architecture/design guidance, but no such person functionally existed.

[rvba]

There are those comedians who talk with people in IT (mostly various types of roasts). People laugh, but it is incredibly sad that for example someone from the Android team does not use an android phone for a daily driver.

Microsoft had a lot of sins, but at least they asked the coders to eat own dogfood.

Also the "2 year coding wizards" that you described usually dont live up to see the results (or rather: disasters) of their decisions + they dont have to maintain their own code.

[MomsAVoxell]

>Eat your own dog food

The end.

[makeitdouble]

> 2 years

I've been thinking about this a lot. 2~3 years is a long time, long enough to have a pretty good grasp on what a code maintained by 50~100 does in pretty concrete terms, come up with decent improvement ideas, and see at least one or two structural ideas hit production.

If the person then stays 1 or 2 more years they get a chance to further refine, but usually will be moved up the ladder Peter Principle style. If they get a chance to lead these architecture changes that company has a chance to be on a decent path technally speaking.

I'm totally with you on the gist of it: architects will usually be a central switch arranging these ideas coming from more knowledgeable places. In the best terms I see their role as guaranteeing consistency and making sure teams don't impede each other's designs.

[mmis1000]

> 2 years

I feel it's already enough to rewrite a big part of subsystem or change the whole thing into shit (depends on maintainer).

Software today moves quite fast. 2 year is sometimes difference between a new company and a dead company