• (cs) in reply to Gosling
    Gosling:
    Markp:
    And even then, who's stopping anybody from using that horrific Java bug in their own, homegrown applet and pointing it at your server?

    The rules of how applets work, that's who. Can't open a socket to anything other than the webserver that delivered them.

    Even then, who's stopping anybody using any old DoS tools they fancy, and pointing them at your server? This is like a shop taking knives off their shelves so they can't be robbed at knifepoint

    The way I understand it, that certainly applies if you're running the applet in a browser, where a special security manager is used. But you could just as easily launch the applet outside of the browser, where you assertion doesn't hold. Of course, maybe that huge 200 bytes of traffic only happens in the environment where the applet is in a browser; I have no idea.

    But you got the gist of it, what I was saying is that client-side code doesn't typically get you anywhere in a DoS attack, because you can always write your own. The only time client-side code matters in a DoS is if it presents a vulnerability which allows an attacker to gain control of your system--and many others' systems--in the first place...something this particular applet clearly didn't seem to do.

  • Thomas (unregistered) in reply to Everything Guy
    Everything Guy:
    My experience has been that the server guys often (not always, but disturbingly often) know more about code than the coders
    In my 20 some odd years of development, I have never run into that situation. I've run into server guys that knew some scripting language stuff to automate their work. But I've never run into a dedicated server guy that was knowledgeable about modern development systems. Most server guys are tinkers but don't have the desire to learn how to code.

    In addition, typically dedicated developers make more than dedicated server maintenance guys with the rare exception being certain certifications.

    Being a server guy often involves writing code, which satisfies the server guy's inner coder and quells the desire to code full-time.
    I disagree. Obviously, this depends greatly on the type of servers being maintained. However, in the Windows world at least, most server guys rarely write code.
    If you, the coder, want the server guy to acquiesce to your every demand, no matter how expensive, feel free to handle the following consequent chores yourself:
    No one said that. Admittedly, the mistake here was not involving the server guys in the development process. However, that said, it is also the case that the server guys should involve the developer in maintenance and troubleshooting.
    * Figuring out which of the PHP scripts you wrote has been exploited and turned into a spambot. Some time later, learn about input validation. Or not - why deprive yourself of future fun?

    I've run into as many server guys as developers that didn't have the foggiest clue what input validation really meant.

    * Figuring out why a simple web+database app runs like a dog on a fully loaded (meaning any request for the server guys to "add moar hrdwr plzthx or I'll CC your grandboss and call you a roadblock" is futile) Sun Fire 15k (HINT: it MIGHT be that 7 page SQL statement that Oracle is busy with). As an aside, the app responsible for this was replaced by something that ran on a couple of vanilla Intel boxes. Ran fine.
    Or it could be the massive packet logging that some lunatic server guy put on the production servers which is dragging it down (true story). Or it could be 500 MB of RAM the server guy put on SQL Server (another true story). There are many ways to screw up a system.
    * Diagnosing the symptoms of a webserver with a full disk because you hardcoded OMGVERBOSE logging. It worked great in dev when you only had 5 requests an hour, amirite?
    Yep. I've also seen server guy do the same thing.
    Oh yeah - then there was that time I explained SQL injection to a dev (who is now a DBA) who at first advised me to "avoid entering single quotes" into a HR app.

    Nothing increases the odds of error more than incompetence. I ran into a server guy that claimed WINS was a security risk and couldn't explain why his network was stormed with broadcast traffic.

    Chances are any server guy with more than about 6 months experience has dealt with a busload of devs just like this.
    Chances are good that any developer that has had to deal with even one server guy has encountered an unreasonable nazi that thought he knew everything.

    In the end, development time almost always costs more than hardware. That is not an excuse for shotty code but it does explain why the push to upgrade hardware.

  • blunder (unregistered)

    So, you guys get in your five-minutes-IT-hate today?

    Nothing says "looking to get owned" like a public-facing Tomcat server.

    Sounds like the server guys should have been in charge of the hiring, too.

  • Caleb Jones (unregistered)

    Wow. Looks like a lot of server guys read this website. ;-)

    It all depends on how IT is structured in your business and how competent the different teams are (dev/management/it). If management and development competently decide that using a particular technology that has wide industry adoption is the way to go and they can produce a secure and solid solution, it is IT's job to support it. If the network infrastructure can't handle it, then fix the infrastructure. The infrastructure is, after all, only a tool. Sometimes even IT can be just as guilty in making irrational decisions due to emotional attachment to an infrastructure or certain way of doing things.

    Now, most of the problem comes from product and technology decisions being made without involving IT so that the product is "dumped" on IT and they are expected to deploy/support it w/o affecting the schedule or budget. IT should be involved from the project onset so that realistic costs and schedules can be created and everybody is on the same page.

  • (cs) in reply to DiverKas
    DiverKas:
    Where were the Server Guys when this stuff was being deployed on the development environment? Or QA? Or Implementation?

    Why werent the Server Guys in on the design meetings ahead of time?

    Probably not invited because they'd make things "complicated". Developers like to live in their own sweet world, and if a problem crops up in production, they just wash their hands of it and say "not my problem".

    TRWTF is nobody's read any BOfH...

  • Everything Guy (unregistered) in reply to Thomas

    [quote user="Thomas"] In my 20 some odd years of development, I have never run into that situation. I've run into server guys that knew some scripting language stuff to automate their work. But I've never run into a dedicated server guy that was knowledgeable about modern development systems. Most server guys are tinkers but don't have the desire to learn how to code. [/quote]

    If by "dedicated server guy" you mean "a server guy who never codes", then of course. You've basically No True Scotsman-ed your way out of that one. I know a lot of sysadmins and I don't know a single one who doesn't code (and I'm talking about more than 20 line automation scripts) and/or fix dev code.

    [quote user="Thomas"] In addition, typically dedicated developers make more than dedicated server maintenance guys with the rare exception being certain certifications. [/quote]

    That was not true anywhere I've worked, including before I had any certs, probably because all of the "server guys" needed a broader skillset.

    [quote] I disagree. Obviously, this depends greatly on the type of servers being maintained. However, in the Windows world at least, most server guys rarely write code. [/quote]

    Maybe that's true in the Windows-only world, I've never worked there. Most of the Windows servers that have been under the responsibility of me or my team have had VBS or other glue programs in various languages written by the server guys to make apps work the way management wanted them to.

    [quote] No one said that. Admittedly, the mistake here was not involving the server guys in the development process. However, that said, it is also the case that the server guys should involve the developer in maintenance and troubleshooting. [/quote]

    Agreed.

    [quote] I've run into as many server guys as developers that didn't have the foggiest clue what input validation really meant. [/quote]

    That says more about the incompetence of the devs you've run into than the reverse, since input validation is almost exclusively their responsibility. Server guys only need to know about this when they code or when they troubleshoot security incidents that occured because a dev dropped the ball.

    [quote] Or it could be the massive packet logging that some lunatic server guy put on the production servers which is dragging it down (true story). [/quote]

    ...which he probably put there to debug an app

    [quote]* Diagnosing the symptoms of a webserver with a full disk because you hardcoded OMGVERBOSE logging. It worked great in dev when you only had 5 requests an hour, amirite?[/quote] Yep. I've also seen server guy do the same thing. [/quote]

    I've seen server guy do it too, but in that case, server guy gets the 3 AM phone call to fix server guy's WTF. When dev guy does it he places an imposition on server guy.

    [quote] Nothing increases the odds of error more than incompetence. I ran into a server guy that claimed WINS was a security risk and couldn't explain why his network was stormed with broadcast traffic.
    [/quote]

    Well, strictly speaking, since WINS implies Windows... ;)

    [quote] Chances are good that any developer that has had to deal with even one server guy has encountered an unreasonable nazi that thought he knew everything. [/quote]

    Being the saviour a few times will give you a messianic complex, it's true. No, you can't have sudo because you really really want it. No, I won't flush all the firewall rules on this box to "just make it work". Why? Because I Have Root And You Don't.

    [quote] In the end, development time almost always costs more than hardware. That is not an excuse for shotty code but it does explain why the push to upgrade hardware. [/quote]

    And 3 AM server guy debugging time costs more than both.

    I understand the reasoning but it's so often misapplied...spending thousands of dollars so your java app cluster runs out of memory every 2 hours rather than 1 because your devs don't understand resource allocation is a classic false economy.

  • (cs) in reply to Ron Piler
    Ron Piler:
    2) Server guys are there to ensure the enterprise has adequate reliable server resources to do whatever it needs to. Not to dictate design decisions.

    Try telling that to the government department I work for/under. The department IT people seem to think the actual front line, core business sites are just there to annoy them. Anyone who points out a stupid decision is met with excuse, blame or rude comments. Lately the decisions have been harming the proper functioning of the thousands of sites, and the hundreds of thousands of staff who the IT department is supposed to be assisting.

  • (cs) in reply to Caleb Jones
    Caleb Jones:
    It all depends on how IT is structured in your business and how competent the different teams are (dev/management/it).

    Now I'm a developer (well, currently more like analyst/architect) and I read that last bit as /dev/management, like a Unix pseudo-filesystem. :)

    What's a bit worrying from the comments above is that it's a lot of "us against them". Are you sure that your developers and server guys are working at the same company?

    Within our company, at some point we had an exercise to come up with a generic set of non-functional requirements for all applications. This involved things like where configuration data is stored, meaningful exceptions, and it has evolved over time to dictate the name of web services, standard database configurations, etcetera.

    These non-functional requirements came from 'the server guys'; the document was written by 'the developers'. The end result is that the server guys spend a lot less time on stupidities, and by writing a standard set of libraries to implement those non-functional requirements, life has become easier for the developers as well.

    Everything, by the way, is written in Java. Everybody likes it that way, too.

    But the point is that as soon as you're thinking in terms of 'us' and 'them', you're on a trail that leads nowhere. Once everybody appreciates the work that the 'others' do, you'll see that everybody's job gets easier.

  • Bill S. Preston, Esq (unregistered) in reply to blunder
    blunder:
    So, you guys get in your five-minutes-IT-hate today?

    Nothing says "looking to get owned" like a public-facing Tomcat server.

    1. Nowhere does it say The Tomcat instance would be exposed to the outside world.
    2. If that was a geniune concern, the solution would be to hide it behind a well-secured Apache HTTPd or something. Easy enough to do.

    ITT: People believe Java is the root of all evil, based on endless straw arguments

  • saepius (unregistered) in reply to methinks
    methinks:
    "just in case they network the problems"

    this sentence no verb.

    ;o)

    FTFY

  • Bill S. Preston, Esq (unregistered) in reply to Bim Job
    Bim Job:
    Quasi-religious fervour and an unsupportable ad hominem attack.

    Glorious!

    For what it's worth: every time I've seen a Java applet, I've had to fix the inherent state machine myself -- despite intentionally avoiding Java since 1995.

    For what it's worth: every time I've had to interface with a Java program, or programs, I've been the one who has to solve environment issues, or JNI mappings, or classpath issues.

    I'm (sort of) sure it wasn't intended this way, but, in its current incarnation, Java just seems to me to be a lazy route to incompetent outsourcing, degenerate idiocy, box-ticking, and irrelevant process.

    Don't get me wrong. I'm all in favour of laziness, outsourcing, degeneracy, and a really good-looking box.

    It's the other stuff that depresses me.

    Good to see you raising my "unsupportable ad hominem" by one "broadly dismiss an entire industry based on a self-admitted utter lack of experience". Presumably the whole "enterprise computing" lark is just a fad, and we'll all be back on punch cards soon enough

  • (cs) in reply to Ron Piler
    Ron Piler:
    3) WTF was a new server needed for this anyway?

    The term server doesn't necessarily means as much as it used to do. Perhaps it was just a XEN client with a total of 256MB of allocated memory and just a puny little single core dedicated to it.

  • SoaperGEM (unregistered) in reply to jonnyq

    I have to agree with jonnyq's comment. The real WTF is why Hobson couldn't just work with what they had rather than insisting on adding a whole new server specifically for Java. It sounds more like Java was the only thing he ever bothered to learn, and he refused to learn anything else, even for remedial tasks like generating PDFs. The Server Guys said he could use PHP for that, which would have worked fine.

  • Everything Guy (unregistered)

    ITT: Negative experience with Java doesn't count.

    I dunno about you, but after I bang my head against a wall, say, half a dozen times, I try to move my head away from that wall.

  • EV (unregistered)
    1. How many hundred times per-second is "getResourceAsStream" being called while the applet is running? Absolutely no way the server guys would have even NOTICED if it was a mere, occasional 200 bytes...

    2. "redirect the XML"? WTF could that possibly mean? Inserting a blocking process, which will bring the whole order processing system down if the "dedicated server" for generating PDFs ever goes offline?

    3. A new, "dedicated server" for generating a few PDFs? Huge WTF! How many thousands of dollars in equipment, plus software, plus ongoing electrical, cooling, and maintenance costs?

    4. Is this dedicated Tomcat server going to be a completely different architecture than everything else on-site, that the server guys are going to be expected to secure, keep running 24/7 at all costs, patch, maintain, etc.? I'd be more than a bit upset in their place myself.

    5. "Despite the FTP storage backbone, Hobson and team were able to get the PDF transformer module up and running without an issue." The server guys must have made a good call!

    6. "fifty megabytes of memory"? Is this per-PDF? Maybe several years in the past when XML was new and memory was vastly more expensive than today? Or could the submitter be exaggerating just slightly to make his side sound better?

    TRWTF is these ultra-arrogant programmers who are just used-to getting their way, and tossing the long-term issues into someone else's lap, no matter how ridiculous the demand...

  • Thomas (unregistered) in reply to Everything Guy
    If by "dedicated server guy" you mean "a server guy who never codes", then of course. You've basically No True Scotsman-ed your way out of that one. I know a *lot* of sysadmins and I don't know a single one who doesn't code (and I'm talking about more than 20 line automation scripts) and/or fix dev code.
    Like I said, I've been doing development and maintenance work for a long time and in some cases for Fortune 500 companies. I have yet to run into a server guy that can code. By "dedicated" server guy, I'm excluding the jack-of-all-trades/resident expert guy that code primary systems and maintains the servers. That typically happens in smaller companies.

    This very well may be a difference in the Windows world from the non-Windows world.

    Thomas:
    In addition, typically dedicated developers make more than dedicated server maintenance guys with the rare exception being certain certifications.
    That was not true anywhere I've worked, including before I had any certs, probably because all of the "server guys" needed a broader skillset.
    In my years of experience, servers guys are generally mechanics. In all my years of development, I have only once ever run into a situation where any server guy made more than any of the developers and that was because he had a Cisco security certification. Again, most of my work has been in the Windows world, so that might mean the difference.
    Or it could be the massive packet logging that some lunatic server guy put on the production servers which is dragging it down (true story).
    ...which he probably put there to debug an app
    Nope. He was being nosy. Felt he was "compelled" to log every packet that went by.
    I've seen server guy do it[excessive logging] too, but in that case, server guy gets the 3 AM phone call to fix server guy's WTF. When dev guy does it he places an imposition on server guy.
    Only if they fess up to it which they typically don't.
    In the end, development time almost always costs more than hardware. That is not an excuse for shotty code but it does explain why the push to upgrade hardware.

    And 3 AM server guy debugging time costs more than both.

    Yes and no. First, you are assuming said downtime will occur. Second, I again come back to the fact that top developers are much more expensive, on average, than top server guys. Third, much more development is based on time and materials than server support. Thus, the cost of development is quite tangible. If server guy works eight hours or or fifteen hours, unfortunately, in today's society they do not typically get paid any different.
    I understand the reasoning but it's so often misapplied...spending thousands of dollars so your java app cluster runs out of memory every 2 hours rather than 1 because your devs don't understand resource allocation is a classic false economy.

    Can't argue there. Support and maintenance can break an app just as sure as the apps inability to fulfill the business need. The more people that use your application, the greater the factor that maintenance becomes.

    Like with all scarcity, it comes down to cost/benefit. Does the benefit of developers reducing the memory footprint from 50 MB to 25 MB outweigh the cost of simply upgrading the server? Doubtful.

  • (cs) in reply to SoaperGEM
    SoaperGEM:
    I have to agree with jonnyq's comment. The real WTF is why Hobson couldn't just work with what they had rather than insisting on adding a whole new server specifically for Java. It sounds more like Java was the only thing he ever bothered to learn, and he refused to learn anything else, even for remedial tasks like generating PDFs. The Server Guys said he could use PHP for that, which would have worked fine.
    Now I've been developing on quite a few platforms, starting in the early eighties, and your comment makes absolutely no sense.

    As a developer, it's good to know many platforms (I know... quite a few), but that the server guys would insist that the developers use PHP instead of Java, in other words, laying down that particular non-functional requirement, is outrageous.

    As a developer, you would have a pretty good idea of the strengths and weaknesses of each platform. The weakness of PHP, ASP and all those server-side scripting tools is that it's very easy to make a mess, and very difficult to maintain it if that happens. You can make a mess with Java as well (JSP comes to mind), but you have to try a bit harder.

    If the server guys don't have the capacity to run a JVM, they need more capacity, simple as that. They shouldn't be able to dictate a platform based purely on their own prejudice.

    It's like telling a Unix sysadmin: "You never bothered to learn Windows administration."

    If you want to dictate the platform, either become the business owner or the developer.

  • MikeL (unregistered) in reply to laoreet
    laoreet:
    So, they had some guys that wanted to keep their systems in mint condition, and a dev disagreed with them and therefor they are bad guys? How often do we not see cowboy devs chucking whatever they hacked together last on production servers and move on to the next great hack?
    Word.
  • IT-ILL (unregistered) in reply to Severity One
    It's like telling a Unix sysadmin: "You never bothered to learn Windows administration."

    If you want to dictate the platform, either become the business owner or the developer.

    Yes, it's a lot like that.

    Now say the app guys want to develop something in C#.NET. They could develop the same thing in Java, but their choice is C#.NET. Your sysadmins are all Unix guys. Sure, they could probably adapt to Windows ok, but with them, a Unix platform is always going to be more stable and more secure than the best Windows platform they could deliver.

    Do you hire some Windows sysadmins? How many? And what do you do with them if the project gets wound up? Is it going to cost more than developing the app in Java? Do you accept a the best effort at a Windows .NET production environment by a team of Unix guys?

    And what if all your servers are Suns? Do you now buy some Intels, ensure spare parts, get a new hardware support contract, skill your sysadmins up on this new line of hardware some of them will have never seen before (not that it should be hugely difficult but it is necessary), etc?

    Sysadmins should never unilaterally dictate the platform and expect the app guys to comply just for their convenience but neither should the app guys expect heaven and earth to be moved for theirs, and if your sysadmins are telling you it's not practical to expect the usual level of reliability in supporting your proposed platform, you should probably listen just in case they might know what they're talking about. Otherwise, you end up with a menagerie of different platforms that don't quite integrate, you have to go find That Guy who knows That One App - god forbid he ever leaves.

    There really is something to be said for standardizing platforms

  • SoaperGEM (unregistered) in reply to Severity One
    Severity One:
    If the server guys don't have the capacity to run a JVM, they need more capacity, simple as that. They shouldn't be able to dictate a platform based purely on their own prejudice.

    It's like telling a Unix sysadmin: "You never bothered to learn Windows administration."

    If you want to dictate the platform, either become the business owner or the developer.

    In your magical utopian organization where developers are in charge and get to dictate to the Server Guys as well as the business owner making the financial decisions that they should purchase more servers with higher capacities, add new technologies that the business just hasn't needed until you showed up, and get all of the latest programs and platforms right away, maybe...

    But back here in the real world, often what makes for a better developer is someone who is versatile and willing to work with what they're given. Being inflexible, asserting that "it absolutely MUST be done in language X at any expense!" is the kind of attitude that may leave some searching for a job.

    And with the recent economic downturn, what if your Unix admin has been out of a job for awhile and really needs work, so applies at place where everything is hosted on Windows servers? Then your response in quotes sounds a bit different, doesn't it?

  • Thomas (unregistered) in reply to SoaperGEM
    But back here in the real world, often what makes for a better developer is someone who is versatile and willing to work with what they're given. Being inflexible, asserting that "it absolutely MUST be done in language X at any expense!" is the kind of attitude that may leave some searching for a job.
    Granted, going off the reservation of the platforms in use at company is bad business. However, typically the pressure to deviate comes only partially from the developer and instead primarily from the business stakeholder. "I want this right now!" The developer says something to the effect of "I can whip this out quickly in XYZ but you guys don't have XYZ here." The more clout the stakeholder has, the more of heaven and earth get moved.
  • EmperorOfCanada (unregistered) in reply to EmperorOfCanada

    Three key elements that I left out of this story were: One I was hired with an IT overhaul in mind. A number of top non-tech employees (it is not a tech company just highly tech reliant) had quit due to IT getting in their way. Second, just before I started the company hired one of the big accounting consulting firms to audit the company (revenue generated per each employee and so on) and the auditors put at the top of the list that IT was a liability as it stood. And third I spend the week before starting reading various relevant stuff such as exit interviews and the numerous (3+ per day) emails that the IT heads sent out to staff. Recent IT policies included: Staff may not have personal emails at home. They would be given a company email for personal use. Updates to the company website must have a 3 week "cooling off period" and this would include text changes. No USB keys, smart phones, PDAs or MP3 players were allowed on the company property as they all posed a security risk. But even the CEO didn't understand what was at risk here. As he put it the only thing that might be vital was the customer list and it was short and easily printed. My determination was that the top IT guys were old Novell guys and were genuinely scared of things blowing up in their faces. But the upper management were too scared to try to change things as the IT people had them convinced that the world would end without their heroics. Basically they were in charge of a web server (I outsourced this) an email server (I outsourced this) the network, and keeping people's machines working. So with the 6 Novell guys gone the new staff jumped in and upgraded us from dual ISDN (WTF) to a real network, put in a modern firewall, switched us to exchange (not my favorite but the marketing guys really wanted it plus the hosting is not bad) replaced the unencrypted wifi, and since then have upgraded nearly every computer in the building. They have tested backups coming out their ears and for the first time in company history have finally released a working piece of internal software that, while simple, has basically been orgasms all around. I think an all around success; other than the unsuccessful lawsuit by the second highest IT guy because we refer all employment checks to a lawyer. I think it is all summed up by the average length of a help desk ticket remaining open being reduced from 14 weeks to 1 day (this number is skewed by a few back ordered parts and some tickets opened at the end of the day.) It took them two weeks once to replace a ruined keyboard. They tried to cause trouble for the employee because after a few days the employee bought her own keyboard.

    Oh and just for the record I have seen worse IT departments. Or at least IT departments acting in more despicable ways. Generally it has been my experience that IT departments don't get credit for things not going wrong and blame for when it does. So they develop policy after policy that cover their asses from any possible risk. What they generally lose site of is that most IT departments are not that important to the company. Keep the network running, the viruses out, and the printers printing but otherwise keep the hell out of the way of those who are generating revenue. So when someone says "I need program X installed." The first response should not be oh program X will cause us some problems so "No!"; the first response should be: how can we quickly install program X without causing ourselves pain. If there is some serious problem with program X then you submit the issue to the manager of the employee and say "Program X will take 8 hours to run a separate network to that employee's desk so that we will continue to have a smoothly running network. Is Program X worth the effort?" As opposed to the usual IT tactic of saying something like "Program X will corrupt other packets on the network ending the world as we know it. Scare scare scary scare."

  • Mook0wz (unregistered)

    lol, let me tell you guys about my WTF:

    I walk into a company 3 years ago and the first thing I encounter is this:

    Dim intAccountId intAccountId = Request.QueryString("accountId")

    rs.Open "SELECT * FROM god_awful_accounts_table WHERE reallyLongAnnoyingAccountIdFieldThatDoesntFollowNamingConventions = " & intAccountId, oConn

    still dealing with the same BS today. Tried to educate, implement, and otherwise encourage change, but we don't even have a system in place for checking to see if devs actually know their stuff. Our manager knows less then most of the devs, and if we implement something he doesn't understand, it gets tossed out the window. Only reason i'm still working there is the pay. The job sucks balls.

  • hoodaticus (unregistered) in reply to SR
    SR:
    TRWTF is a Java Applet and an XML solution so close together. To me that smells of using Java applets way past their sell-by date.

    Do you have a free XSL:FO > PDF renderer that ISN'T Java? Please, I would love to know.

  • hoodaticus (unregistered) in reply to Mook0wz
    Mook0wz:
    Our manager knows less then most of the devs, and if we implement something he doesn't understand, it gets tossed out the window. Only reason i'm still working there is the pay. The job sucks balls.

    That is the 9th Circle of Hell. I'm sorry for you bro. I just quit a developer job because my ideas kept getting thrown out. Why? IT couldn't "maintain the application". Why? IT manager doesn't know how to program.

  • NuCode (unregistered)

    Uhm, Java on web orientated stuff? This kind of hacks?

    If i were the Server Guy, i would not approve anything, under any circumstances by Hobson. Java is the worst idea ever for web orientated task 99.98% of the time.

    Why? It's the slowest development cycle ever, results in very slow and hard to maintain system and very bloated application.

    PHP + AJAX is a good solution most of the time. RoR for rapid prototyping, Flash for small interactive appliances (and i do really mean small and simple. For complex you can use Flash for sound, PHP + AJAX for the UI).

    I say the Real WTF is how messed up that organization is in their IT, they are poised for failure.

  • Everything Guy (unregistered) in reply to EmperorOfCanada
    EmperorOfCanada:
    Three key elements that I left out of this story were: One I was hired with an IT overhaul in mind. A number of top non-tech employees (it is not a tech company just highly tech reliant) had quit due to IT getting in their way.

    Right. Now bear in mind what you go on to write later in your post:

    EmperorOfCanada:
    Generally it has been my experience that IT departments don't get credit for things not going wrong and blame for when it does. So they develop policy after policy that cover their asses from any possible risk.

    Why didn't you attempt to address this attitude? What do you think is going to happen the first time something big goes wrong with your shiny new outsourced heroes? Low rights and high responsibility is a recipe for high turnover. What's that going to cost you?

    EmperorOfCanada:
    Second, just before I started the company hired one of the big accounting consulting firms to audit the company (revenue generated per each employee and so on) and the auditors put at the top of the list that IT was a liability as it stood.

    Oh, because they always understand IT. I have seen enough retardation come from Big Auditors to staff several sheltered workshops. Did you realise that running Free Software is a security risk? OMG

    EmperorOfCanada:
    My determination was that the top IT guys were old Novell guys and were genuinely scared of things blowing up in their faces.

    See above, re: rights and responsibilities. They likely stayed on because old Novell guys are hard to employ elsewhere.

    EmperorOfCanada:
    What they generally lose site of is that most IT departments are not that important to the company. Keep the network running, the viruses out, and the printers printing but otherwise keep the hell out of the way of those who are generating revenue.

    All of those things (and a whole bunch of things you omitted) are vitally important to generating revenue. So is, occasionally, interfering with those who are generating revenue. If some shortsighted marketdroid decides he wants to spam everyone and his toaster with our new product catalogue and hasn't cleared it with me, you'd better believe I'm going to break out the kill -9 hammer first and ask (rather frankly worded) questions later. Otherwise, we get blacklisted everywhere, nobody can email a good percentage of your clients, and it doesn't get fixed, potentially, for days. What do you think that does to revenue?

    You hire IT people because, in essence, you don't know how it works, and you need it to work to make money. If you take away all of their autonomy and treat them like computer janitors you will end up making more excrement that needs mopping up. Also, see rights:responsibilities.

    EmperorOfCanada:
    So when someone says "I need program X installed." The first response should not be oh program X will cause us some problems so "No!"; the first response should be: how can we quickly install program X without causing ourselves pain. If there is some serious problem with program X then you submit the issue to the manager of the employee and say "Program X will take 8 hours to run a separate network to that employee's desk so that we will continue to have a smoothly running network. Is Program X worth the effort?" As opposed to the usual IT tactic of saying something like "Program X will corrupt other packets on the network ending the world as we know it. Scare scare scary scare."

    See above blame:praise ratio quote.

    It would be fantastic to be able to create secure environments to run risky applications. The problem is, this means more time and money (and omg IT is such a cost centre!!1one), so it gets shot down by managers, who yell "JUST MAKE IT WORK! MY BUDDY AT [corp] SAID THEY GOT EXCHANGE IN 2 DAYS!" (of course, his buddy didn't want to mention the resulting outages..) and blather on about all the helpdesk tickets you can't respond to in that time.

    Oh, and even if you're completely, 100% correct about all of that, and I'm completely wrong, you're still a textbook sociopathic prick of a boss for firing someone on the spot for following policy. Sooner or later, bosses like you get it in the neck.

  • Coward (unregistered) in reply to Kermos

    Shut-up grand paw ;)

    Kermos:
    (snip) the server guys were doing actually a pretty decent job at ensuring security and keeping resource abuse down. Too many developers these days treat memory as if it is a limitless resource (snip)

    Applications should be as bloated as possible how else will AMD and Intel keep forcing the need for upping processor power?

  • Someone like Kevin (unregistered) in reply to Mook0wz
    Mook0wz:
    I walk into a company 3 years ago and the first thing I encounter is this:

    Dim intAccountId intAccountId = Request.QueryString("accountId")

    rs.Open "SELECT * FROM god_awful_accounts_table WHERE reallyLongAnnoyingAccountIdFieldThatDoesntFollowNamingConventions = " & intAccountId, oConn

    Hey, at least they have Option Explicit turned on.

  • Charles Mcnider (unregistered)

    That is some pretty useful information on xsl-fo. Thanks for your research. I shall put it to work immediately.

Leave a comment on “The Server Guys”

Log In or post as a guest

Replying to comment #:

« Return to Article