You are incentivized to build grand, complex systems which will look good when you want to do a talk at an O'Reilly conference - which is exactly what winds up happening.
You are incentivized to build grand, complex systems which will look good when you want to do a talk at an O'Reilly conference - which is exactly what winds up happening.
When I hear the phrase 'fire anyone who has architect in their title', here's what I hear in my internal monologue: Yes! Fire all the architects! Front line engineers know what every other development group is doing and can integrate their systems in a pinch! They are also across the application security requirements recently mandated in government regulation and can implement that too! No-one needs company-wide frameworks, because each development unit's home-grown libraries are good enough. Systems design? Pfft, overrated. Just check it in and break things, it's called 'agile'.
I apologise if my internal monologue sounds shrill, but your advice to 'fire all the architects' sounds similar to advice from developers to 'fire all the marketing department'.
edit: I am not an architect, this is not a defensive rant.
There's a good reason why "engineer", "architect", and "systems integrator" should not be distinct roles.
Well, no one knows what every other development group does in a company of significant size. And more often than not, no one can integrate systems in a pinch; and when it comes to integrating, the front line engineer does it. Unless your hypothetical architect has magical powers, I don't see how your point is relevant.
It's up to the other development teams to expose an interface to their services and make their libraries re-usable; and most importantly, document them and let other teams know. A company should encourage, and somewhat mandate(Bezos directive regarding no stinking db accesses, only services).
> They are also across the application security requirements recently mandated in government regulation
I don't know where you work, but the places I have worked, all mandated and non-mandated security requirements are implemented by engineers. I am curious. Care to quote me some of these security requirements of yours?
> can implement that too!
Implement what? I haven't implemented a hashing algorithm, or public-private key encryption ever, and most likely am not going to - I use tested, out of box components like I should. What's rocket science in storing hashed-salted passwords, or using SSL for transport, or PGP for offline...which engineers are incapable of? If they indeed are incapable of using bcrypt for storing passwords, well, I don't know what to say - words fail me.
> No-one needs company-wide frameworks, because each development unit's home-grown libraries are good enough
I am yet to see a company-wide framework which is relevant to anything beyond a small team, let alone useful. That said, I need to secure encode input and that other news team which takes news feed from variety of providers in multiple languages has already something for sanitizing markup. Are you implying without this architect of yours, I won't talk to the other team, or look at the code; and go in my cave to re-implement that? That makes 0 sense to me.
> Systems design? Pfft, overrated. Just check it in and break things, it's called 'agile'.
Where does this come from?
> but your advice to 'fire all the architects'
The architects in the article refer to a particular kind of person who finds it beneath himself to actually implement something, and spends his day making slide deck and uml diagrams. And yes, they should be fired, unless they are capable of and interested in implementing the stuff they swore by in their slides. Do a PoC and the engineer will take it from there. But don't come in with your ppt - you are wasting everyone's time.
So if I understand correctly, the only value-add to software development is cutting code?
Let me put this another way via an analogy: should the architect who designs your house also be required to wire the electrics, install the plumbing, and lay the blocks too? And if he/she is not interested in "implementing" (because a design deliverable is not an implementation right?), then they should be fired?
Wow.
The only value add to software development is people who can do software development. If all you do is pull slides out of your ass, you aren't welcome.
> Let me put this another way via an analogy: should the architect who designs your house also be required to wire the electrics, install the plumbing, and lay the blocks too?
Yeah. Surely a building architect and software architect are comparable.
/s
I am not interested in wiring and plumbing(tests, deployment scripts if you will), but if you come raving about how bayes classification is so sub-par, and you should use svm, you better know what is linear classification, non-linear classification(svm), and have a PoC with the data set comparable to what is being used in the application which cross-validates and proves svm is better than my bayes.
If you just read about it in some book(or blog or wherever), and can't implement it or you just think you can drop slides on me and I am supposed to do it, the door is over there - please show yourselves out and quit wasting my time. Your ppts and umls mean shit to me. If the upper management tolerates(or worse, appreciates it), do the dance for them. I am not impressed.
You just described why projects fail. Developers Developers Developers.
Architects? We don't need, we are so smart we integrate everything ourselves. Marketing? Sales? Who needs that, my github repository sells and when it doesn't, there is always oDesk.
And don't get me started over "customers" and "clients".
To cut the sarcasm here, yes, I know that a lot of MBA's and Architects suck. As do a lot of software developers, even if they call themselves agile or know that svm is somehow related to classification.
So I do not really see where this straw man burning leads to .
>> You just described why projects fail. Developers Developers Developers.
Read it again. Software development isn't the same as the whole project.
> Marketing? Sales? Who needs that, my github repository sells and when it doesn't, there is always oDesk. And don't get me started over "customers" and "clients".
Hyperbole.
> I know that a lot of MBA's and Architects suck.
Not what I said. "If you are an architect, I don't care about your slides and umls, unless you know what you are talking about, and can do a PoC before dumping your horseshit of slides on me." is what I said.
> As do a lot of software developers, even if they call themselves agile or know that svm is somehow related to classification.
I implemented bayes, and suppose I don't know about svm. If an architect comes raving about svm is so much better than bayes because (I read a blog/I read a book/my thesis adviser told me so/once I did a project), it's your job to prove svm is better for the problem at hand. Don't waste my time with your slides and blogs.
> So I do not really see where this straw man burning leads to .
I don't either. Your whole post is full of hyperbole(marketing sucks, oDesk, github). You are making up arguments I didn't put, and then responding to them.
No,
But if the guy doesn't know to cut code, I doubt if he can do anything advanced that can be built on top of it.
We are just saying you can't claim to be architect without coding or knowing coding.
>>Let me put this another way via an analogy: should the architect who designs your house also be required to wire the electrics, install the plumbing, and lay the blocks too? And if he/she is not interested in "implementing" (because a design deliverable is not an implementation right?), then they should be fired?
He should be able to do analogous work in software(That is he should understand and be able to implement electrics, plumbing and laying blocks in software). If he can't he is just a black berry button pushing, Slide making, glorified desk supervisor and not an architect.
Your analogy is poor.
A normal house uses well-understood materials and established techniques to build very similar buildings. And even there, bad architects, ones without construction experience, can cause a ton of trouble. Talk to a house-builder sometime.
But many software projects aren't like that. They're much more like landmark buildings: novel structures, novel techniques, novel materials. And there, architects can cause massive troubles. Look at the Sydney Opera House, at 14x over budget and 10 years late. It's a classic case of an architect with limited understanding of construction techniques and materials just making shit up.
And of course, there's the problem that systems architects do something totally different in relation to software (issuing mandates about the internals and construction techniques) than architects of buildings (visionaries about the look and use).
For better or worse, this is not a good analogy.
Software is design all the way down, due to complexity. There is no realistic distinction between software design and software construction / implementation.
Also, regardless of whether the software architect actually does the development work, he should be capable of doing the work. Therefore an effective software architect is a software engineer.
But then I note that every small company everywhere still manages to solve issues of integration, security, code reuse, and systems design. That's because you can do all of those things in ways other than top-down, hierarchical control from a central office.
I have never seen a company where "architects" empowered to boss people around via white paper and mandate didn't cause far more problems than they solved.
Then there are the bozos. They stand out pretty dramatically, so maybe that's why the title is a little poisonous in my head. "You're an /arrrccchhhitect?/ I'm the Queen of England, we should have lunch." (<--- not actually said :-) )
My touchstone is: If an architect is unwilling to write code then they belong in the second camp. If they're willing to write code, but don't have enough time, I look at when they last wrote code; if it's been more than a couple of years I start getting critical.
In this industry, I think it's important to stay grounded in code. You can get away without that if you're a pure career manager, but you'd better realize that you're no longer capable of designing systems at that point.
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.
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.
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.
I don't have any experience with/at Yahoo, but I imagine that there are a lot of good employees and a lot of bad employees and its important to identify which is which.
This guy: http://codahale.com/about.html
has 'Infrastructure Architect' as his job title.
I'd be wary of painting everyone who has Architect in their title with your broad brush strokes.
Or being able to building a Working Linux machine from scratch by compiling the kernel, and installing the utils. Or being able to network and administer a cluster of servers in a data center.
This is vastly different than, a guy who would just draw a block of servers on MS paint and connect them through some lines and then call himself an architect.
Sorry, not the same type of person.
if you have examples I would love to know. The variability of architects I have known has been enormous - I put them on a spectrum - everything from UML 'oh I don't need to program' waste of time to highly competant "set of principles" approach - such as why are we serving this per second data to all the clients by holding open connections to everyone of thousands of clients, let's put them on caches with 1 sec TTL all the way upto folks who live in the JvM and can debug it and explain how
can you supply examples of the phd shit solved and where it sits on the spectrum - cheers