> Front line engineers know what every other development group is doing and can integrate their systems in a pinch!
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.
> 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.
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?
> So if I understand correctly, the only value-add to software development is cutting code?
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.
> The only value add to software development is people who can do software development.
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 .
> The only value add to software development is people who can do software development.
>> 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.
I think the only value-add about the construction of software can only come from people who are regularly cutting code. Other people just don't have enough detail to understand the implications of their mandates.
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).
>>So if I understand correctly, the only value-add to software development is cutting code?
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.
>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?
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.
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.