[cmhnn]

If the argument the blog is trying to make is Architects can't know everything then it's a bad article to submit.

On the other hand, if the argument is a boss should not expect someone called Architect or senior engineer etc. to be able to troubleshoot based on experience I have a problem with that.

If someone can't be air dropped and they have a title that is intended by the business as code for a senior level software person who can think of how to build systems and can also build them themselves, then I am not sure what they bring to the table.

[_y5hn]

This is the problem with development for, forever. Most of the time, people are tasked with: Here's the spec/user story/loose idea/unrealistic wishlist, and can you be done before this weekend at least?

What's the problem again? The facilitation of foundational discussions and exploration is seen as waste. So the business spends X months building the wrong idea, without any feedback and adjustments along the way whatsoever instead.

To air-drop someone senior to set things straight. What a great way to sabotage organisational learning and simplification. Not that anybody gives a rats ass about eachother anyways, right?

[cmhnn]

There are a lot of problems in the industry but the experienced helping the inexperienced on demand in response to a crisis doesn't seem like one that is nearly as serious as others.

I am old enough to have been on XP teams and to have become a certified scrum master in its first few years. It's gotten out of hand. Being agile and blasting to an MVP is fine for people who think Netflix or sending dick picks is mission critical but with IOT and AI scenarios emerging that allow all the little software napoleans to fuck up something serious or inadvertently create a universal spying machine it might be time to put the breaks on for at least a class of problems.

No industry hates old people as much as tech and that industry has people all over it like an idiot on another thread who clearly had no idea who Brian Kernighan was when they wrote their post. Young programmers have always been arrogant idiots. I was one myself. But it astounds me that many programmers today don't even know a ton of stuff that would make their job easier since it is shit that is already figured out or is shit the science says can't be figured out.

I hate people that wallow in history as much as the next person with an ounce of inclination to independent thought but for fucks sake learn some basics before applying that code golf to 20,000 cores because that shit costs money you free food demanding little jack ass.

As for building what the customers need or want? The more time I spend around programmers the less inclined I am to want them deciding anything for anyone in terms of features.

If you're blessed enough to be great at programming and picking things people actually want or need then you'll be too rich soon to bother with stuff like being told to help a team fix their shit anyways.

[_y5hn]

I don't know about hate, but each man an island was the tone set by top owners and executives since 1999.

Dev is hard enough, but the demands of divisive process micromanagement just creates heroes and firefighters, and sets up org for continual failure.

While endless backlogs and mitigations documents processes, creative collaborative progress nosedives.

Majority of devs need facilitation though. No history of otherwise, but perhaps a silo issue.

Drop-ins can be natural, but not so much as upfront restrictions-planning outside teams.

[cmhnn]

I think you are saying you want the industry to be better. I support that. But until we get there, the need for people who can airdrop is going to be there. Sometimes you may be dealing with a fortune 50 like customer with lots of $$$ in play or a smaller customer who needs to get something running or they are in deep trouble of going under. It's not so much about looking inwards sometimes as it is about helping customers who depend on the crap that was built to get past the bugfest the industry seems comfortable selling all to often.

[tomrod]

Senior/Architect level here. This. And, much of the time, the architect's drop-in approach has been considered and rejected by management already. Sometimes for good reason, sometimes not.

[oaiey]

The reason is most of the time not that the manager expect the architects to solve the problem but to get a clear picture from someone they trust, communicate it management friendly and then make the tough decision the developers are often afraid to do or to sell their managers.

There is no problem solving in these situation. Just assessments and peer reviewing of the stuff the developers do.

At least this is my stake on this situation.