• Drew (unregistered)

    I'd post the first comment, but I'd have to run it by my server team first.

  • Ouch! (unregistered)

    Well, so what? 640k ought to be enough for anybody.

  • SR (unregistered)

    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.

    (The boss used to do the web site for a largish PC vendor and I still take the piss out of the applet that was on their site about 10 years ago.)

    CAPTCHA: appellatio - a blow job in an orchard?

  • Addison (unregistered)

    What? Server guys who don't understand anything but server issues and just go around trying to make their lives as easy as possible? I've never heard of such a thing!

  • laoreet (unregistered) in reply to SR

    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?

  • noone (unregistered)

    just in case they network problems

    lol

  • Cory A (unregistered)

    Have to agree on this one, this isn't really so much a WTF as it is Business as Usual. Now, in most shops a call to a Supervisor and a logical explanation can overrule the Server Guys, but not always. In some shops, and I would dare say a lot of shops, the Server Guys are given some godlike powers. Basically, it's because they are usually smarter than the manager that is supposed to be supervising them.

  • (cs) 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.

    (The boss used to do the web site for a largish PC vendor and I still take the piss out of the applet that was on their site about 10 years ago.)

    Java people, unfortunately, like their XML.

  • ab (unregistered)

    The real WTF: [image]

  • (cs) 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?
    The servers would be in perfect condition if they didn't have to run those pesky client apps.
  • Not-Here (unregistered)

    Sounds to me like the dev guys were rolling out software into live without doing sufficient testing.

  • (cs)

    They wanted a dedicated Java server to transform XML to a PDF? Seriously? No wonder the server guys said no. I'd say no. Apparently the server is already running PHP, and there are PHP libs perfectly capable of creating PDFs or even transforming XML to PDF via XSL-FO or other things.

    Also, I'm not crapping all over the use of a Java applet to query orders, but seriously? Is that all the applet did? Why is that better than a simple web form with some javascript on it even? Now the Server Guys' reaction smacks a little of dissing things they don't understand, but I just can't imagine writing a Java applet to do something easily done without Java.

    Sounds like a good story could be told about from a server guy's perspective about the pesky Java-happy developers that kept needing extra resources to do simple things.

  • DiverKas (unregistered)

    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?

    WHY ARE SILOS STILL ALLOWED TO EXIST TODAY?

    Ugh.. still, the only WTF is all the Java lovin going on.

  • Inhibeo (unregistered) in reply to DiverKas
    DiverKas:
    WHY ARE SILOS STILL ALLOWED TO EXIST TODAY?

    They come in handy when you have a lot of grain that you want to keep dry.

  • Anonymous Coward (unregistered) in reply to Inhibeo
    Inhibeo:
    DiverKas:
    WHY ARE SILOS STILL ALLOWED TO EXIST TODAY?

    They come in handy when you have a lot of grain that you want to keep dry.

    Or Tiberium you want to keep safe...

  • Downfall (unregistered)

    Good god. It's a truly epic WTF when it's obvious that the party who believes he is the WTF-ee is actually the WTF-er. I'd buy a beer for the server guys any day.

  • (cs)

    I don't really see a WTF here either.

    Sounds to me like 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 and there are too many stories about excessive hardware being thrown at exceedingly simple problems.

    Even the FTP I don't see an issue with as it abstracts the data storage. This way if the data ever needs to be stored on a different machine all is needed is a change of IP address.

  • (cs)

    I....I'm just stunned. To think that these guys were THAT draconian about system resources...

    Wow.

    Addendum (2009-09-08 10:12): Edit: I didn't mean about the dedicated server bit, but being that they went that crazy about 50MB of RAM is a bit overboard. I understand about the rest though.

  • Rodnas (unregistered) in reply to Kiss me I'm Polish
    Kiss me I'm Polish:
    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?
    The servers would be in perfect condition if they didn't have to run those pesky client apps.

    Or hooked up to some fancy-schmansy network. (i.e. internet or LAN)

  • Warren (unregistered)

    "Once the order is successfully received, the customer receives an email confirmation their order."

    I think one word that sentence is missing.

  • blah (unregistered) in reply to Kermos
    Kermos:
    Even the FTP I don't see an issue with as it abstracts the data storage.
    FTP is a godawful protocol and a security hole.
  • Federico (unregistered) in reply to Downfall
    Downfall:
    I'd buy a beer for the server guys any day.
    I agree. A dedicated server and 50 MB of memory just to convert a few lines of text into PDF? I'd *love* working in a shop where someone with a solid technical backgroung is granted the power to reject poorly designed applications.
  • Bananaman (unregistered)

    Without knowing the typical system load, it's pretty arrogant to call this a WTF. Sure, the Server Guys' architecture using FTP is archaic, but moving the PDF conversion out of the main path of the order processing isn't a bad thing. If they only have that single path (and it's not hiding a load-balanced system), there's a possibility that generating the PDFs for each order will overwhelm the system, causing delays in order processing or dropped orders, or annoyed customers that just go somewhere else.

    Now, that assumes that the current system is running close enough to capacity for the pdf conversion to be a problem, or that the company is growing fast enough for it to be a problem in the lifetime of the app, none of which we can know from the WTF description. But rather than work with the Server Guys to come up with a mutually beneficial solution, we just perpetuate the Us vs. Them mentality that ultimately screws everyone over.

  • Anonymous Organ Donor (unregistered) in reply to blah
    blah:
    Kermos:
    Even the FTP I don't see an issue with as it abstracts the data storage.
    FTP is a godawful protocol and a security hole.

    What if you were to disallow all access to the FTP server save local access?

    Essentially you're locking the website down to a specific directory, and potentially only allowing access from one system - removing all permissions save "put stuff here". FTP isn't the most friendly of services, it doesn't have the powers, but it does lock everything up nicely if implemented properly.

    I'd like to read the WTF from the server guys perspective... and the things that came before this example (OK, so this wasn't bad, but there must have been some interesting samples to create such a knee-jerk reaction).

  • Lod (unregistered)

    Sound to me like the server guys are just keeping the devs in check, maybe a bit overboard, but still an important role that too often is not filled.

    Situation #1 seems to put the WTF on the server guys side (there may be additional details as we are getting only 1 side of the story here). But situation #2.. a dedicated server? WTF on the silly dev. The dev may not understand this, but servers are not free. Adding a server is not an easy solution to much of anything. They cost many man hours to deploy, maintain, secure, monitor, patch, upgrade, etc.

  • (cs)

    It's hard to tell if the pro-server guy's are trolling, or serious... and that's sad.

  • Tempura (unregistered) in reply to Federico
    Federico:
    Downfall:
    I'd buy a beer for the server guys any day.
    I agree. A dedicated server and 50 MB of memory just to convert a few lines of text into PDF? I'd *love* working in a shop where someone with a solid technical backgroung is granted the power to reject poorly designed applications.

    Well, running-time is cheaper than working-time. If the busty solution is faster developed and easier to maintain, why not?

    I think the real wtf is, the developer- and server-team don't work together.

  • Paul Gee (unregistered)

    The real WTF is most definitely the ability of the developer to deploy his code to a production environment without any apparent approval process.

    As a developer myself, I know it can be a pain in the buttocks to jump through the hoops when it's your code but when you're on the receiving end of someone else's rubbish time and again, you realise the need for it.

    Only the other day I found that someone from another company had deployed to a client's production environment and caused all sorts of IIS-related knock-ons in our application - for example, enabling anonymous access through IIS to a series of databases.

    The worst thing about that particular situation is that "The Server Guys" at the client didn't stop the deployment before it even got into its tracks. I should also mention that it was an in-development product they deployed, which made it even worse.

  • (cs)

    The WTF I see is their bull about using the Java VM issue to perform a DOS. Sure, that would be one way to do it, but if you had the resources to pull off a DOS, why would you use some hard-to-reach, tiny request instead of just making large requests using just about anything else? And even then, who's stopping anybody from using that horrific Java bug in their own, homegrown applet and pointing it at your server?

  • (cs) in reply to Kermos
    Kermos:
    I don't really see a WTF here either.

    Sounds to me like 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 and there are too many stories about excessive hardware being thrown at exceedingly simple problems.

    Even the FTP I don't see an issue with as it abstracts the data storage. This way if the data ever needs to be stored on a different machine all is needed is a change of IP address.

    You almost had me there, but the part about FTP abstracting data storage gave it away. Good effort though, you're almost at Top Cod3r level.

  • blah (unregistered) in reply to Markp

    Java is a DoS all right... on the client machine.

  • (cs) in reply to Paul Gee
    Paul Gee:
    Only the other day I found that someone from another company had deployed to a client's production environment and caused all sorts of IIS-related knock-ons in our application - for example, enabling anonymous access through IIS to a series of databases.
    How is this even possible? SQL doesn't allow anonymous access. Do you mean that the site allows anonymous access, and connects to a database on the back-end.... like just almost every other web site on the planet?
  • (cs) in reply to Bananaman
    Bananaman:
    Without knowing the typical system load, it's pretty arrogant to call this a WTF. Sure, the Server Guys' architecture using FTP is archaic, but moving the PDF conversion out of the main path of the order processing isn't a bad thing.
    Looking at the diagram it doesn't appear that the PDF would have been in the main path.

    I don't understand the people who claim not to see a WTF. "The Server Guys explained: directly writing to the disk of a machine which hosts such an important process (converting XML to PDF) is far too dangerous." The first mention of writing to disk that I see is when they introduce an FTP transfer.


    Submission attempt 3.

  • Wendy (unregistered) in reply to Vechni

    No not trolling.

    So okay, it's a little on the hardcore-protective side. But I would much prefer the server guys be overzealous as in this case, than just let anything fly if a developer thought it was a good idea - and backed it up with "but that's no big deal".

    I have seen servers go down because of much smaller 'errors' than those listed here.

    Even if you have a dedicated server, you don't want it going down, when you can make sure it won't with a small workaround.

    Hat-off to the server guys!

  • RBoy - a Server Guy (unregistered) in reply to Drew
    Drew:
    I'd post the first comment, but I'd have to run it by my server team first.

    Denied, 2mny lttrs. Uses 2mnr rsrces.

  • (cs) in reply to Markp

    The real WTF is their wired.com grade education on how DoS works... and how networks operate in general.

    Their DoS argument was that the app was attracting too many users and therefore was going to DoS them. Which is like saying we shouldn't have a website, as it presents an inadvertent user-based DoS security risk. How anyone can begin to side with that team is beyond me and apparently beyond the reading comprehension level here!

  • Mason Wheeler (unregistered)

    TRWTF here is that this is the first "daily" update in 4 days.

    Second post attempt...

  • MyName (unregistered)

    TRWTF is all of the typos. Doesn't anyone proof-read these things?

  • anon (unregistered)

    To the defenders: even if the draconian responses here were considered valid in some way, yanking a customer facing application from the server without warning is a WTF of magnificent proportions. I could care less what lead to this point (though there's probably many WTFs there as well), but this act alone should cause dismissal of the "server guys" and an immediate change in the "server guys are king" policy.

  • Anonymous (unregistered)

    Damn, the second diagram looks awfully similar to a f-ed up design I tried to prevent from being implemented last week. One of the server guys must be working on my team now.

  • (cs) in reply to Mason Wheeler
    Mason Wheeler:
    TRWTF here is that this is the first "daily" update in 4 days.

    Second post attempt...

    Well, first we had what is called a weekend. A lot of daily things don't actually happen at the weekend either. And secondly I believe there was a national holiday in the US. Labour Day, I think it was. That's also a day when things that normally happen, don't. So TRWTF is your lack of patience. There's always the side bar you could post in.

  • James (unregistered)

    This sounds exactly like the way our government operates most of its IT. I've experienced even worse horror stories working with our wonderful government's Small Business Administration.

    These situations are a whole lot more prevalent than most would like to admit. As was said before, "Server Guys" are given god-like powers throughout the organization, and in some specific cases (like the SBA), they can even dictate BUSINESS PROCESSES simply because they refuse to or enforce supporting of certain applications. The departments that are doing the actual work are sometimes required to break their own regulations and codes because of the "Server Guys". It's a complete nightmare, and probably worthy of a WTF submission.

  • Federico (unregistered) in reply to Tempura
    Tempura:
    Federico:
    I'd *love* working in a shop where someone with a solid technical backgroung is granted the power to reject poorly designed applications.

    Well, running-time is cheaper than working-time. If the busty solution is faster developed and easier to maintain, why not?

    Hi, in my experience rarely was the faster developed solution followed by the easier mainteinance, but YMMV.

    Tempura:
    I think the real wtf is, the developer- and server-team don't work together.

    Well, yes!

  • (cs) 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?

    Reading comprehension man. Assuming the story is true to the letter, could you please explain what of the solutions developed/proposed by the dev team stopped or threatened the server guy's ability to keep the servers in mint condition (* more on that below).

    Furthermore, can you please explain why the server guy's ftp-based solution is cleaner and easier to maintain than the one suggested by the dev team?

    laoreet:
    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?

    Anecdotal evidence much? Can you put an objective number to the problem you are describing here?

    I've worked several hats - developer (Java, FoxPro, VB, Perl/Shell script and what not); software architect; WebLogic Admin; *nix/Linux SysAdmin; Tier II/III Support. With that experience I can tell you this:

    It goes both ways. Indeed there are dev teams who compromise production systems with their hacks or with their desire to try the latest app container, crap that almost gave me an embolism at several times.

    Indeed it is also the case of clueless server guys who stomp on legitimate development needs. They see any developmental change as a threat to server integrity as opposed to a solution to a particular business problem. It is worse when they attempt to dictate how applications are not how to be deployed but to be written.

    C'mon, this wtf is an example of the later (not to say that implementing an applet for the first problem discussed was the way to go.)

    You got to look at these things objectively and technically. If that was the common modus operandi of these server guys, then they are incompetent empowered by process loopholes.

    Server guys (I being one of them many a time) exist to keep servers in mint conditions so that they solve existing and future problems.

    There are legitimate concerns to keep things unchanged, but in my experience, many server teams use the "keep the servers in mint condition" as a cop-out to keep things the same and reduce their workload, even if it means denying the implementation justifiable (and sometimes critical) solutions to business problems.

  • Ron Piler (unregistered)
    1. The teams should be communicating. Nobody should reach production and then discover they're not allowed to deploy.

    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.

    3. WTF was a new server needed for this anyway?

  • (cs) in reply to James

    haha - how many times as a developer, that you have to put in 100's of hours extra work, costing huge amounts of money per hour - butchering good design and maintainability at the mantle of relatively pointless optimisation - all so that the hardware guys don't have to spend £50 upgrading their machine's RAM to cope. You'd think they'd love an excuse to make their machines better... :)

    Don't get me wrong, I understand the need to fix bad design that causes apps to be stupidly resource hungry - that is perfectly sensible. But much of the time spent on optimisation doesn't justify the opportunity cost.

  • PleegWat (unregistered)

    Those design diagrams are a good example of 'an image says more than 1000 words':

    • 100 for the dev
    • 100 for his manager
    • 100 for his PM
    • 100 for the guy writing the testcase
    • etc

    Now if only those were the same 100 each time

  • Ron Piler (unregistered) in reply to Cro
    Cro:
    haha - how many times as a developer, that you have to put in 100's of hours extra work, costing huge amounts of money per hour - butchering good design and maintainability at the mantle of relatively pointless optimisation - all so that the hardware guys don't have to spend £50 upgrading their machine's RAM to cope. You'd think they'd love an excuse to make their machines better... :)

    Don't get me wrong, I understand the need to fix bad design that causes apps to be stupidly resource hungry - that is perfectly sensible. But much of the time spent on optimisation doesn't justify the opportunity cost.

    I don't think I've had to do that for a long time. "Throw more hardware at it" is a perfectly valid response these days

  • Georgem (unregistered) in reply to Cro

    I remember in a previous job being told that we weren't allowed to "install any software that uses comms" on our laptops. Which instantly disbarred all developers from ever developing any of the products we were developing.

  • Georgem (unregistered) in reply to blah
    blah:
    Java is a DoS all right... on the client machine.

    Just as well it was running server-side in the second part of the WTF, then, isn't it. Also, you're talking bollocks. Don't believe everything you read in "VB Hackers Monthly"

Leave a comment on “The Server Guys”

Log In or post as a guest

Replying to comment #284527:

« Return to Article