• (nodebb)

    Did the validatePersoms method call the validateObjects method?

  • Michael R (unregistered)

    "Imagine how much it would have cost if we hadn't gone with the cheaper labor?" ??? Let me quote Red Adair:

    If you think it's expensive to hire a professional to do the job, wait until you hire an amateur.

  • Aitkiar (unregistered)

    "This, by the way, was another popular mindset in the early 00s: you could design your software as a set of UML diagrams and then hand them off to the cheapest coder you could hire, and voila, you'd have working software (and someday soon, you'd be able to just generate the code and wouldn't need the programmer in the first place! ANY DAY NOW)."

    I have work in several companies that have evolve and change that mindset. Now we don't use UML, we use plain word documents, with pseudo code that nearly compiles.

    The results are even worse.

  • Hanzito (unregistered)

    It's not really a given that ML's team would have delivered for the projected cost, is it? I've seen quite a projects go way over the original price, with an supposedly watertight contract with the original bidder.

  • Lothar (unregistered)

    There are two comments held for moderation at this time, so the following might already be addressed.

    The shown code creates a shallow copy of the passed list, i.e. the list itself is a new one, containing the same references to the entries. This allows you to delete entries from the list as part of the validation while keeping the passed list in its original form. That would not be the case if you passed listOfApplicants directly to validatePersonList. Also, if the list contained an entry that is not of type Applicant or Person, you'd get a ClassCastException already at this point rather than inside validatePersonList. Maybe validatePersonList uses a lot of resources while validating so "crashing" early might actually be a good thing rather than a WTF.

  • Hal (unregistered)

    The death by a 1000 cuts approach works fine as long as thing you are migrating the functionality out of exists somewhere in the middle.

    It can't be the end user interface. You kinda need to forklift that nobody wants to have to do one thing in application B and switch back to application A to complete the process. You might get away with it the first delivery of B handles all the base cases and only a few employees that already handle business-exceptions have to go back to A to deal with corner cases.

    The mainframe migrations always fail because nobody accepts the first thing the mainframe needs to stop doing is the things its best at. They view the mainframe as black box; but its not that JCL+COBOL program is separate database and pile of flat files. The only time I saw truly successful migration off the mainframe or mid-range was when step zero was moving DB2 to x86 servers first.

    That way the mainframe was in the middle. They were able to start moving the CICS interface to web forms, and start to rebuild the batch processes and all the embedded business logic into java and other places.

  • Argle (unregistered)

    I always love saying "I wish I had the money to buy an elephant." Someone inevitably asks, "why do you want an elephant?" Then I say, "no, I said I wish I had the MONEY to buy an elephant." I also wish I had the money to hire cheap offshore programmers. I could retire tomorrow and live a life of ease.

    I turn 63 this year and I've been programming professionally since I was 17. Remy, thanks for reminding me that I've been told since the start that "any day now" we'll no longer need programmers.

  • Sauron (unregistered)

    This, by the way, was another popular mindset in the early 00s: you could design your software as a set of UML diagrams and then hand them off to the cheapest coder you could hire, and voila, you'd have working software (and someday soon, you'd be able to just generate the code and wouldn't need the programmer in the first place! ANY DAY NOW).

    Wait, did they really think that?

    That was just super dumb.

    Everyone knows that the reality is you can design your software as set of Jira tickets with a meaningless title and "TODO" as the description, then hand them off to the cheapest coder that can be hired by the cheapest Kerbleckistani contractor you can contract with, and voila, you'll have working software (and someday soon, BUT REALLY SOON THIS TIME, you'll be able to just generate the code with AI and won't need the programmer in the first place! ANY DAY NOW).

  • Álvaro González (github)

    Let's be honest, casting objects fron one class into another is the kind of design decision everybody would be mocking if it had occurred to PHP.

  • Hanzito (unregistered) in reply to Sauron

    UML diagrams? JIRA tickets? Those are the ways of dinosaurs. User stories is where it's at!

  • (nodebb) in reply to Lothar

    Also, if the list contained an entry that is not of type Applicant or Person, you'd get a ClassCastException already at this point rather than inside validatePersonList.

    I feel that what probably happened is that validatePersonList was throwing a ClassCastException and they created this code to debug it.

  • lzsiga (unregistered)

    Anyways, why isn't this method static?

Leave a comment on “A Valid Applicant”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article