|
The only way they excel in their field is when you hand them a pitchfork.
Software Zen: delete this;
|
|
|
|
|
May be I missed something, how is this poll encouraging any "practice". It is just a set of questions. The poll did not ask anyone to become a rogue programmer.
In my opinion, a developer should know more than the IT people and I am happy that the poll reflects that. It does not neccessarily mean that the developer should take actions nor he should take up mundane jobs like backing up systems. But if required he should be able to do those tasks.
Also, the aim of IT department (and the managers), especially in a software company, should be to assist the developers so that they can focus on the real thing: developing software.
|
|
|
|
|
Rama Krishna Vavilala wrote: In my opinion, a developer should know more than the IT people and I am happy that the poll reflects that.
Me think most people define IT not as what they are supposed to do (mostly network, hardware infrastructure) than what they are visibly doing (installing software, hardware and supporting users).
a good IT department will provide the company with a good development infrastructure (network, backup system, security, hardware/software support).
This signature was proudly tested on animals.
|
|
|
|
|
|
So... your internal application development and enhancement processes are so burdensome and dysfunctional that your clients would rather suffer through a 2 GIGABYTE Access file than approach you to provide the services and functionality they NEED in order to advance the business of the business?
Time to look in the mirror -- you can blame "rogue programmers" all you like but all too often business-driven MDB apps are a symptom of dysfunctional IT that isn't serving the needs of the business.
I used to be in IT and now I'm in application development and support -- stuck between IT and the business -- so I know whereof I speak.
Scenario in way too many corporate shops:
Business: I need an app to automate this grunt work for Initiative X with external partners.
IT: That'll take 12 months to spec out, develop, test, deploy
Business: The whole initiative will be over and done with in 9 months!
|
|
|
|
|
"but the only way to improve them is to make them better". O rly? 
Agree with your post though 
GSoC 2009 student for SMW!
---
My little forums: http://code.bn2vs.com
---
70 72 6F 67 72 61 6D 6D 69 6E 67 20 34 20 6C 69 66 65!
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
