• P (unregistered)

    Actually it's a test that increases the percentage of successful tests, so test failures don't look as awful. A big brain move there.

  • Mystery Guest (unregistered)

    I do hope there's an update later where the contractors are fired, the system is completed in-house for 10% of the current total spend, the manager who pushed for the consultants in the first place is convicted of fraud and, due to the state correctional systems being written by those same consultants, gets accidentally sent to a facility for violent sexual offenders.

    I... I may have been triggered by this article.

  • Pudin9 (unregistered)

    Testing vendor-supplied code is not necessarily wrong per se. If your logic depends on the behaviour of an external library, and especially if it has bugs, and/or is regularly updated, it makes sense to describe the expected behaviour with tests, so you notice when it changes.

  • Steve (unregistered) in reply to Mystery Guest

    But back in the real world Brian will get fired for being negative about and obstructive to the contractors, and Initech will eventually grind to a halt as 100% of its revenue is paid to contractors, the contractors bought in to supervise and advise the contractors, the contractors brought in to supervise them ,,,

    Contractors. Con as in fraud, tractors as in large expensive items covered in sh$t

  • Scott (unregistered)

    I'm sure there are good examples out there, but in 30+ years of development, I've yet to meet a contractor who wasn't a fraud, an idiot, or both.

  • hpoe (unregistered)

    Clearly no one can appreciate the genius of these HPCs. Don't you know they spent several weeks at a highly prestigious JavaScript Bootcamp where they became full stack developer in just 6th months. You old dinosaurs are just too far behind the times. Their job title has rockstar in it, you guys probably aren't even ninjas.

  • Another Brian (unregistered) in reply to Scott

    I've worked with a few decent contractors in my career. And I can count them on one hand.

  • Phlamingo (unregistered) in reply to Mystery Guest

    We were all triggered by this, Mystery Guest. All of us.

  • (nodebb) in reply to Another Brian
    I've worked with a few decent contractors in my career. And I can count them on one hand.

    Plot twist: "Another Brian" has massive polydactyly.

  • Sole Purpose of Visit (unregistered)

    Kudos, Remy, for slipping in a classic Wolfgang Pauli quote there. Not strictly appropriate, but I liked it anyway.

  • Brian Boorman (google) in reply to Mystery Guest
    ... the manager who pushed for the consultants in the first place is convicted of fraud ...

    Explain to me how the manager committed fraud. Was he receiving a kickback from the contractors for hiring them? There has to be some personal financial or property gain from the action to be considered fraud. Simple incompetence != fraud. It's just bad business decisions.

    Now if you want to talk about the contractor's, you could probably make a case that they couldn't deliver what they promised. Whether that's fraud or simple breach of contract depends on many other factors that we don't know about in this little story here.

  • Stella (unregistered) in reply to Mystery Guest

    I've seen software behaving like you described it... doing the right things while being so wrong at the same time.

  • I'm a Fixture Here Now (unregistered)

    Nonsense tests seem to be quite popular, though I've normally seen the 'test that a property setter sets the property' variety rather than trying to test aspects of the test framework - that's quite special. I think they are good for metrics ('look at our extensive test suite!') and because it's not in the main codebase (and can never cause a bug) it's probably less rigorously reviewed.

  • (nodebb)
    1. The situation is a WTF
    2. The categorization of contractors (which are distinct from consultants, and should never really be "high paid") is quite common
    3. The categorization applies to far to many consultants as well

    BUT, the universal phraseology is really beginning be bothersome.

  • (nodebb) in reply to Brian Boorman

    Explain to me how the manager committed fraud.

    He probably could never be convicted of fraud, but this happens so often that it's hard for a manager to claim ignorance.

    It's also really hard to hold anyone accountable in a software project. The contracts are usually vague enough that any contractor can claim they they honestly feel that they delivered what they promised. Proving otherwise would likely cost more than one could ever expect to collect.

    If you ask for a more concrete contract, the contracting company is either going to ask you to provide so much detail that you pretty much have to do 90% of the project for them. If you ask them to provide the detail, then they'll charge you so much for the pre-sales work that you've already spent more than the budget before you even start. This is actually the reason for agile in the first place, clarifying a final vision before you start isn't an efficient way to build software.

  • (nodebb)

    Your lead-in story reminds me of one of my favorite maxims (taken from The Art of Systems Architecting) and one which I repeat often in the CS 428 ("real-world software engineering class") I teach:

    "In architecting a new [software] program, all the serious mistakes are made in the first day." [Spinrad, 1988]

    A lot of failed projects I have reviewed over the years should have been stopped -- or seriously rethought -- on day one.

  • sizer99 (google)

    The key to successfully dealing with contractors is to give them a very clear deliverable on a very fixed (though generous) budget. We've used this successfully many times for things where it would take too long to do it in-house because we don't have the expertise or the time to build the expertise.

    This also gets you honest, talented contractors, because only they would take that deal. Your normal HPCs are fatally allergic to 'fixed cost' and 'you must reach deliverables to get paid'. Everyone wins.

    On the flip side, you can't jerk them around by majorly changing things once the contractor gets started without re-negotiating. You could, but word gets around. I've found they're generally quite easy about making a couple minor changes (because no plan survives implementation), but if we pull the rug out because of our managers' incompetence, then we give them more money to fix it.

    Addendum 2020-05-14 15:22: You also have to be smart with the deliverables, i.e. functioning code and exactly what it needs to demonstrate. I've seen deliverables that just specify 'final code delivery' - welcome to stackexchange copypasta that compiles at best (if you're lucky).

  • shcode (unregistered)

    i, for one, see no issue in testing whether JavaScript's assignment works, because... well... it's JavaScript, you never know.

  • Guest (unregistered)

    I still have about half this review to go and I dread to think what other errors I may find.

    I think Brian misspelled "horrors" there...

  • Sole Purpose Of Visit (unregistered) in reply to shcode

    I've some sympathy for that viewpoint (not least because with Javascript and PHP, I'm never quite sure what flavour of equality I'm dealing with -- a personal failing). However, you're writing the tests in Javascript so ... the word "turtles" springs to mind here.

  • Ugh (unregistered) in reply to I'm a Fixture Here Now

    Sometimes (often? always?) they're around just to keep up with some brain-dead "90% of LOC must have a test covering them" metric even if the line in question is a trivial assignment.

  • Tabish Raza (unregistered)
    Comment held for moderation.
  • Tabish Raza (unregistered)
    Comment held for moderation.

Leave a comment on “I Fixtured Your Test”

Log In or post as a guest

Replying to comment #:

« Return to Article