The best "architects" serve as facilitators, rather than deciding themselves how software is built. They have to be reading the code, but they don't themselves have to be coding to be effective.
You don't need one until you've got 30-70 engineers, but a strong group of collaborative architects is the most important thing for keeping software development effective and efficient at the 30-1,000 engineer range.
This is where an architect is useful, because they can ask "why?"
Sometimes there is a reason!
Sometimes there isn't a reason, but it might be something we want to move everything over to if it works well and will rip out if it doesn't.
Sometimes it's just someone who believes that functional programming is Objectively Better, and those are when an architect can say "nope, you don't get to be anti-social."
The best architects will identify some hairy problem that would benefit from those skills and get management to point the engineer in that direction instead.
A system that requires homogeneity to function is limited in the kinds of problems it can solve well. But that shouldn't be an excuse to ignore our coworkers (or the other teams: I've recently been seeing cowboy teams be an even bigger problem than cowboy coders.)
Why are you rewriting the same application a second time?
I've personally yet to have a situation where that comes up. And every application I've ever worked on has its architecture evolve over time, as behavior changes and new domain concepts are identified.
There are recurring patterns (one might even call them Design Patterns), but by the time we've internalized them we have even less need for up-front planning. Why write the doc when you can just implement the code?
XP putting a customer on the team was the best thing in the methodology. Replacing those with business representatives is one of Scrum's original sins.
> XP putting a customer on the team was the best thing in the methodology.
Recently my boss said to me: "Customers want something that WORKS. If you deliver something, and it doesn't work, what's the customer going to think?" The huge drawback to putting a customer on the team is that the customer probably doesn't want to know, let alone be involved with, how the sausage is made. They want a turnkey solution unveiled to them on the delivery date, all ready to go, with no effort on their part.
Generally what you want is a customer proxy in that role, who knows or can articulate what the customer needs better than the customer themselves can. Steve Jobs was a fantastic example of someone who filled this role.
It's also worth noting that a customer is not necessarily a user. As a developer I don't care so much about the customer but I care wholeheartedly about the users.
The problem isn't programmers: it is cheap-ass executives obsessed with compliance.
Good software designers are facilitators. They don't tell people how to build software, but say "not like that" by making the technical requirements clear. They enable design to constantly change as the needs change.
It has been a long time since I've been at a company willing to actually employ someone in that roll. They require that their most senior engineers be focused on writing code themselves, at the expense of the team and skill-building necessary for quality software.
Instead we get bullshit like "team topologies" or frameworks that are more about how the company wants to manage teams than they are about how well the software works. We get "design documents" that are considered more important than working code. Even the senior engineers that are around aren't allowed to say "no" if it is going to interfere with some junior project manager's imagined deadline.
Software companies are penny-wise and pound foolish, resulting in shittastic spaghetti messes with microservice meatballs.
I have seen issues like that. Rebooting has always fixed it, but it is notable.
I really wish they would hire a strong frontend team. I can almost always figure out what happened just from the signal, and it's usually a state machine getting stuck. Which I have some sympathy for, but also you just can't have that happen in something that is going to feel polished and responsive.
HP did write their own operating system: HP RTE. It wasn't until decades later, after the platform became commodified and they stopped designing their own chips, that they went with someone else's.
And of course, Microsoft made their own cards back in the day, and they still make the XBox as integrated hardware.
This technology is way too early for commodification. Right now, Rivian is a data play.
Their platform means they have consistency other providers don't have. They have data from the existing trucks on the road, and they'll roll out these sensors long before they roll out self-driving. Cleverly they've also pitched these as "adventure" vehicles, which means they'll have some data from rarer situations, not just highways. Off-road performance, for example, will add anomalies that they can use to stress-test self-driving code. If a car could handle areas without roads, it is less likely to kill people if a mudslide happens. Or a shadow falls across the bridge.
It is nice to see a car company investing in a sensor platform that could actually safely self-drive.
It is unfortunate that the existing market participants seem hell-bent on destroying consumer confidence in self-driving before this will make it to market.
We desperately need a safety regimen for self-driving cars that takes it as seriously as airplane safety.
How many hours have you spent with the latest Tesla FSD in congested neighborhoods or unprotected left turns at sunset? It may be "good," but it's not even remotely close to the current Waymo experience, especially when it comes to abnormal situations. I am continually blown away by how Waymo behaves (spent 3 hours in them this past week). I'm rooting for Tesla, but it is nowhere near Waymo as of today.
You don't need one until you've got 30-70 engineers, but a strong group of collaborative architects is the most important thing for keeping software development effective and efficient at the 30-1,000 engineer range.