• UnderSampled (unregistered)
    As a result, he started on a Tuesday, and by Wednesday was telling everyone how he would do their job.

    So that's why they never start on Sundays!

  • (cs) in reply to neminem
    neminem:
    snoofle:
    Anything, including Perl, can be used to write a clear, comprehensible, well documented and maintainable program.

    I agree completely about Perl - while it doesn't necessarily make it as easy to write -large- maintainable applications as some languages, I've certainly seen decent-sized scripts in perl that were entirely pretty and easy to figure out. Perl kinda gets a bad rap just because it makes it so easy to write unreadable garbage if that's what you're trying for. That said... http://en.wikipedia.org/wiki/Whitespace_%28programming_language%29 http://en.wikipedia.org/wiki/Brainfuck http://en.wikipedia.org/wiki/INTERCAL_programming_language

    Technically Turing Complete! (Yes, I do know you were actually implying that only about languages that were designed to get work done in them, rather than languages designed intentionally as parodies, but I like nitpicking.)

    Actually the worst thing I can think of is the 'COMEFROM' command which is actually implemented in some languages....

    Yazeran.

    Plan: To go to Mars one day with a hammer.

  • Scrummy (unregistered) in reply to Remy Porter
    Remy Porter:
    That's a really lousy thing to say, though.

    "Agile didn't work!" "Then you did it wrong!"

    That said- Agile is a good way to get a team in sync. It's not a project management technique, it's not even a "coding fad"- it's how you organize a team and keep them headed in the same direction.

    Maybe it's not nice to say/hear, but the truth often hurts. If you can't succeed with a proven methodology, it's probably not the methodology that is the problem.

  • (cs) in reply to Nagesh
    Nagesh (fake):
    Nagesh:
    Scrummy:
    Kensey:
    Sure, that sounds good in theory, but I worked with an actual Agile dev team. They turned out plenty of awful code and had a project basically thrown away by the client after months of work because oops, they forgot to gather requirements first! So when they triumphantly unveiled the first demo (that the client knew nothing about), the reaction was "...yeah, this doesn't really work for us, and by the way how much of our money did you spend on this?"

    By contrast some of the very best code I've seen was turned out by single programmers working alone "off in a cave", with a coherent vision and the skills to realize it.

    (The dirty little secret of all the coding fads like Agile and XP is this: no technique on earth can make bad programmers into good programmers. Only becoming a good programmer can. And if your team is made of good programmers, it doesn't much matter which technique(s) they use, as long as they're all in sync together.)

    In my experience, when an Agile development effort fails, it's because the team wasn't doing Agile correctly.

    I endorse this view in full & total.

    I also be learning about True Scotsman Fallacy this weekend.

    Look like you got link to http://rationalwiki.org/

  • (cs) in reply to Scrummy

    No, it's stupid to say and hear, because it conveys no information. It assumes its conclusion- that Agile is the right answer.

    It isn't. I'm a huge proponent of Agile methodology, but it's not "a better hammer" and not every problem is a nail. You can't simply say, "well, using Agile teams would solve this problem," because not every organization is suitable for Agile teams to work.

    Agile is one tool for organizing teams, and it's a great tool. But it's not appropriate for every situation, and it sure as hell isn't a panacea for your technological woes.

  • (cs) in reply to Scrummy
    Scrummy:
    Remy Porter:
    That's a really lousy thing to say, though.

    "Agile didn't work!" "Then you did it wrong!"

    That said- Agile is a good way to get a team in sync. It's not a project management technique, it's not even a "coding fad"- it's how you organize a team and keep them headed in the same direction.

    Maybe it's not nice to say/hear, but the truth often hurts. If you can't succeed with a proven methodology, it's probably not the methodology that is the problem.

    Scrummy, Funny person only. All sarcastic talk just no sarcastic font-face here. Most "proven methodologies" are not real "proven". CMM5 is big farce in our own country.

    Business is business. Manifesto and process driven stuff look good on paper, but real deal is real deal.

    That is ugly truth staring at heart of every programmer.

  • (cs) in reply to Scrummy
    Scrummy:
    In my experience, when an Agile development effort fails, it's because the team wasn't doing Agile correctly.

    QFT. Too many times "agile" translates to "We have no procedures and just do whatever and hope it's right" instead of actual agile which has strict guidelines. And, almost all the time, these faux agile environments love the short development cycles and no upfront requirements, but hate and refuse to use the other parts like pair programming, TDD, constant customer feedback, and all the things that, you know, actually make Agile succeed

  • Jack (unregistered) in reply to Nagesh
    Nagesh:
    I also be learning about True Scotsman Fallacy this weekend.
    Why would you risk wasting a clever comment by posting as Fake-Nagesh?
  • Nagesh (unregistered) in reply to Jack
    Jack:
    Nagesh:
    I also be learning about True Scotsman Fallacy this weekend.
    Why would you risk wasting a clever comment by posting as Fake-Nagesh?
    I ain't being fake imporster. Other Nagesh is ruin in my good name with troling.
  • omar (unregistered)

    I hope you told that guy to F_ck off.

  • (cs)

    Many a project in the "latest and greatest development environment" has foundered because the "evangelists" have no idea what mission critical means.

  • Oh THAT Brian (unregistered) in reply to Yazeran

    COMEFROM? Was that in an unauthorized version of COBOL?

    Seriously, you can have well-documented projects in virtually any language. It all depends on the programmer.

    I remember being given a COBOL program once and was asked to make sense of it. It was apparently a monstronsity that tried to create home-grown ISAM files. It was written as a class project, by managers.

    And I used to have a job where my main responsibility was to examine user's code to find the source of their errors!

    After several days of trying to read this convoluted mess, which include the now-defunct ALTER verb, I admitted defeat. My manager grinned and said that I was not the first to throw in the towel. Several others had tried and nobody could figure out the code. Maybe it was because the code never worked?

    My point: You can have 'self documenting' languages that are impossible to read, or cryptic languages that, if coded by someone who does it well, can be read like a good book.

    A well coded program can be a thing of beauty.

  • (cs) in reply to Nagesh
    Nagesh:
    Jack:
    Nagesh:
    I also be learning about True Scotsman Fallacy this weekend.
    Why would you risk wasting a clever comment by posting as Fake-Nagesh?
    I ain't being fake imporster. Other Nagesh is ruin in my good name with troling.
    You're definitely a real imposter. For starters, you couldn't have known that the True Scotsman Fallacy applied to Scrummy's comment unless you already knew what it was.
  • True Scotsman (unregistered) in reply to PedanticCurmudgeon
    PedanticCurmudgeon:
    Nagesh:
    Jack:
    Nagesh:
    I also be learning about True Scotsman Fallacy this weekend.
    Why would you risk wasting a clever comment by posting as Fake-Nagesh?
    I ain't being fake imporster. Other Nagesh is ruin in my good name with troling.
    You're definitely a real imposter. For starters, you couldn't have known that the True Scotsman Fallacy applied to Scrummy's comment unless you already knew what it was.
    You keep pointin' out the obvious an imma give you a true phallus, lad.
  • William (unregistered)
    Dave decided to show some initiative, and he fired up a BPM tool and went to work reimplementing their software in it. <!-- In Dave's defense, pretty much all of us have made this mistake at least once. But according to the submitter, Dave was a real jerk about it. -->

    No, Remy, I have never "fired up a BPM tool" in my life, and I hope it stays that way.

    CAPTCHA: "augue" - what thinking about BPM tools gives me.

  • (cs) in reply to beorn
    beorn:
    campkev:
    the lower the chance of Dave having an "unfortunate" accident
    I think you put the quotes around the "wrong" word

    It's not actually wrong?

    Whoosh

  • Gunslinger (unregistered)

    Looks like TRWTF is letting him work on this project unsupervised for 2 years with no plan and no interim deliverables.

  • (cs) in reply to Jack
    Jack:
    Nagesh:
    I also be learning about True Scotsman Fallacy this weekend.
    Why would you risk wasting a clever comment by posting as Fake-Nagesh?
    Same reason he posts as Fake-Nagesh in the first place-- because he's an idiot.
  • (cs) in reply to Michael
    Michael:
    Having worked at a university in the past, this story is entirely credible. You have to understand how a university is different from a Real Job:

    • The university's money doesn't mostly come from satisfied customers. It comes from vague threats of violence against reluctant taxpayers. So there is no need to show a profit, or a return on investment.

    • Given the lack of motivation to spend the minimum amount of money as productively as possible, managers' self esteem is directly tied to how much money they spend not how much they make for their employer.

    • This means if you have an opportunity to hire someone you do so, in order to build your empire and keep those salary dollars flowing through your hands in future years. It is not important that the employee produce good work inexpensively, since profits and productivity don't matter.

    • By the same rule, you'd never want to fire anyone because that takes you down the ladder a notch. Besides, you can't fire a government employee for anything less than mass chainsaw murder fully recorded by the security cameras. Or hate speech, i.e. saying anything not Politically Correct.

    Under this system (non-capitalism) it is amazing anything works at all.

    But of course capitalism is TRWTF. So what are we to do?

    Sez you. This whole post is political polemic. I'd call you a cunt but you appear to lack the depth and warmth.

  • (cs) in reply to campkev
    campkev:
    the lower the chance of Dave having an "unfortunate" accident
    I think you put the quotes around the "wrong" word
    +1 for appropriate use of irony. -1 because I think you think it is really wrong word.

    Actually, you can say that he had an "unfortunate" accident, ie an accident that wasn't unfortunate because everyone else wanted him gone, so it would be unfortunate to dave, but fortunate to everyone else. So the quotes give proper irony to that sentence.

    The more popular method (and appropriate to the context of the story) would be an "unfortunate accident" using the whole phrase to indicate that something had been done to him under the guise of an accident, and for the reasons mentioned under "unfortunate" is ironic because its both fortunate to everyone who hates Dave, and was no accident. "How did you get that black eye dave?"... "Uh,... I fell..."

    You could also put the quotes around the word "accident" to indicate that, while what happened to Dave was unfortunate, Dave still "fell".

  • (cs) in reply to Smug Unix User
    Smug Unix User:
    Give me a good batch file any day.
    DOS prompt FTW!
  • Jack (unregistered) in reply to PiisAWheeL
    PiisAWheeL:
    campkev:
    the lower the chance of Dave having an "unfortunate" accident
    I think you put the quotes around the "wrong" word
    +1 for appropriate use of irony. -1 because I think you think it is really wrong word.

    Actually, you can say that he had an "unfortunate" accident, ie an accident that wasn't unfortunate because everyone else wanted him gone, so it would be unfortunate to dave, but fortunate to everyone else. So the quotes give proper irony to that sentence.

    The more popular method (and appropriate to the context of the story) would be an "unfortunate accident" using the whole phrase to indicate that something had been done to him under the guise of an accident, and for the reasons mentioned under "unfortunate" is ironic because its both fortunate to everyone who hates Dave, and was no accident. "How did you get that black eye dave?"... "Uh,... I fell..."

    You could also put the quotes around the word "accident" to indicate that, while what happened to Dave was unfortunate, Dave still "fell".

    "Thanks" for that. It's all so "clear" now.

  • anonymous (unregistered)

    Of course, it's obvious to me where they went wrong, because I'm so awesome, but the rest of you probably have no idea, so I'm going to tell you.... not because you'll understand, but because it needs to be said!

    2Yrs without so much as a single product review or code review or documentation review or any review. If your managers are so inept that they let this happen, then they deserve every single bit of what they got. Bah.

  • Robert (unregistered) in reply to Michael
    Michael:
    Having worked at a university in the past, this story is entirely credible. You have to understand how a university is different from a Real Job:

    • The university's money doesn't mostly come from satisfied customers. It comes from vague threats of violence against reluctant taxpayers. So there is no need to show a profit, or a return on investment.

    • Given the lack of motivation to spend the minimum amount of money as productively as possible, managers' self esteem is directly tied to how much money they spend not how much they make for their employer.

    • This means if you have an opportunity to hire someone you do so, in order to build your empire and keep those salary dollars flowing through your hands in future years. It is not important that the employee produce good work inexpensively, since profits and productivity don't matter.

    • By the same rule, you'd never want to fire anyone because that takes you down the ladder a notch. Besides, you can't fire a government employee for anything less than mass chainsaw murder fully recorded by the security cameras. Or hate speech, i.e. saying anything not Politically Correct.

    Under this system (non-capitalism) it is amazing anything works at all.

    But of course capitalism is TRWTF. So what are we to do?

    Be careful about your terminology there. You're describing the environment of working at a public university. Don't lump us private university programmers in with that croud, please. I work at Caltech, and it's a glorious job with none of the problems you described.
  • (cs) in reply to KattMan
    KattMan:
    verisimilidude:
    ur:
    Yeah, two years - how can it take that long to re-implement something that was even feasible with batch files?
    Depends on the language you use. Perl - real quick but maintenance will be tough. Python - Not as quick but maintainable. Java - Not quick and if not done well totally unmaintainable. Visual Basic 6 - Well, maybe that's what he used. It would explain the two years, lack of error handling, and inability for anyone else to pick up the system.

    So you threw VB in there just because WHY? VB showed problems with programmers so much easier because "everyone" could pick it up. It had error handling just like any othe rlanguage, but since "everyone" could program in it they never used it. Problem wasn't the language, but the programmers, VB just made it easier to spot the problems later because it was more easily read.

    Just don't get me started on those "hey I can read this I must be a programmer" types. There are far to many of them still banging on a keyboard thinking they are writting good code.

    I see the VB6 inclusion as appropriate for exactly that reason. The kind of guy that would do those things would probably have VB6 as his go-to tool.

    Anyway, what is a "BPM tool" supposed to mean? Google searches seem to lead to Business Process Modelling, ie flowcharts, etc. Not sure how that translates to a programming language.

  • AN AMAZING CODER (unregistered) in reply to Remy Porter
    Remy Porter:
    No, it's stupid to say and hear, because it conveys no information. It assumes its conclusion- that Agile is the right answer.

    It isn't. I'm a huge proponent of Agile methodology, but it's not "a better hammer" and not every problem is a nail. You can't simply say, "well, using Agile teams would solve this problem," because not every organization is suitable for Agile teams to work.

    Agile is one tool for organizing teams, and it's a great tool. But it's not appropriate for every situation, and it sure as hell isn't a panacea for your technological woes.

    This is the truth, and I'm also a proponent of agile.

  • (cs) in reply to snoofle
    snoofle:
    It's the carpenter; not the hammer that makes the difference.
    The hammer may not make a difference, but the wood does. Try building a bridge out of particle-board. It just won't carry the weight.
  • George (unregistered) in reply to Scrummy
    Scrummy:
    This is why you don't let a person or team just go into a hole and write a bunch of code for several months. I can't stress enough how Agile development would have mitigated this process. When you work in small sprints, it guarantees that you will get a complete product that works, with documentation.

    There is a middleground between scrum and letting people work unsupervised in a hole.

  • mickeyding (unregistered) in reply to beorn

    TWTF - "It was thoroughly documented and well understood by the support team"

  • (cs) in reply to Scrummy
    Scrummy:
    Kensey:
    Sure, that sounds good in theory, but I worked with an actual Agile dev team. They turned out plenty of awful code and had a project basically thrown away by the client after months of work because oops, they forgot to gather requirements first! So when they triumphantly unveiled the first demo (that the client knew nothing about), the reaction was "...yeah, this doesn't really work for us, and by the way how much of our money did you spend on this?"

    By contrast some of the very best code I've seen was turned out by single programmers working alone "off in a cave", with a coherent vision and the skills to realize it.

    (The dirty little secret of all the coding fads like Agile and XP is this: no technique on earth can make bad programmers into good programmers. Only becoming a good programmer can. And if your team is made of good programmers, it doesn't much matter which technique(s) they use, as long as they're all in sync together.)

    In my experience, when an Agile development effort fails, it's because the team wasn't doing Agile correctly.

    Indeed. How can it be that "oops, they forgot to gather requirements first!" An agile team working correctly is gathering requirements at the beginning of every sprint, every week or two. It is impossible for them to work for months without requirements. And showing it to the customer only after months (after performing many one- or maybe two-week sprints) is TRWTF for an agile team. This tells me they have to learn how agile works first.

  • (cs) in reply to Oh THAT Brian
    Oh THAT Brian:
    COMEFROM? Was that in an unauthorized version of COBOL?

    No, but it might have been SLOBOL: http://neil.franklin.ch/Jokes_and_Fun/Languages_Compete_with_APL

    About COMEFROM, I remember reading an article about it, but can't find the exact reference any more. However this link should point you in the right direction: (link no. 2) (referenced in this article: (link no. 3) )

    Fuck you, Akismet! My comment is not spam. Get lost. What should I write here to convince you I'm not spamming. Is Akismet really TRWTF? Just asking... After the fifth or so attempt, I have removed the links. Hope that helped. No, it didn't, so what to do? I know it. Disguise the links to look not-link-like (WTF???) No, not enough. Maybe remove the links altogether (but they were the whole purpose of my post here) Edit: That helped. Now to try reinserting the links again.

    Addendum (2012-06-07 04:22): Link no. 2 should be an article about the comefrom statement: www.fortran.com/fortran/come_from.html and link no. 3 is this small article: https://secure.wikimedia.org/wikipedia/en/wiki/COMEFROM

  • blither (unregistered) in reply to Jeff
    Jeff:
    Stev:
    Planning. Do it.
    I plan to.

    Wonderful, thanks :)

    How could they do 'agile' with the guy if he was such a dick? That would have required cooperation.

  • Bartholomew Taps (unregistered) in reply to Scrummy
    Scrummy:
    This is why you don't let a person or team just go into a hole and write a bunch of code for several months.

    It's fine to do this as long as (a) the developer is competent and (b) the requirements are known

    In this story, there is an existing system to demonstrate the requirements. And of course one should include the "right" kind of flexibility as a requirement if you expect things to change in the future.

    The story here is that the guy is incompetent. And that is the only really compelling argument for requiring him to do iterative/frequent delivery type process.

    But of course somebody else would need to feed him the stories and evaluate the deliveries. And if they are incompetent...

  • Bartholomew Taps (unregistered) in reply to snoofle
    snoofle:
    It's the carpenter; not the hammer that makes the difference.

    If that was true, we'd still be banging nails in with our fists. Human beings are tool-makers for a reason.

  • dan (unregistered) in reply to KattMan
    KattMan:
    I prefer bagets to begats. They don't leave such a bad aftertaste and cost less.

    Hmmm.... do you mean baguettes?

  • Bartholomew Taps (unregistered) in reply to Scrummy
    Scrummy:
    In my experience, when an Agile development effort fails, it's because the team wasn't doing Agile correctly.

    I suppose Russia and China weren't doing communism correctly.

    Agile appeals to managers who want to get something out quickly to impress their superiors (it is linked to the "responsiveness" trend in management). Followed to the letter, agile will produce quick results initially. But the amount of refectoring, testing and pairing required makes it low on overall productivity. It is, if you like, a low latency/low bandwidth approach. By the time a market-ready or deployment-ready system has been produced, it has adtually taken longer than waterfall.

    What inevitably happens is that managers attempt to offset the low productivity by skimping on refactoring, testing etc. This causes projects to crash into a brick wall of unmaintainability, and productivity disappears completely. The team is reduced to adding trivial features and doing trivial bug fixes.

  • (cs) in reply to Paul Neumann
    Paul Neumann:
    Steve The Cynic:
    <yawn>... By comparison, electric light bulbs are almost zero-maintenance, very much brighter, don't flicker or blow out in windy conditions, are smoke-free, and cause fires only rarely.
    Learn abstraction. The comparison being made is that lights ARE more better(TM), but prior to the invention candles were "not broke."
    I did learn abstraction, many years ago. My point was that candles *were* "broke" in a variety of fairly serious ways (smoky, dim, fire hazard, ...), so using them as an analogy for "if it ain't broke, don't fix it" purposes is of limited value.
  • Hmmmm (unregistered) in reply to Bartholomew Taps
    Bartholomew Taps:
    I suppose Russia and China weren't doing communism correctly.

    There's many a true word spoken in jest. No country in history has ever got anywhere near being truly communist. Most haven't even got to socialist...

    The main problem I see with agile is that the method is far too sensitive to implementation details, forget (or skimp on) one seemingly little thing and the whole thing switches from being beneficial to being a productivity sapping waste of time...

  • ur (unregistered) in reply to Bartholomew Taps
    Bartholomew Taps:
    Scrummy:
    In my experience, when an Agile development effort fails, it's because the team wasn't doing Agile correctly.

    I suppose Russia and China weren't doing communism correctly.

    Stop this subversive backchat or I, the people, will have you shot.
  • Foo (unregistered) in reply to Yazeran
    Yazeran:
    Actually the worst thing I can think of is the 'COMEFROM' command which is actually implemented in some languages....

    Yazeran.

    Plan: To COME FROM Earth one day with a hammer.

    FTFY

  • Your Name (unregistered) in reply to Not Nagesh
    Not Nagesh:
    Really? Management (which actually does have a purpose) let this guy run amok for two years without any evaluation of what he was doing? Typical University IT team perhaps. I never worked on one, but have only heard stories. In the end, maybe everyone got what they deserved.
    Trust me, it's not just universities..... The very large corporation I work for does the same thing. My group let an egotistical buffoon completely redesign our old smooth-running, well-documented system from the ground up, because he supposedly "knew better" even with no experience in our app. It was supposed to take 2 years start-to-finish. Now, 4 unsupervised years later, only 25% of the "new system" is complete (in production), and it's slower & buggier than ever. Meanwhile Mr. Ego has moved on to a different project and doesn't want to finish what he started. Truth be told, no one else wants to finish it either.

    Captcha 'commoveo' -- commoveo here, sit down, and finish your damn project!

  • null (unregistered) in reply to pjt33
    pjt33:
    According to the article (I know, I know), it was "a BPM tool".
    Big Pile of Manure?
  • Nagesh (unregistered)

    Ain't it being amazing how frequence Alex no post article and still have scarecrow boldnes to call site "daily?"Any amployee I manage would have be massaged severely to be showing that much reckles.

  • (cs) in reply to Nagesh
    Nagesh:
    Ain't it being amazing how frequence Alex no post article and still have scarecrow boldnes to call site "daily?"Any amployee I manage would have be massaged severely to be showing that much reckles.

    Once you start paying him, then you can hold him to deadlines.

  • Nagesh (unregistered) in reply to KattMan
    KattMan:
    Nagesh:
    Ain't it being amazing how frequence Alex no post article and still have scarecrow boldnes to call site "daily?"Any amployee I manage would have be massaged severely to be showing that much reckles.

    Once you start paying him, then you can hold him to deadlines.

    I ain't ever click on ads. Scarecrow to have them, if ain't being post article all time.

  • A Gould (unregistered) in reply to myName
    myName:
    "It wasn't a terribly pretty system, but it did have a few very important features: It worked."

    Sometimes a piece of code will be defended in the comments with this phrase and the poster will be decried, yet it passes unmentioned this time.

    In the words of my Practical Programming professor (whose only taught night classes because his day job was running the university networks) - "make it work, then make it pretty".

    Or put another way - If it works but it's ugly, it still works.

  • Nagesh (unregistered)

    When my contract run out, I am thinking Alex is being donkey-hole and scarecrow for not post article. I ain't be massage his dead body any times soon.

  • Anonymous (unregistered) in reply to Scrummy
    Scrummy:
    When you work in small sprints, it guarantees that you will get a complete product that works, with documentation.

    Guarantees it, indeed! Meanwhile, back in the real world...

  • (cs)

    Isn't it fun how much power you wield when you get to pick the perspective for a story?

    How many people in here have tried having a job at a place populated by people who think source control is a shared usb-key, and who are satisfied with 5000 lines of csh scripts that need to be hand fed to the system because that is the way an unbroken line of ambitionless grognards did it since the asterisk in *nix meant U.

    I'm not saying Dave wasn't a wet behind the ears little .... that needed to earn his keep before he started telling people to do things different. I'm just saying, Ben could easily have been the villain from a different perspective :)

  • Paul (unregistered) in reply to Hmmmm
    Hmmmm:
    No country in history has ever got anywhere near being truly communist. Most haven't even got to socialist.
    That's because before you get there, everyone is dead.

    "From each according to his strength, to each according to his need."

    Sound like a good idea? It is certainly popular. But it is the ideology of death.

    Every society is composed of only three types of people: producers, beggars, and thieves. Only the producers make the things everyone needs. Beggars talk you into giving them stuff. Thieves just take what they want by violence.

    If there were no producers, there would be nothing for the beggars and thieves to consume. They would die when they ran out of stuff to take from each other.

    Taking -- usually by threats of violence -- from the producers, and distributing to the beggars and thieves, can work as long as the producers are allowed to produce enough for all. But as the non-producer class grows, it steadily gobbles up the "evil" "greedy" producers until they are drained and gone. Eventually the best producers are destroyed and the whole thing gradually begins to collapse on itself.

Leave a comment on “Batch of Trouble”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article