4 ms·
From what I've witnessed, it is typically an organizational issue. Let's say there's a site that has some sort of marketplace, and the company wants a better a
by nhashem 14y ago
From what I've witnessed, it is typically an organizational issue. Let's say there's a site that has some sort of marketplace, and the company wants a better algorithm for searching the marketplace because the current algorithm is some crappy substring search. So they hire an architect with some advanced experience on search and tell him, "go figure out something cool that will solve this problem." So far so good.
If you're a developer who works on implementing site features and enhancements, this is what you see. The architect spends the next three months where every meeting his status is "I'm working on the search algorithm." That's all you know that's happening. You assume it's really cool and advanced and it requires his undivided attention, while you continue to juggle managing production issues and implementing new features on the site. Occasionally he has some question about existing search engine, and you show him how it works and due to some painful legacy decisions made earlier, it's pretty embedded in basically everywhere on the site, and everytime he just kind of grunts and scratches his beard and goes back to his desk.
Three months later the project manager taps you on the back and says, "hey, the CEO wants an estimate on how long it's going to take you to implement the architect's new search engine." Erm, okay. So you schedule a meeting with him to see what he has built so far. You don't even know what to expect at this point, since he barely asked you ANYTHING about the existing technology of the company. You're thinking maybe he built some sort of abstracted RESTful service, and hopefully the work on your end will consist mostly of translating direct SQL queries to REST calls.
But, no. Instead you get this HUGE diagram with barely comprehensible terms. Some things immediately jump out to you, like "previous search query terms" is in some sort of cylinder object you assume is supposed to be some sort of database, but you don't actually log the search queries to any database currently. And then there's all these boxes he seems like he just sort of hand-waves, like "baseline linguistic semantic engine," whatever the fuck that means. You ask him about that and he mutters, "oh yes, that is when you compare the search query term for the baseline frequency it occurs compared to the corpus," and this time it's you that grunts, but unfortunately, you don't have a beard you can stroke.
So basically, for you to "implement" this, you're going to need to do a ton of development work building data sources that don't even exist, and then implement his algorithm and find some way to make it robust and scale. So you tell your project manager, "yeah, um, whatever number we're using this quarter for estimating 'story' sizes or whatever, just use the biggest one and double it." And that's the last you hear of it until you're in some meeting a week later with the execs, and someone mentions some problem because the search engine performed suboptimally, and the CEO says, "Wait, I thought the architect already built the solution for that? Why haven't we put it into production yet?" And then you face-desk so hard you break 27 bones in your face and spend the next two years rehabilitating from your reconstructive plastic surgery.
So yes, it's not really the architect's fault. And I actually think architects, with the right skill set and organizational support, can be fantastic. At my last employer there was an architect on my team that was one of my favorite people to ever work with. If an architect is well-integrated with the team, and can work with them to actually develop what he's working on in tandem with reality and determine the right levels of abstraction, then they can be a great resource for a software team. Every time there was some feature request that made us think, "man, we're gonna need some PhD shit for that," our architect would ride to the rescue and figure out some way to solve it that was very advanced but still completely practical given the constraints of everything else, on top of providing general mentorship and design advice.
Architects can get a bad rap and in the example I just described, it's not really their fault. But, it's probably not worth continuing to pay them $250,000 to design completely impractical algorithms nobody can realistically implement, including themselves, either.
- gcb 14y agoNice try, architect ;) Now seriously, if you are a kick ass developer, in any company the size of Yahoo you can only get a decent pay if your title is architect. There's no other way to get to upper salary ranges. Either that or manager. And 200k is not that crazy in San Francisco or socal. Heck, 75 and you can barely support a suburban family. Now, the real problem is management, or better: performance review and promotions. In a corp that size, it doesn't matter if you save 1mi a month in infrastructure costs with a months work. No. You have to come up with a nice project name and make it sound complex and big. Nobody remembers to look at outcome in performance meetings. They focus on projects and shenanigans. So, keep the architects, tell them they can simply work instead of coming up with projects names, and fire the middle management... I thought that was common sense. Whats happening with the world?
- kamaal 14y ago>>So yes, it's not really the architect's fault. And I actually think architects, with the right skill set and organizational support, can be fantastic. Sorry, this looks like the same line of talk used to defend MBA's. And 'Architect' titled are basically MBA equivalents of the programming world. They want to manage things they can't do or understand too well in deep. If you can't write code, you basically can't design large software that requires tons of code to be written. Architecture isn't merely black boxes represented as classes interacting with each other. If you are an architect you should be able to write code which you can use to do prototypes, or demonstrate a proof of concept, or verify what somebody else is trying to show you, or you would like to show them. You should be able to point out bottle necks, pain points in large software code bases and correct them. You should know how to refactor and all other best practices in software world. UML/Black box diagram only architects, aren't architects.
- codeonfire 14y agoThe architects and MBAs will counter by blathering something about siloing, antisocialism, poor communication skills, and anything else that will attempt to disparage and marginalize people who strive to understand things at all levels including the very deepest. Some people are insane about this. I've heard some messed up things like academic advisors telling me to avoid computer science professors because they are 'hard to talk to.' Asimov's "my ignorance is just as good as your knowledge" anti-intellectualism is really horrifying to behold and will be used against people who strive to know the high level and the bare metal. There is really no defense against this career-wise either except to get out in the open market where it's just you and your knowledge against the idea guys and their talk. In most organizations the idea guys like you describe will posse up because they have to.