>> it breaks Agile

It must be "nice" working with an enterprise architect who views agile as a strict, narrowly defined thing.

He's really sharp and has keen insight into how enterprise business works. His advice saves us a lot of time and money.

But if he wants you to open tech debt tickets, rather than spotting/fixing security issues immediately, this will not save the company time or money.

He doesn't. He was just describing to me the way the enterprise usually sees things. Our shop is more modern than he's used to working in.

His logic would apply to tests of all sorts. As long as the dev says the feature is done, that’s the end. And he’s wrong. As teams (or companies, or whatever unit) we get to decide our definition of “Done”. I suggest that definition include appropriate testing. And appropriate code review, which serves two purposes… catching defects and knowledge sharing.

In his world, testing the software belongs to a different team than the implementation. Differently managed, differently staffed. Not with engineers, but with testers. It's difficult to say the least to move from testing into engineering

And you can't just redefine Agile like that. It's the businesses' money, culture, and productive means. Not yours. If they want teetering software stacks with no thought given to maintainability, managed by non-tech-savvy staff, then that's what their money will buy.

We enjoy an environment catering to our needs because our orgs can afford to throw a lot more resources at better managers and better talent. As a result individual contributors can contribute not just tickets, but also to help improve the way we work. Not possible in heavily top-down org structures.

Ugh. I haven’t worked with an independent QA team in 15 years or so; testing is the responsibility of the dev team and there are test engineers on each team to facilitate that.

Maybe this is a difference of building a product vs contracting? We have to keep what we build running for years; there is no turnover to a client where can declare the system “done”.

As for redefining agile, I’ve done no such thing. The agile manifesto calls for working software. It calls for collaboration. Avoiding knowledge sharing amongst team members and throwing software over the fence to a remote test team are both counter to that goal (in my experience).

In my experience, splitting the testing team out of development materializes refactoring as costly.

"What parts of the system did this impact?"

"Well, this is a core piece of our ORM config, so... the entire data layer, so from a functional perspective this change impacts every part of the system"

"Then you're not changing it, QA can't rerun all their old tests, it would take months, most of those tests don't even work anymore".

End result: refactoring never happens. Get it right the first time.

Naturally. In an Agile environment it's more or less impossible to get it right the first time without seriously forward-thinking architecture, which takes time that could be spent pushing harder towards the deadline.

It's a business decision to organize software production this way. Refactoring and ease of software maintenance are quality of life issues for engineers. Not business concerns.

That's how a managerial bureaucracy approaches the problem of deadlines: The second it looks like it's working, mark it done and move to the next task, and deal with the bugs later - ideally the manager will move to another position by then due to their exceptional productivity in meeting the set goals, and the bugs will be someone else's problem to solve...

If they get solved at all.

Microsoft famously called that process “infinite defects methodology”, and decided it was a bad idea in 1989. "In general, the longer you wait before fixing a bug, the costlier (in time and money) it is to fix."

https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...

Anyone with Architect in their title receives skepticism from me. I've turned down title changes that include it and I refuse to put it on my LinkedIn.

I think that attitude is a little short-sighted, and perhaps a little bit of "anyone that isn't a pure developer is incompetent" elitism.

For one thing, titles are just titles, and they stick around for historic reasons. For example, there really isn't a great reason for companies to call people DevOps Engineer, but it still happens.

I'll take the Solutions Architect role as an example. It's basically sales or customer-oriented developer or technical resource that works with customers to determine what a solution to a problem will look like. "Architect" is mostly meaningless in the sense that Solutions Architects don't really architect much of anything. Usually, they just come up with a plausible path forward and visualize that solution to all the stakeholders involved. This includes travel to customer sites, something that developers are basically never willing or expected to do.

They're the folks who deal with the god damn customers so the engineers don't have to. They have people skills, they're good at dealing with people. Yeah, I mean, considering the staff engineer on my team does not shower, there is value in that role.

Most of the value in the Solutions Architect is how they're able to work with customers to discover their needs on a more technical level rather than at a high level. Once the plan is determined, the solutions architects don't actually build the solution on their own, they're more like an interface or leader to the development team that builds the solution.

https://www.careerexplorer.com/careers/solution-architect/

I don't want to put words into your mouth, but maybe you're skeptical of "architects" because they aren't typically expert specialists in one small area. Maybe that's why you don't want to be associate with them. Understandable, perhaps, but don't be misguided into thinking that "architects" aren't skilled professionals who add value to the company.

On top of that, I believe they're often paid higher than developers ;-)

His world seemed completely and utterly divorced from mine. He was deeply connected with big enterprises and how they manage to meet business objectives regardless of not being software engineers themselves. In our world, we take for granted that our managers and leadership are technically proficient. In his, the "Engineering Manager" is a rarity, the people managing engineers are just ordinary managers.

Software architecture, in this world, is how you escape the rat race of soulless ticket punching without having to go into management. You use your skills and experience in an advisory role. Obviously there are better or worse architects, I've had the pleasure of working with really good ones. But it often feels like a title and field borne out of a need to retain top talent. (read, not push them away to competitors)

Even people designing buildings?