|
I used to be a 'Rogue'...although, I called myself 'Shadow IT'. I worked for the mouse years ago, brought in as a 'temp'. Purely for the same reasons, it seems.
Typical Experience doing a project...
Dept Manager: We need a electronic documenting syst......
IT (Interupting): What is your budget?
DM: Well...no. We were hoping to put a plan together before we....
IT (Interupting again): You need to get a budget so we can hire the staff needed for this project.
The next day, I get a call from Mr. Head Hunter. Bang! I'm a "documentation specialist". In six months, I help develop a multi-user multi-location Access DB running off a local share on a file server. All below the radar...mostly. In two years, the powers on high see a program in action that is doing an efficient job. Some wise person decides it should be corporate wide, corporate quality... with all the bells and whistles (and servers) that the IT jocks can tie onto it.
As was said just previously. It is a two way street. If IT makes themselves unapproachable or the process a cluster-F catch-22, no one is going to want to play. IT is there to make things work efficiently always.
No single raindrop believes it is to blame for the flood.
-irresponsibility@Despair.com
|
|
|
|
|
In reading some of the examples given and based on my experience, the phenomenon of "rogue programmers" is not an "I know best" problem, but a "no one listens" problem. Whether it is that no one listens to the issue (they get blown off) or an extremely slow turn around with no feedback. I am a development team leader who reports directly to the director of development at my company. We have found that a lack of openness and communication is the primary reason we get these little nuggets of joy scattered around our servers. The best way to deal with it was to stop blaming the developers every time we found something and attack the root cause. Second, I agree that you have to put in a strict policy. If QA is rolling their own solutions to everything and mucking up the network and the servers they should be forced to adhere to the policy and use the intranet. To do otherwise creates ambiguity in the policy enforcement and pretty soon everyone is writing rogue code. At that point you have also made it hard to discipline anyone (try firing someone for writing a rogue program at that point, see if the phrase wrongful termination does not come up. Obviously it was okay for QA to write all their own stuff in violation of the policy, but when another person does it they get a repremand? Sorry, can't do that.
|
|
|
|
|
I have to admit I am pretty hopeless at hardware - possibly because I have very little interest in it
|
|
|
|
|
It depends where you draw the line. Backups, security, network... my It-department is often way better than me.
But since its really hard to have the whole picture regarding a system. for instance, witch Failover and loadbalancing scheme to use is dependent on how the system works. therefor my relation to the ItDepartment is at times i bit strained.
IMHO we're about the same... just not the same part of the system
|
|
|
|
|
I know quite a lot about hardware, I've assembled several PCs so far. In my opinion, knowing hardware is very important for a developer. It helps you better understand computers and, hopefully, improves your ability to write programs for them. I'm always surprised at the fact that most programmers never had a look inside a PC.
On the other hand, I am mostly ignorant about sysadmin. Sure, I can install and configure a desktop or server OS, but I'm not (yet) able to configure advanced functions such as the domain controller or Exchange.
|
|
|
|
|
Dario Solera wrote: I'm always surprised at the fact that most programmers never had a look inside a PC.
How did you come up with this concept? I've not yet come across a developer who doesn't do his own hardware upgrades - which requires opening up the box - on their personal systems [at the least].
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"As far as we know, our computer has never had an undetected error." - Weisert
"It's a sad state of affairs, indeed, when you start reading my tag lines for some sort of enlightenment. Sadder still, if that's where you need to find it." - Balboos HaGadol
|
|
|
|
|
I completely agree with this, it is always better to know most of the things. Knowing half is as good as knowing nothing so always try to understand the system completely..
|
|
|
|
|
"It doesn't take much to know more about (Windows) SysAdmin than I do."
On the other hand, I used to be an OpenVMS System Manager, and when I switched to development I found that I knew more about that than the people who were supposed to be doing it.
|
|
|
|