Slashdot Mirror
IT Turf Wars: the Most Common Feuds In Tech
snydeq writes "InfoWorld's Dan Tynan reports on the most common feuds in tech: turf wars in the IT department. 'IT pros do battle every day — with cyber attackers, stubborn hardware, buggy software, clueless users, and the endless demands of other departments within their organization. But few can compare to the conflicts raging within IT itself.' Dev vs. ops, staff vs. management — taking flak from fellow IT pros has become all too common in today's highly territorial IT organizations."
it's the best.
Disagree != mod troll.
the layer between which management absolves its direct interaction with developers, and through which a SOX policy completely devoid of any comprehension of the developer or her work is enforced.
Good people go to bed earlier.
Or is that just a California thing?
To quote Lincoln Spector and sung to the tune of the Jets song from West Side Story.
When you use DOS you use DOS all the way
From your first data loss 'til you format drive A:.
When you use DOS, why your confidence grows;
For your keys there's commands, for your mouse there's Windows.
It's DOS that's sublime; it's used by all go-getters.
At file-namin' time, we're never locked in fetters--
We choose eight letters.
When you use DOS, old hardware you can swap.
You can buy something new, next month prices will drop.
When you use DOS, why, you're never a stooge,
If your 640's low, well, there's always a cludge.
DOS users: On clones we can run, with brand-names we're the choosers.
The Macs'll buy none, cause all the Apple users
Are mouse abusers.
We're using DOS, yeah! and we're gonna fix
Every last system that's not something eighty-six--
Not something eighty, very weighty, six.
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
Luckly we have the equivalent of Sun Tzu's Art of War for the IT crowd.
B.O.F.H
Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
Obviously they've never read any of the BOFH tales...
Don't blame me, I voted for Kodos
shutdown -s -f -m \\theman
The network guys are never wrong. Nope. Doesn't happen. Must be something wrong with your servers. Can't be the 2k line ACLs we've put on each vlan to protect the windows machines. Nope. You don't need any ICMP protocols anyways. Why?? What do you need it for? There are no problems with the network. Don't believe me, look at my stats....
Alex, I'll take keybindings not used by Emacs for $400....
are not technical, they are interpersonal. Cognitive intelligence is enough to get one started in this field, but gradually developing knowledge our one's own mind, how to work with others, develop a commitment to encouragement, and gaining a think skin are a must. A lot of IT jobs are a disaster. But you can still find peace in the middle of it if you develop the strength.
Years ago I quit my job web developing because a customer of my former employer was shady, and promising that the websites could do credit card sales, built in... at no additional charge. So when I quit my job over this kind of blatant lying, I was blacklisted by the former employer. A couple months later, their prized customer stiffed them in $15k worth of fees.
I phoned my former employer when I heard the news and gave her a bit of the "I told you so," except I was kind about it, and polite. It was apparent from her responses she felt sorry for blacklisting me, and sorry for not listening.
Sometimes the flak is warranted. Management: listen to your people or don't fucking hire them to begin with.
The dangers of knowledge trigger emotional distress in human beings.
DBAs always seem to want root for some reason or other... with apologies to A Few Good Men:
SysAdmin: You want the authority?
DBA: I think I'm entitled.
SysAdmin: You want the authority?!
DBA: I want the root!
SysAdmin: You can't handle the root!
What do you mean they cut the power? How can they cut the power, man? They're animals!
Got a great idea and want to get it past security without trouble? that's simple... simply get buy-in from a senior executive. get him to adopt it as his pet project and get it working on the Dev servers. now when he announces it Security cant do anything but say yes and do your bidding because they do not dare tell the Senior VP of marketing that they wont let his project run. Do I make enemies withing security? yup. Every one of them hated me because my default approach to them was an end run. And it was simply because the security guys were incapable of thought outside of the "lock it all down" OMG OMG! DANGER DANGER! WE got a iphone/ipod app launched for use in the company and made every one of the security guys froth at the mouth and fall on the floor convulsing when I end ran them to a VP who loved it and wanted every sales person to have it. They lost their mind at allowing 190 non company locked up iphones and ipods connected to the holy internal wifi.
Just wait when my ipad system for sales forecasting get's greenlighted and they have to allow 200+ ipads on it as well...
Do not look at laser with remaining good eye.
You can't. They are everywhere. However, you can escape them if you become an entrepreneur and write your own shit, then anyone you hire has to be up to standards or you fire them. This is how good companies replace bad ones.
The dangers of knowledge trigger emotional distress in human beings.
Have you tried no being a dick yet?
I have found not one, but two jobs where the entrenched administration chose Novell and refused to budge. I normally am pretty calm about using any tech, if it works then it works.
Novell, however, is a bloated piece of crap that no user should be forced to use. However, if it were the only game in town, then you're stuck with what you've got. It's not, however. It's not even the best at what it does. The only reason it's still in use is because there is a certain class of 'admin' out there that refuses to learn something new and update their skill set. So they instead drag the rest of their organization down with them in to the nightmare that is Novell software.
Mod me down with all of your hatred and your journey towards the dark side will be complete!
It's easy to point at other vendors, engineers, deployments, designs, et al and say that it went wrong because of them. But how much of that is an excuse made by midrange or flat outright incompetent personnel? Not everyone can be brilliant on the bell curve, and for everyone else, well, it's easier to blame others when the plan blows up.
Remember that the network switches / hubs / routers are part of "the network".
So when there REALLY is a problem on the network, the network admins usually hear about it because EVERYONE is having problems with ALL of their apps.
If one workstation or one server is having a problem (but the others are working) then it probably isn't a problem with "the network".
It may be that the network is not configured the way you'd like it to be for whatever you're trying to do ... but remember that the network admins have to keep the network configured to support all the OTHER items that were on it before yours.
At least be able to tell them what you want to do protocol-wise.
In this regard the iPad/iPhone is equivalent to kids driving around with motorized scooters on the freeway. It's exciting and easy to use. But completely incorrect tool for the job. iPads are consumer products without any security features worth mentioning.
I admit: my first reaction is that if I worked security at your company, I'd want to kick your ass. I mean, I like you, but they probably have a very valid point about not wanting untrusted apps popping up all over the place.
But my second reaction was that you're right. There's no valid reason why you can't have unsecured guests on the holy internal wifi. We have an open WLAN here at the office, but it's firewalled away from anything we actually care about, with exceptions on a case-by-case basis. You don't get open access to the database server just because you're connecting to our corporate wifi. If your security guys can't handle that, then, well, sucks to be them. Good for you for finding away to make people actually do their jobs.
Dewey, what part of this looks like authorities should be involved?
Any developer that writes an app that requires admin rights on the desktop should be beaten and stabbed. (yes, you should be able to disable auto-updating)
I see this all the time in government. Various IT departments will make it impossible or difficult for others to do work, but limiting access to various things, restricting software, no allowing for permissions, and refusing to take responsibility for a role or function that might enable any of those things.
ME: I would like to do X. I need to have access to Y in order to do X, may I have access please?
IT Dept: A) No you cannot do it, but we would happy to do it for an exorbitant sum, but we don't have capacity now, so you will have to wait 6months. B) We are not responsible for granting that access but please speak with RandomITDept (who will immediately say its not their responsibility, and refer you back), however we would happy to do it for an exorbitant sum, but we don't have capacity now, so you will have to wait 6months.
I understand the rational for limited access to certain things, but the sole purpose for most of this seems to be to secure work and thus positions for their particular IT department as well as the power base for those managers so that their staffing and budgets are justified.
Sigh.
Daily life around here.
Marketing wants what marketing wants. To hell if it has a positive cost/benefit ratio. "Nice and shiny and uses lots of Flash ... and runs on my iPhone ... drool"
Devs dev what marketing wants. Dev only wants to dev in production. As Administrator/root/qsecofr (or ALLOBJ).
IT Management, but especially Finance Magement skimp of every possible detail until they end up spending more time AND money patching it until it would have been cheaper to do it the way joint Ops/Securty said it would.
Ops/Security is handed a dogs breakfast of non-working, insecure code that produces amiguous, and often wrong results. Last to find out or provide input. But it's our fault when it doesn't work, or opens all security doors, or breaches laws in several countries. (The last ones to touch it must have broken it).
Classic way NOT to do it.
Q:I was listening to a CD in Grip and it sounded horrible! What's up? A:Perhaps you are listening to country music
Designing a wireless / wired network to support unsecured guests is a LOT different than designing one to support only secured guests.
AND it requires that all the PREVIOUS systems not have problems with the design.
The network admin has to support ALL the systems. Not just your pet.
What happens when the corporate database IS accessible from the corporate wifi because other apps need that access and those apps are run by people on wifi?
Got a great idea and want to get it past security without trouble? that's simple... simply get buy-in from a senior executive.
One of the best environments I ever worked security for allowed for senior managers to take personal responsibility for these kinds of decisions. The business unit would announce their Big Idea. InfoSec would look at it, analyze risks / security issues, and (often missing from many InfoSec groups) work out ways to allow the same functionality while mitigating any discovered risks, and ultimately document those risks. If the business unit didn't want to follow InfoSec's recommendations, they could take their Big Idea to their boss and make the business case for it so that their boss can take personal responsibility for the decision. InfoSec would provide the risk assessment. Senior management would then decide if the business case overcame the risk and everyone would press on accordingly. The process did wonders for enforcing open communication. Management wanted good information before they put their own butts on the line. Business units couldn't get away with just grousing or avoiding InfoSec and InfoSec couldn't get away with arbitrarily dismissing any new ideas. I should point out that this system is seeped in conflict. And that's good. Conflict is fundamental to security and, in many ways, any pursuit that has many options guided by creative thinking - something that all good IT environments should be encouraging. The key is to ensure that conflict can drive a constructive process. Too many IT environments pretend conflict doesn't exist and has no proper outlet for it.
I could just as easily say "if programmers could think on their feet and fix problems that cost the bottom line thousands of dollars per minute of downtime they would be IT guys." But then I'd sound just as short-sighted as you do.
Slashdot? Oh, I just read it for the articles.
The head of our systems branch used to always say, without irony, "The applications branch can't run without systems, but without the applications branch, systems run just fine."
To which the head of apps branch would mumble, "Yeah, and without customers Apps branch would run just fine."
i ~ Celebrating Science, Cyberspace, Speculation
BAs? I thought a BA was a Bearded Anthropologist, but I don't see how that connects...
and kicking! I just wrote some code to do tracker desktop search from within emacs (using dbus and dired).
let .net developers do things correctly.
You mean, like migrating apps away from .net?
Got a great idea and want to get it past security without trouble? that's simple... simply get buy-in from a senior executive. get him to adopt it as his pet project and get it working on the Dev servers. now when he announces it Security cant do anything but say yes and do your bidding because they do not dare tell the Senior VP of marketing that they wont let his project run.
They should go to the VP of marketing and ask him about delaying the implementation of the project to try to address some security issues, and inform him that the devs didn't give corporate security a heads up to even start considering the security ramifications.
Then a few weeks later, they can deliver a shiny report to the VP quantifying the risk that this new effort brings to the company, explain what the risks are, and propose mitigations to the risk (some of which involve removing things from the project, locking it down, or spending a lot more money), as well as the risks and costs for going forward with no changes.
After the VP weighs his options, he may cancel the project, due to the cost created by not involving security planning at Stage 1.
Do I make enemies withing security? yup. Every one of them hated me because my default approach to them was an end run. And it was simply because the security guys were incapable of thought outside of the "lock it all down" OMG OMG! DANGER DANGER! WE got a iphone/ipod app launched for use in the company and made every one of the security guys froth at the mouth and fall on the floor convulsing when I end ran them to a VP who loved it and wanted every sales person to have it. They lost their mind at allowing 190 non company locked up iphones and ipods connected to the holy internal wifi. Just wait when my ipad system for sales forecasting get's greenlighted and they have to allow 200+ ipads on it as well...
Just wait 'til Security has to have an auditor in with a pen test that involves sneaking in an iPhone with malware installed, and gives the company an F rating on a SOX audit, with demands that the "open wifi policy" cease, and 10-million$$ fines for the company.
That is the problem when you are working in a gatekeeper position or have deal with people in that role.
No one notices the gatekeeper until they screw up. The default answer to any request must be no, because if they say yes and something bad happens it is their fault. No one remembers that they have been keeping the bad stuff out up until this point. Only that they let this one bad thing through so they must be bad at their job and should be replaced.
Maybe I read it wrong, but wasn't the GP's post about having unsecured guests onto the internal, secured wifi?
Having unsecured guests on an unsecured, external wifi network is easy.
Allowing someone in parking log to access your internal network from his unsecured machine ... that's a problem.
Just ask Target about it.
If programmers new what they were doing I wouldn't be stuck running old-assed unsecurable OS's that we only keep around because stupid programmers can't be arsed to update their bloated crappy application software to run on current systems.
Hey programmer, try running your app without a machine to run it on.
A lot of times it's the push from management, not the lack of motivation. App XYZ was written 9000 years ago (in computer time, so, translated into maybe 15 earth years?) and the developers were tricked into using some snazzy system calls or library components that promised they'd change the way they work "forever", but, really, support was dropped 3 years later leaving an app that, best case, needs an entire tier rewritten (worst case: the whole dang thing). It takes time and money, but the business won't spend any money because XYZ, as far as their concerned, still works just fine. Believe me: there's nothing I want more than to rewrite these little timebombs into something more supportable.
Part of this is why I just roll my eyes when the architecture team starts pushing this brand new framework of product or library that will somehow magically solve all our problems. It's just a whole lot of "play now, pay later."
More Twoson than Cupertino
What a sad day it is, I read DOS as denial of service through most of the first verse. The sad thing is I grew up on DOS, ok MS-DS.
insert inflammatory comment here!
they would rather write a buggy version of asp.net (using asp.net no less) than let .net developers do things correctly.
Where can I escape retarded senior developers???
Escape them? It sounds like you are on your way to becoming one.
It sounds like anytime you want something, you run to upper management. I guess you will be a manager firing people in no time with that kind of attitude. Good job. You are successfully not seen as much of an IT person, but a corporate person that pushes people around under him/beside him by getting in with upper management. I would not consider your story as much of an IT story as much as a corporate "push your weight around" story. Sure, it happened in the IT department, but it could possibly happen in any department.
The world is how you make it
Sometimes it's a senior (in years only) developer who created a "standard" before I got there.
I'm guessing you never bothered to ask why that "standard" was there to begin with and 2 to 4 months down the line will find out that there is some limitation that was completely outside of everyone's control and you've just run head first into it. Of course by then you'll have started a re-write and will learn to just blame it on the old timer's lack of documentation and if it was documented, it wasn't documented "right".
And I was under the impression that we had to migrate our apps every couple of years because the IT staff spends half it's time in Microsoft brainwashing seminars that tout how much easier to administrate, and more secure their latest XYZ is even though they made that claim just a few years ago with OS ZYX.
Well all of us programmers don't have backgrounds in engineering or sit around in a cube programming widgets. Some of us come from small shops where we have to do complete life-cycle development, database administration, package and installation, and everything else at one time or another so, we're pretty familiar with the roles that a dedicated IT department should be responsible for. In fact I wouldn't hire any developer that doesn't know have at least intermediate level knowledge of server OS's and networking. So you can color me unimpressed if the network admin says his job is as difficult as mine, when I consider something like IT support and network administration a stepping stone.
> One of the best environments I ever worked security for allowed
> for senior managers to take personal responsibility for these
> kinds of decisions.
Yeah, I once had a dream like that too, except the senior managers were also unicorns who shit candy.
Log in or piss off.
Just think how that would have gone if you had done steps 1 (buy-in) and 2 (dev servers) and replaced step 3 (be a dick) with (approach security with said buy-in and offer to collaborate on making the security work in a conducive manner). Senior VP would know you know how to manage a project and get things done and security would know that you're someone who cares about their requirements and is willing to work with them, making future engagements that much easier. Now that you've established your reputation as you have, good luck working with them on that ipad system now that the gloves are off.
It's very green to think that the most important thing to focus on at work is technology or process choices. It's more important to build meaningful bonds with other teams than any other skill set. That's why IT goes to bat for me when I need them to. Because I work with them, not against them. If they say things need to be a certain way, I may question why and protest civilly if it's not legit, but I follow their rules. It's their playground I need to run my code. They need my code to keep their playground. It's in our best interest to work together. So put aside the silly topics that split you and focus on why you are truly there, to make a good living doing what you love.
I know that sounds a little wistful. But after many years of this industry, I can honestly say there are some things more important than what tool set you use. I'm in demand because I can code well and I'm a good teammate. Those two things are both equally important.
Tiger Blooded Bi-Winning Machine
IT Myth 0: Let's get a bunch of boys who relate to machines better than they do to other people, put them all together, and expect them to work as a team.
Black bear*, FTW.
* Ref
You mean MS-DOS wasn't a Denial Of Service OS?
Not a sentence!
Yeah, those "personal responsibility" contracts are just proof that you allowed senior management to do something unbelievably stupid and attempted to absolve yourself of the duties you were hired for. When it hits the fan, you'll be canned because you weren't doing your job (senior management might or might not be fired depending on cronyism).
"Of course, I wasn't the one who was constantly rebuilding hosts in the internal network because black hats kept breaking in through compromised iPhones, so for me, it was a total win."
Your solution is all nice and fluffly, but completely NOT grounded in reality, and the GP was talking about reality.
Devs have NO say, Ops have NO say. You get handed the dog food and you can either eat it or find someone else to feed you.
Opinion:=TMyOpinion.Create(Me);
+1 Wisdom
If you aren't suspicious of your government's actions, you aren't doing your job as a responsible citizen.
One of my favorites is http://www.thewebsiteisdown.com/ featuring "The Sales Guy vs. The Web Dude" as web dude tries desperately to get his important work (gaming) done while assaulted on all sides by rampant incompetence. And the email from the boss, "whatever happens, DON'T REBOOT THE SERVER!" (of course that emailed was conveniently "not found").
mfwright@batnet.com
Sometimes it's a senior (in years only) developer who created a "standard" before I got there.
I'm guessing you never bothered to ask why that "standard" was there to begin with and 2 to 4 months down the line will find out that there is some limitation that was completely outside of everyone's control and you've just run head first into it. Of course by then you'll have started a re-write and will learn to just blame it on the old timer's lack of documentation and if it was documented, it wasn't documented "right".
Exactly. If there's one important lesson that I've learned, it's that you never assume the person who wrote that "retarded" piece of code was a moron when they did it, or that you even know why it was written a certain way. There's probably a very legitimate reason for it. It may not even be relevant any more, but it sure was at the time. Just do yourself a favor and ask a few questions before jumping to conclusions.
If you aren't suspicious of your government's actions, you aren't doing your job as a responsible citizen.
Yeah, those "personal responsibility" contracts are just proof that you allowed senior management to do something unbelievably stupid and attempted to absolve yourself of the duties you were hired for. When it hits the fan, you'll be canned because you weren't doing your job (senior management might or might not be fired depending on cronyism).
I invite you to re-read my post. My job was to identify and outline the risks. Which I did in my report that was distributed to the team and all management involved in the decision process (always CYA with documentation). At that point, it is management's job to make the decision. That's what management does. If you're in a position where you can do your job, get ignored, and still get fired then you should cut your losses and get a different employer (or be a contractor with sufficient fees to cover the service of being a scapegoat).
I'll point out that in this environment, it was exceedingly rare for a management showdown. People tended to back down instead of taking the risk assessment to their managers. Managers would often come back with more questions and directions for their team to adopt recommendations. When it went up to the next level, it wasn't a given who would "win" the argument. If management over-ride was a trivial and common-day practice, I wouldn't have viewed my environment as being "one of the best." I agree that not every environment is like this. Heck - many environments seem to have little concept of accountability. But that doesn't mean it is impossible to do.
If programmers new what they were doing I wouldn't be stuck running old-assed unsecurable OS's that we only keep around because stupid programmers can't be arsed to update their bloated crappy application software to run on current systems.
Hey programmer, try running your app without a machine to run it on.
Go whine to the project manager or whoever deals out the projects and balances and prioritizes available dev time.
If you aren't suspicious of your government's actions, you aren't doing your job as a responsible citizen.
Why an iPad app? Why not a web app? That way you don't (necessarily) have to buy any new hardware, and don't need to lock yourself in to any proprietary platform.
You have to understand, each iPad is a portable, overpriced little security nightmare. They're fully capable of running advanced malware like a desktop computer, but at the same time, are uncontrollable, unsecurable black boxes. You have less control over them than Apple, the telcos, and anyone who can compromise anything they're running. A brand new iPad out of the box must be treated with at least as much suspicion as any random, potentially malware-riddled home PC. And you want to introduce hundreds of these onto a network presumably intended for secured machines.
I'd really like to hear more about this, because from what you've said it just sounds like you pulled the biggest backstabbing dick move of all time to get a silly iShiny app in use for some reason. Maybe the security guys were being totally unreasonable, and maybe your iPad app is genuinely useful and really awesome, but from your post your idea sounds like a bad one.
"When information is power, privacy is freedom" - Jah-Wren Ryel
Ding ding Ding!!!! we have a winner.
And that is the point of getting executive buy-in. to bypass the security guys that say by default "no way, if it does not meet NSA security specs it's not on my network" and actually getting work done in the company.
I'm a big one on giving the guys that matter, sales, the tools to sell more and make more money for the company. It's that understanding that get's me as a IS guru and dev the ear of most of the executives as I talk their language.
"increased sales, better time management, low cost easily replaced hardware (iphone/ipad)" makes them listen, buy in and say, "great idea, let's test that and see if it can be implemented "
SEC would prefer we use $3500.00 each windows 7 tablet computers instead of $500.00 ipads. SEC guys are out of touch with reality, end running them is the only option in getting real technology in the company.
Do not look at laser with remaining good eye.
They frequently do cause unnecessary limitations. Then I get it up to snuff and find out that quiet XYZ client wants it that way for their POS legacy setup.
"Who is this XYZ?"
"XYZ, they propped us up during the last economic downturn. By the way they called this morning and were pissed."
Sigh.
http://www.channel4.com/programmes/the-it-crowd :)
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
And that is the point of getting executive buy-in. to bypass the security guys that say by default "no way, if it does not meet NSA security specs it's not on my network" and actually getting work done in the company.
The problem here is having to bypass the security guys. In that environment, we were constantly coming in to a meeting and putting the breaks on the Big Idea as presented. There were often huge risks due to absolutely no consideration or understanding of security or even the underlying technology. Our job was to not only find these problems, but help the business unit come up with solutions to those problems. That was the usual outcome. Sometimes the business unit just didn't want to change their direction or the Big Idea was fundamentally risky. And thats when we had the face-off between business gains and business risk.
That doesn't mean we didn't have people doing the end-run game you're describing. But they were often exposing our mutual employer to pretty significant risks - often completely unaware of what they were doing. Granted - your environment might be different. Your security group might be setting up their own headaches by being viewed as a problem rather than part of IT solutions. Or you might be setting yourself up to be part of the next big security incident for your employer.
http://www.infoworld.com/print/151016 "You're welcome." --Nick Burns
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
So I am curious how this evolved into this form. How did this get implemented? How did you get the buy in that you should actually take the time to do this assessment?
I better jump on this chance to ask my question. No, I'm not trying to start a flamewar, but this might be a unique chance to some more insight.
Okay, you use emacs. What was your choice based on? What were the factors that ended up getting you on emacs?
For me, I decided to learn vim, because I had heard that there was a lot of chording (ie. Esc-Meta-Alt-Ctrl-Shift type simultaneous keys) in emacs. It worked out well when I started using vim on my smartphone. But I haven't actually used emacs before, so I don't know what emacs is like, and I freely admit that I don't know what I'm missing.
It sounds like there are a lot of historical for preferring either, which are not necessarily relevant today (e.g. Emacs took up more memory, before massive cheap memory was available on the market; there were no colour screens when vi was created, etc.).
So, my specific questions to all you emacs/vim users out there are:
1. Which do you use?
2. Have you used the other one before?
3. If you have had experience with both, what were the deciding factors for your choice?
Note: Please don't say which one is better overall --I think we've all heard that before. Please don't tell us how Pico or Gedit or MS DOS Editor is better than either vi or emacs (unless you want to share how your decision came about after actually having used vi/emacs). The purpose of this question is (among others) to help a user naive to both vim and emacs to decide which to learn.
Thanks for any insight you can give.
404555974007725459910684486621289147856453481154 in hex is "You sank my Battleship?"
[GPG key in journal]
I'm pretty sure he has.
Their security sounds eerily familiar to my security - Who forces me to sit with my laptop on an unsecured connection right on the internet, because I'm an "untrusted" contractor - but working on developing their systems, who are thus *also* untrusted. And therefore they can't allow internal access, so none of the internal customers are allowed to actually see what I'm developing, unless I mail them a screenshot.
Oh yeah - since I'm in the untrusted segment, they also don't allow debugging because that's against policy, since the server needs to connect to my development environment (the insecure one - the one I'm using to BUILD THEIR SOFTWARE for them that will then be promoted to the internal servers, no questions asked).
I've told my project lead that he could do two things: one was to change the policies, and the other one was to accept more billed hours. He chose the hours. Way easier.
Therefore, by the (faulty) logic you're using, you're just a cow with a keyboard - osu-neko (2604)
Tried it. Didn't like it. It really wasn't much fun.
If I were God, wouldn't I protect my churches from acts of me?
So I am curious how this evolved into this form. How did this get implemented? How did you get the buy in that you should actually take the time to do this assessment?
It was the job description. The employer was dealing with a number of major security incidents and was trying to get a handle on the situation. They wanted to change how things were operating but they didn't want to kill the golden goose.
I have to admit, the environment was different than others. It was corporate but had more of a research feel to it. Unlike, say, banking environments where locking things down is a part of the culture. Yet this culture allowed for personal responsibility as management put their reputation on the line to support a business case. Taking risks was a part of that culture but you had to be able to justify those risks. So in effect, the security group was working as consultants to the various business units (while still being Masters of the Firewall and therefore holding the kill-switch to external network access).
I believe this would work in other environments. I've applied some of this to Government as well. I championed getting ourselves involved as problem solvers and not simply They Who Know You Surf Porn or Masters of the Firewall. I attended a number of meetings where we acted as consultants to help the group identify and mitigate security problems. Sometimes it was with existing or about-to-be-deployed solutions. Sometimes we got involved at the requirements stage and were able to help the organization start on the right path from the very beginning (which tended to make everyone happy). Come to think of it, this was another environment with a history of high-visibility security incidents.
ACs, either we are defining what falls within IT differently (I would say anything to do with operations, from the support desk on up to the enterprise architect), or your knowledge of the salary range within such positions is extremely limited. There are plenty of operations people making near or above six figures and then some, and plenty of programmers in the same markets who will never see that kind of money until the dollar devalues like the currency of a third world junta. But it's *real* cute how I whipped you into such a frothy-mouthed frenzy with the mere suggestion that you can't perform under pressure.
Slashdot? Oh, I just read it for the articles.
I've been at various times, a syadmin, a dba, sec/op, developer, manager and even took my turns at answering the phones at one point in time. Often, several of these roles at once. I've been on every side of this issue, and if you wanted to take a stab at a generic fix, it could be summed up simply: work on your communication skills.
I hate to plug agile, but the focus on round table discussion among all stakeholders really seems to be the way to go. Aside from the criminal examples, the problems in the article all stem from lack of understanding or an inability to explain. Making the people who dream it (sales & marketing) sit with the people who make it (developers, dbas), the people that make it go (admins, security), and the people who say go or no-go (managers), is required if you're going to churn out products with as little strife as possible. Devs need requirements and tools, DBAs and Admins need hardware budgets and usage estimates, Security needs the policy followed or amended, Management needs to keep costs down and cycle time high, and so on. You need to communicate this to all members, not just via project managers.
The article ends with a choice quote:
"The top sources of conflict are the tech person's ego, poor management, a lack of proper leadership, and allowing technical people to make business decisions. The solution there is to know your role and let your talents shine where they should."
No. This is just a quote to sell services to non-technical management. Paraphrased: "Those silly technical people have no social skills, or business acumen. It's their all their fault, pay us to tell you why" with a subtext of, 'use this to ensure your year-end bonus to the board, and why only the grunts should be fired'. Everything in there perpetuates the myth of the antisocial nerd, incapable of everything but a magic control over computers.
As an aside, I think the devs get it the worst. Requirements always suck, always move, and often conflict, management always moves up dates, removes people, adds features, and rearranges priorities in the 11'th hour. Some companies don't allow devs to install local software, slowing development. Most hardware allocation requests have to come from them, instead of the product managers, so it's often one dev vs. dba/sec/admin- department. Operations crews don't want to learn new systems or introduce esoteric requirements only after software is gold, and so on.
For some reason, no one has problems when security or admins say it will take 3 weeks for a badge or new hard drive, but expect developers to rewrite software in a day. I often wonder if it's just that the dev department never does a good job training their manager compared to the other groups.
Amen to that.
And even when you are right, it's you who have to proof it as you're the last arriving one in the place, possibly in a way that does not hurt the other guy.
:wq!
oh cry more. oh no, security was compromised and i have to do more work!
but if your happy politicizing yourself out of a job. be my guest. i will continue to demand root access to my damn machine because i don't want to wait the 3 days it takes you whiny security guys to install a simple app.
our security guys are demanding that we only use internet explorer 7, because apparently Firefox is insecure. that's all well and good, but I'm a web developer and i need Firefox (as well as ie & chrome) to do my job properly.
Just for fun, what would malware actually do? Apps are heavily insulated from one another, and a corporate Ipad store has exactly what you want it to have. I wonder if Apple has set up a whitelist control for its corporate plans, as that would address most of your concerns. In the meantime, a compromised Ipad can be wiped without much problem.
"We returned the General to El Salvador, or maybe Guatemala, it's difficult to tell from 10,000 feet"
being a programmer he works under regular pressure..
the pressure of his fat rolls that is.
oh no he didn't....
It's not about skills so much about caring about consequences.
It was interesting when I started at a new job and a developer was working as a temporary sysadmin and he was "showing me the ropes". I pointed out a problem on a MS Windows domain controller which could be resolved by stopping and starting services, but before I'd got very far he walked out and hit the fucking reset button on the machine. There was no backup domain controller ("if it breaks I'll fix it"). He then did not answer the large number of phone calls that came through in the next half hour while doing nothing but sit and watch it do it's disk check and told me not to answer either ("they'll get over it"). The guy KNEW how to do the right thing but didn't think that was his job and didn't even contemplate the lost production and anger he had caused just to save a few mouse clicks but waste a lot of his time staring at a screen. That illustrated to me more than any of quite a few other examples that some developers just have to realise that running systems is a completely different job with different aims than running a test system they can reboot at any time.
It's not about skills.
It is about understanding what the job actually is.
That is why developers are typically kept as far from production as possible until they can understand what sort of actions are incredibly stupid in production and what the consequences of those actions could be.
exactly.. its just bits on the network.. the security guys should be concentrating on all hosts being untrusted.. Far too often I have seen nastiness happen because someone plugged a personal laptop into the company network behind their lovely well maintained and managed at the front end of the network.
What are we going to do tonight Brain?
Meanwhile, your competitors don't actually give a rat's ass about your sales data for Omaha.
Talk about proving the point of the post. 'Cos one of you is *definitely* going to turn out to be right.
Player Owned Structure?
Yeah yeah yeah, I know it is Point Of Sale...I'll show myself out...
APK likes to ask for responses to the same things over and over. Maybe he just likes the responses?
Yeah, related to the "last hand to touch it" syndrome I read in another post here.
sr
His ignorance covered the whole earth like a blanket, and there was hardly a hole in it anywhere. - Mark Twain
*whoosh*
"But then I'd sound just as short-sighted as you do."
You apparently missed that bit, where the point I make is precisely that such a position (one role must be superior/more valuable/better paid than the other) is silly.
Slashdot? Oh, I just read it for the articles.
I'm in my late 20s...
So you've been in the industry a total of what, 5 years? That's hardly enough time to be judging senior developers. I could only say that's enough time to judge your own team, but then I'd go back to the communication thing. I can only assume that since you've been at your career for around 5 years that it's all stocked in one place. Given that, you've been there long enough to be able to pipe up about shit and be listened to. At this point, if you haven't said anything politely, it's your own fault. Yes, there are poor developers and sometimes people get to where they are because of the years under their belt, but being as you sound so fresh and immature about it, I'm giving the seniors the benefit of the doubt.
If you aren't suspicious of your government's actions, you aren't doing your job as a responsible citizen.