[btilly]

In other words you're saying that "software architect" exists as a role in these organizations because bad organizational structures create problems that it is a band-aid for.

And I'm saying that the band-aid doesn't work that well, and you do better if you fix the organizational structure to not need it. And furthermore, as a developer, those organizations are no fun to be in and you can't pay me enough to want to deal with them. Particularly not when I have the option of finding better organizations to be in.

Which adds to the problem. When good developers choose not to be in your company because your company is a disaster for developers, you don't get good developers. Which reinforces the idea that developers aren't that good, and causes them to try to put guard-rails around developers to prevent the problems that bad ones cause. Thereby creating a negative reinforcement cycle.

[tguvot]

Good point, architect is indeed compensating function that comes to cover for many deficiencies in organization. Those deficiencies are:

. Developers that are mature but lack proficiency because they don't care about software development

. Inexperienced developers that lack, well, experience to make proper designs

. Absence of domain specific knowledge when company tries to shift it's technological gears or switch to new domain/market all together

. Problems in communication and planning between dozens of teams/services that build together 1 product that must work in unison perfectly, yet it's hard for each team to know architecture/plans of all of the other teams and properly consider it during development

. Absence of ability to see "the big picture" by individual teams and take it properly into consideration

. Just a general jack of all trades that will compensate for bad product/project/program management, will establish proper processes, etc.

As part of this you occasionally can revamp organizational structure and leave company in much better shape, but it requires a lot of work that you, as architect have no authority to do :)

> And furthermore, as a developer, those organizations are no fun to be in and you can't pay me enough to want to deal with them

One of my last jobs was in company that I literally sweared to never work for. They gave me a shiny title, 50% raise of already top salary in industry that I had, yet what really sealed the deal was manager who wanted to try to do something new. Even though it was at times horror show, at the end of the day it was probably most fulfilling position that I had due to a sheer volume of things that I managed to change. And we also delivered totally new product, first in industry beating all the competition to market, including companies that were supposed to be market leaders in this area.

>Which adds to the problem. When good developers choose not to be in your company because your company is a disaster for developers, you don't get good developers.

The issue is that really good developers are rare. Developers that you can delegate to them and sleep well at night are a rare commodity on the market. I been working in dev for 25 years, both in startups and in established companies and I maybe know only dozen of people like this. Unfortunately, most of the developers on the market are in it only for money and don't really care about what they are doing.

Also, as anecdote, at this ^ job place that I described, in order to work around bad reputation of the company I suggested to create daughter company with a different name that will be operated independently in a different location in order to try to get better developers. We were a few steps away from closing on office lease before management bailed out because they were afraid that it will upset employees of the company

[btilly]

To the deficiencies that you list, I have to say that your organizational structure can create better developers, or make them worse. Delegating all responsibility for the bigger picture to architects and hiding developers from those issues will make them worse. On the reverse, I admit that not every developer can learn to do architecture well. But when you enable developers to take those responsibilities, the ones who are capable of it will step up.

My rule of thumb for developers goes like this. I mentally divide developers into junior, mid-level and senior. This has nothing to do with their titles. The breakdown is that a junior developer is still learning basic programming consistency and good habits. They generally struggle on programs that go over a couple of thousand lines. A mid-level developer has internalized consistency but is unable to remain aware of the big picture while focusing on details. They tend to top out and struggle at 10k-20k line projects. A senior developer is aware of the big picture while dealing with details, and remembers details while dealing with the big picture. They tend to top out around 200k line projects. And a principal software engineer adds an awareness of subtleties about how the big picture is likely to evolve, and how to guide that in a long-term positive way. These people can manage architectures in the millions of lines.

On this scale, I rate myself senior. To move to the next level, I'd need to spend more time at large companies with very large codebases. But dealing with the associated politics is not my preference so I'm happy where I am.

The issue is that really good developers are rare. Developers that you can delegate to them and sleep well at night are a rare commodity on the market. I been working in dev for 25 years, both in startups and in established companies and I maybe know only dozen of people like this.

Judging by what I saw of environments with software architects as a role, I guess I shouldn't be surprised at this.

However I know a heck of a lot more than a dozen programmers that I consider good like that. OK, throw out top-notch organizations like Google, and just go for relatively small companies that I've worked at. Let's narrow it farther and just do places that I've worked in the last 10 years. I still have no problem getting past a dozen.

Why? Because I choose to work at organizations where software architecture is owned by developers. With other developers who have made the same choice.

(Incidentally, 3 of those programmers were co-founders at ZipRecruiter. Who hired a lot of mutual acquaintances on my list, then grew to be a billion dollar company. Somehow I don't think that this is coincidence.)

[tguvot]

I most definitely enable developers to take responsibilities. I don't want to do more then what I need to do. I also prefer to help developers grow and take more responsibility, as it makes my life easier.

BTW, principal software engineer in many places == architect. Titles are very country dependent, company dependent. When startup where I worked was bought by US company I became principal. When I was acquired by German, I was retitled... don't even remember to what.

>Judging by what I saw of environments with software architects as a role, I guess I shouldn't be surprised at this.

I wasn't always working in companies that had this title. Yet, this still remains true. Also we may have different standards and operate in different environment on different types of products :)