• The Zune Man (unregistered) in reply to PedanticCurmudgeon
    PedanticCurmudgeon:
    Matt Westwood:
    Better still, the Summoner in Chaucer's Canterbury Tales who IIRC was a syphilitic pederast. And of course his buddy the Pardoner, who "I believe was a gelding or a mare". Perhaps it was they who programmed this - but then again, back in the 14th Century they would have used FORTRAN.
    Why not Perlingata?
    Why not Genitalia?
  • (cs) in reply to PedanticCurmudgeon
    PedanticCurmudgeon:
    Matt Westwood:
    Better still, the Summoner in Chaucer's Canterbury Tales who IIRC was a syphilitic pederast. And of course his buddy the Pardoner, who "I believe was a gelding or a mare". Perhaps it was they who programmed this - but then again, back in the 14th Century they would have used FORTRAN.
    Why not Perlingata?
    +XVIII Pro Victorio
  • Zwha (unregistered) in reply to Ken B.
    Ken B.:
    ObiWayneKenobi:
    What boggles the mind is how somebody can't understand things put in plain terms: Not "good code" and "bad code" but more like "If we take x longer, we can easily add features in the future and have better maintenance" and "If we crank it out immediately, new features are going to be very hard to add and the application is going to be very poor longterm." Again, I'm not a business major but that seems like a cut-and-dried approach, yet most managers will choose the second option instead of the first.
    The problem is the "plain-English-to-bean-counter" translation of the above is:

    "I can spend time and money now to save even more time and money in the future. Or... I can look like a hero by saving time and money now and let the next guy worry about the higher cost down the road."

    And they have immunity - Any issues delivering are because of problems they inherited from their predecessor, while (in the rare situation) any success in the project after they leave (such as something actually getting done) is a direct result of their legacy to the project.

    I suspect (to be a little fair) that the problem is often the client/user not the manager. Irrespective of how far ahead the manager can see, it is always difficult to convince business stakeholders that more cost now can ever be a good thing. Wasting their current budget is wasting their current budget - the potential to save on budget later is irrelevant (perhaps TRWTF are budgets - 10 months being a tight arse and spending no money, then 2 months trying to blow the budget by as much as possible to guarantee that you'll get a similar allocation the following year - or maybe that's just Governmnet).

  • (cs) in reply to Zwha
    Zwha:
    Ken B.:
    ObiWayneKenobi:
    What boggles the mind is how somebody can't understand things put in plain terms: Not "good code" and "bad code" but more like "If we take x longer, we can easily add features in the future and have better maintenance" and "If we crank it out immediately, new features are going to be very hard to add and the application is going to be very poor longterm." Again, I'm not a business major but that seems like a cut-and-dried approach, yet most managers will choose the second option instead of the first.
    The problem is the "plain-English-to-bean-counter" translation of the above is:

    "I can spend time and money now to save even more time and money in the future. Or... I can look like a hero by saving time and money now and let the next guy worry about the higher cost down the road."

    And they have immunity - Any issues delivering are because of problems they inherited from their predecessor, while (in the rare situation) any success in the project after they leave (such as something actually getting done) is a direct result of their legacy to the project.

    I suspect (to be a little fair) that the problem is often the client/user not the manager. Irrespective of how far ahead the manager can see, it is always difficult to convince business stakeholders that more cost now can ever be a good thing. Wasting their current budget is wasting their current budget - the potential to save on budget later is irrelevant (perhaps TRWTF are budgets - 10 months being a tight arse and spending no money, then 2 months trying to blow the budget by as much as possible to guarantee that you'll get a similar allocation the following year - or maybe that's just Governmnet).

    You said a mouthful there. Managers are bad enough, but politicians are usually just amateur, not-very-good managers with narcissism.

  • Gunslinger (unregistered)

    So, what ended up being the problem then?

  • Herby (unregistered)

    "Elder Scrolls"??

    To me it looks like the Dead Sea Scrolls, without any meaning. They should be dead soon. Look, even writing this in FORTRAN would result in better code!

  • gmoney (unregistered) in reply to ObiWayneKenobi
    ObiWayneKenobi:
    Are managers that stupid to not understand the difference between short-term and long-term, and that long-term is what really matters for a business? That's freaking Business 101.

    Where I work they want it all, is basically the problem. Lack of staff, time, resources is for you to sort out. If you can't and can't deliver, it is YOUR problem, not theirs. In such an environment such questions as long term aren't really considered. As long as x is delivered it is assumed (hoped) all is great.

    You and I know there are limits to what a team can produce in terms of cost/quality/time. If you reduce cost and time, well quality isn't exactly going to increase. Higher ups want less cost in particular, putting pressure on quality and time (resources). If you can't deliver that is your problem for not trying hard enough.

  • Summoner (unregistered) in reply to Palad1
    Palad1:
    Ladies and gentlemen, we've found it:

    The Client-Side Stored Procedure!

    Niiiice!

    So far so good...

  • Forumtroll (unregistered)

    It is quite obvious this is a Java developer gone rogue (to C#).

    God have mercy on his soul.

  • (cs) in reply to Matt Westwood
    Matt Westwood:
    Better still, the Summoner in Chaucer's Canterbury Tales who IIRC was a syphilitic pederast.
    I thought there wasn't any reliable record of syphilis until about 1495, whereas the Canterbury Tales are from 100 or so years earlier. The summoner was only afflicted with boils, which can have many other causes. (Causality: even with neutrinos it's awkward to spin this!)
  • (cs) in reply to NuclearRampage
    NuclearRampage:
    Sounds like standard operating procedure of a typical terribad India code sweatshop.
    Nagesh:
    I speek with my manger and he tell me it is more important to meke delivery of project before time. Noting else maters.

    You hv lot of missconceptons.

  • mjk340 (unregistered) in reply to gmoney
    gmoney:
    ObiWayneKenobi:
    Are managers that stupid to not understand the difference between short-term and long-term, and that long-term is what really matters for a business? That's freaking Business 101.

    Where I work they want it all, is basically the problem. Lack of staff, time, resources is for you to sort out. If you can't and can't deliver, it is YOUR problem, not theirs. In such an environment such questions as long term aren't really considered. As long as x is delivered it is assumed (hoped) all is great.

    You and I know there are limits to what a team can produce in terms of cost/quality/time. If you reduce cost and time, well quality isn't exactly going to increase. Higher ups want less cost in particular, putting pressure on quality and time (resources). If you can't deliver that is your problem for not trying hard enough.

    I've seen managers that are receptive to taking time to build extensible, maintainable code, get burned over and over again. Since the manager is not intimately familiar with the details of the problem, they have to trust the developer when the developer asks for more time to make something better.

    The problem is that unless you work for a tiny company with intimate hiring practices, chances are 80% of your coworkers are terrible and will spend a week 'optimizing' something that ends up running more slowly and more bug ridden when they are done. After the manager gets burned enough times letting the developers work on 'science projects' that have no immediately perceived benefit to the deliverable, they start to react by saying 'NO' to everything by default.

    There are two ways for Joe Developer to get around this issue. One way is to gain the respect of your manager as a get-shit-done kind of guy, so he respects your opinion when you say you need another day to clean things up.

    The other way is to effectively communicate the problem to the manager, and then SELL the fix to him in terms he can understand. "If we fix this function right now, we can use it again on the contract that was just signed and pull that schedule up by a week." If you can't think of a way to sell the fix, accept the fact that the existing code is good enough to get payment from the customer and keep your company's cash flow in the black.

  • nnoutdev (unregistered) in reply to C-Octothorpe
    C-Octothorpe:
    ObiWayneKenobi:
    People like this need to be shot in the face with a hammer. I'm so sick of having to deal with slop like this at almost every job I've had in the five-or-so years I've been a software developer. It seems hardly anybody ever takes a step back and thinks "Hm... there has got to be a better/easier way of doing X, let me take the time to find out".

    Are we all that spineless to tell some uppity manager that Feature X will take an extra day or two in order to make sure that it won't collapse after a little while? Are managers that stupid to not understand the difference between short-term and long-term, and that long-term is what really matters for a business? That's freaking Business 101.

    HA! You have got to be trolling... No, management doesn't give a shit about long-term. They're like kids with ADD, just the short term (i.e. bonus, title, recognition, etc.). Besides, in two years when the application comes apart, they'll just blame you, who due to the shitty work environment, have already left for greener pastures.

    Also, this is unfortunately the norm, at least from what I've seen at every new place I have worked (and currently work). The best thing to do is to not to try to be a hero. Just make sure all your new code is well written, and you should be alright... Unless you're maintaining it, then your basically fucked and we'll all pray for you.

    C-Octothorpe a true jedi developer! hat-tip, wink and a nod!

  • (cs) in reply to Jonathan Hamilton
    Jonathan Hamilton:
    Nice try, but it's from a computer game called Myth II.
    Yeh, that's what I found out when I did finally google it. It's absolutely a pastiche done in the Lovecraft/Poe style though, and deserves credit for being a good one.
  • I. G. E. (unregistered) in reply to DaveK
    DaveK:
    Jonathan Hamilton:
    Nice try, but it's from a computer game called Myth II.
    Yeh, that's what I found out when I did finally google it. It's absolutely a pastiche done in the Lovecraft/Poe style though, and deserves credit for being a good one.
    And here was I, thinking
    Melnorme:
    Against my better judgment, I browsed the code last night to a random file and read about the life of a coder not yet born, who would resurrect Visual Basic and visit horrors on the world without equal in history or myth. I believed every line. I have resolved to destroy the thing before allowing it to become an instrument of WTF.
    was a reference to Swampy.
  • Jeff Grigg (unregistered)

    Arrrrrrggggghhhh!!!! Eyes bleed!!!!

  • Lord of the Fails (unregistered) in reply to ObiWayneKenobi
    ObiWayneKenobi:
    2) No self-respecting Ruby/Python developer would write trash like that without committing seppuku afterwards.
    He did. That's why we get to see the code.

Leave a comment on “Seeking The Summoner”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article