|
Some years ago the bean-counters decided it was too expensive to have an IT dept just for us techies, so they made a big Admin centre 200 km away to do everyone. They spend most of their time repairing the office PCs of managers who have downloaded some virus. When we techies ring up they have absolutely no idea. They also do procurement; these people took 5 months to get me an Ada compiler - I had downloaded the trial copy in 20 minutes. The admin man said, why not use a freeware version. I said, I do safety critical software. He said, what's that?
After a few weeks of this we got our own admin, who is a genius and a saint. We get constant updates, and he will just turn up with a disk and install anything you ask for. He also advises on hardware for home, and keeps up on all the newest cellphones and such like.
Unfortunately he can't speed up the procurement process, but we got them moving by stopping project development... That went right up to the Ministry of Defence. They do not learn though. This year I had to do it again with a Fortran compiler.
--------------<;,><---------------
Old enough to remember card readers...
|
|
|
|
|
I work for a small company of (mostly) techy / intelligent folks.
When something goes wrong or something needs doing, usually we fix it or do it ourselves.
Or we ask around if we don't know.
Small companies can't always afford the luxury of a dedicated IT person or department. Especially since the good ones cost a LOT of money!
|
|
|
|
|
I have always been a DB development wonk, whether as a DBA or developing Apps. Knowing how systems work and how packets flow have always allowed me the ability to write better code. In the movie Galaxy Quest, the villain says "What commander does not know every bolt of his ship", that is also the way I feel about development. I always ask myself,"What DB developer does not know how the OS & Hardware functions?".
I do not believe that a good developer needs to know everything about systems, because I have hired a majority who do not, but I do hold myself to that standard. Although I must say that all other things being equal, that could sway me toward on candidate over another. I will also say that my knowledge was the cause of a 10 week extension of my last contract after my position was eliminated in budget cuts, and that is always a good thing. 
|
|
|
|
|
... I hope 
|
|
|
|
|
The IT has the systems and servers people and the programmers. The systems people are properly noted as 'Way Better Than I Am' at that stuff than I.
(And, by the way, vis-versa).
I Really needed to check two boxes.
"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
|
|
|
|
|
Exactamundo
Our IT has infrastructure and support then there are us DEVS.
Two completely different animals sometimes lumped under the same roof.
There are common areas where the knowledge overlaps but in terms of the context of the app, it is always the DEV that knows whats going on.
PS. Devs do their own DBA stuff here
|
|
|
|
|
robvon wrote: PS. Devs do their own DBA stuff here
Here, too - I don't see how it would work any other way. The design of the database and the apps are not (or certainly should not) be considered independently.
At times, this developer-centric db-design really shines: when two apps have to communicate (not necessarily in real time) - we simply get together, accommodate as much as possible to respect one another's data plans, and make what changes are necessary. This is a great reason to (1) make instead of buy, and (2) shun outsourcing - particularly overseas. Face-time is a good thing.
Back to original subject: the server people are in charge of all physical PCs, do all installations/updates, except for the developer's systems, and control the backup and other maintenance task, the internet, much of security, and pretty much anything of that nature.
Best of all - with this setup, all of us worker-bee's get along very well - not competing, but symbiotic.
"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
|
|
|
|
|
IT, I beleive, is entrusted to look out on the corprate "good" on computers, the infrastructure. While developers, like me, are just trying to get our jobs done. They do keep things running over all to be standard and safe. It's when you need something off standard that they get their panties in a wade.
i.e. We had training, no individuals are given admin rights without a body cavity search (slight exageration). We got admin rights temporarly to load the test software for the training class. Half way through training we got the latest updates to the software with the fixes we needed but IT, in their limited wisdom, wouldn't grant temporary admin rights until we pushed it up to director level, wasting a day of training.
Also, one friend in IT said, off the record over a couple of beers, that they don't allow people to have admin rights so they can justify their jobs.
|
|
|
|
|
My personal complaint with IT is that some of the crap they force down the pipe breaks the machine for developers.
We have a remote administration widget from Cisco that's used by the corporate IT structure. It emulates Vista-style UAC on an XP desktop. It is not possible to develop or install software with this thing in place. It pops up a message box on every disk write to anything that looks like an executable: .DLL, .EXE, and so on. We've gone round and round with them over it. Finally, we wrote a service of our own that detects it, kills the process, and uninstalls it. It was too much of a PITA to bother remembering to kill the damned thing every time it showed up.
Joe Q wrote: no individuals are given admin rights
If they ever try to remove my admin rights to the computers I develop on, I will inform my supervision that they've eliminated my ability to do my job. We'll see who wins: an IT weenie or the people who actually make money for the company.
Software Zen: delete this;
|
|
|
|
|
We must work for the same company.
|
|
|
|
|
Unfortunantly, I've heard of many, many companies with the attitude of "we have to withhold admin privs so we (IT) can justify our jobs. Then they dole them out when you beg.
|
|
|
|
|
Joe Q wrote: Then they dole them out when you beg.
We had a butthead here who used to do that. He was terminated with, shall we say, extreme prejudice.
Software Zen: delete this;
|
|
|
|
|
Unfortunantly, here, that's company policy.
|
|
|
|
|
Firstly, let me just say I understand the frustration that comes from waiting on the IT department to do small and mundane tasks that seem to be easy. I am the development manager for a large corporation with 30 developers, there are approx 1000 IT staff in the other sections such as Hardware and infrastructure. 12 years ago I used to think I knew more than the IT department, now, I know better.
There is a ever present problem in the corporate world and it’s called Rogue Programmers, to give you a bit of an idea of the kind of things we are dealing with here, we recently found a MS Access database that was built by a staff member who thought he could program better and knew more than the official IT developers. The Access database was over 2 GB in size and was used by over 250 people on the construction Project. This in turn was causing them major issues with bandwidth and using their mission critical programs (email, document library, accounting, procurement, etc). This Access database was used as a supplier register, of course one already existed but it was missing two fields, so rather than requesting them to be added and therefore benefitting the rest of the business (and other projects), this guy though he could do a better job, and instead pulled the infrastructure down for the whole project of over 5000 people.
This is a common story in all large and medium companies and we are finding at least one a month of these “Rogue” MS Access databases doing little jobs that could easily be put into larger already existing professional applications. The problem is, IT is governed by the business as a whole, we also have to consider other issues like bandwidth, backup, usability, redundancy, future growth and best for business practices. Whereas the Rogue programmer who always knows better (just ask him), only has to worry about the bright red and green colours that he is going to use to deface the program, and not only does he not think of the effects his program will have, he doesn’t understand them.
On top of all this is the data itself, if the program is used, then it is important and needed, therefore there is a good chance that the reporting of such data would be an advantage to the business, when we build any system we always ensure that the data is linked into our data warehouse where the BI tools are used to do full scope reporting and trending. This is critical to the business and our development of such, but yet again this is overlooked by the Rogue Developer.
If you think you can do a better job than the IT people, prove it, join them, change things from within, I will be the first to admit that many IT departments are run poorly or can be non productive with their processes, but the only way to improve them is to make them better. By being a Rogue programmer, you are actually justifying their poor performance, as the IT department only has to mention the problems your creating and the standards you are not adhering to and the argument is lost.
IT Departments are usually the life blood of a larger company, so you will never beat them, so you have to join them and improve them from within, this is what I did 12 years ago. Since then I have turned our department around and made it a success, sure it was a lot of work, but it was well worth it and very rewarding. But you either can do it or you cannot, so don’t pretend you know more when you don’t have to worry about the side effects of what you do.
|
|
|
|
|
Aymen 
|
|
|
|
|
We get that crap from our QA department. They track issues with either an Access 'application' or an Excel spreadsheet, even though we have an issue tracking app on the company intranet.
Frankly, I believe they do this to control engineering responses to issues, since they have to edit engineering's responses into the issues list. Needless to say, it never happens.
I've told my boss repeatedly we should refuse to acknowledge issues not posted into the company issue tracking application, but he's far more political than I am.
Software Zen: delete this;
|
|
|
|
|
Wow!
Normally, the QA department owns the issue tracking application. In your company, it seems to be the reverse.
|
|
|
|
|
The company issue tracking application is maintained by IT, of course. It is administered by our ISO9000-compliance folks. They're the ones who close issues once all documentation requirements are met to do so. Everyone in the company can participate in the process, and comment on or respond to issues. It actually works pretty well.
My complaint is with the QA yahoos. They steadfastly refuse to use the company app for development projects, even though the application explicitly provides a 'development' issue category. My personal belief is that they do this for political reasons, chiefly that they can control access and responses to their issue lists. They are then able to go into status meetings and claim that engineering is not responding to issues. How can we respond when the issue list is an Excel spreadsheet that sits on some twit's memory stick?
Software Zen: delete this;
|
|
|
|
|
nice one...
I like the QA strategy to excel in their field... 
|
|
|
|
|
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!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
