• David (unregistered)

    While it's frustrating to have decisions made by people demonstrably unsuitable for that, this happens in companies everywhere - especially where the IT management comprises people who have never been hands-on. However, checking in code that's deliberately difficult to understand is unprofessional. While I understand the point that they're trying to make, it's being deliberately difficult. When brought up with management the explanation demonstrated that they had deliberately caused significant amounts of the company's manpower to be wasted in an effort to one-up the offshore team. It goes against any code of conduct they might be expected to adhere to as a professional.

  • Derp (unregistered)

    I reckon I'd be correct in assuming there were many requests to "please do the needful" from said offshore developers.

  • LCrawford (unregistered)

    Then he committed it, secure in the knowledge that the junior developers would never bother to look at it again once he was gone. Then he gave two weeks notice.

    But management noticed his message and fearing a backdoor being inserted into the code, promptly walked him out the door, flanked by 2 security guards.

  • Steve (unregistered) in reply to LCrawford

    Now that's silly - management doesn't read code.

  • P (unregistered)

    It's OK - no-one will inherit the system as that company isn't going to last much longer. Especially true if manglement have paid themselves big bonuses for the money they have "saved".

  • I dunno LOL ¯\(°_o)/¯ (unregistered)

    I like a happy ending.

  • SysKoll (unregistered)

    The key factor here is that manglement made a far-reaching consequence by selecting an offshore contractor. They will not disavow it by admitting that their choice was a poor one. For them, the destiny of the project and the architects is of lesser importance than the validation of their decision. They will also lie about the contractor's efficiency, cover up problems, shut up dissent, and fire discontent employees, all because they cannot start admitting that maybe the Emperor is kinda lightly covered.

    One sad consequence is that business rags will rave about how much money that company saved by going offshore. This is a vicious cycle.

  • Quite (unregistered) in reply to LCrawford

    ... and this is actually bad exactly why?

  • DavidHaitch (github)

    I'd actually find a senior dev doing this to be more frustrating than clever. I've worked in "mature" C++ codebases before, where very odd syntactical expressions are actually required for correct function due to some compiler oddity. Having seen such weird things, I'd be quite willing to believe that a for-while loop actually does serve some esoteric purpose. I'd probably be a bit quicker to ask the senior dev about it than these guys were, but I get the feeling that even asking would make Alex feel like he proved his point.

    I'm not defending the morons in the story, of course, but I'd caution against any senior developers reading this against squandering their subordinate's trust in this manner.

  • matt (unregistered)

    That's "WHOEVER". That pronoun, like every other relative pronoun, takes the case of its role in the subordinate clause, in this case, the SUBJECT of "inherits".

  • my name is missing (unregistered)

    Offshore developers are so inexpensive you can hire 10 times more of them; for while you believe this your development will loop forever.

  • (nodebb)

    Clever little subtlety!

    And no mention of the other clever little subtlety that he inserted in the comment, using "whomever" instead of "whoever" in order to create an ungrammatical sentence.

    He's a trickster, this Alex.

  • Milo (unregistered)

    I don't even know Java, and I could figure out what was going on at a glance...

    Sadly, a few minutes on Stack Overflow will confirm that, yes, people this stupid really do exist, and yes, they really do think they are programmers.

  • Kashim (unregistered)

    So... no one thought to just add a newline in there, and then reevaluate the way the loop worked and see if it was the same? No one thought to try and write their OWN for-while loop in a little test program in order to figure out how it might be working?

    Honestly, I'm shocked Alex wasn't fired. Intentionally writing unclear code for the sake of confusing junior developers just so you could prove that they weren't qualified to do their jobs would be a pretty immediately fire-able offense in my department.

    Offering to help the other developers "get better" isn't really all that reasonable of a solution either, unless you are planning on writing "Your Computer Science degree for dummies". Either the other developers lacked the education to know better practices, in which case it would likely take more education than one guy offering to "help them get better", or they lacked the necessary mental processes required to perform high-level programming, in which case no amount of education was going to help them anyway.

    If your company does off-shoring, and you can't handle working with the crappy developers that brings, then don't work for that company. It's that easy.

  • Loren Pechtel (google)

    If they don't understand how the language works they should be called students, not junior developers.

  • Duke of New York (unregistered)

    So let me get this straight...

    Alex, who mostly did not code, was so annoyed by the offshore coding team's work that he decided to covertly sabotage them, which hampered their work even more for 6 weeks. Then he told his boss that he had done this, expecting that it would give him leverage.

    What a surprise that this didn't work.

    I've been offshored and I'm currently being offshored. It's no fun, but making yourself part of the problem doesn't help anything.

  • Wuu (unregistered) in reply to Duke of New York

    Sounds like maybe you've glossed over the part where they were changing specifications (in documentation) to suit what they wanted, rather than what they were being asked to provide.

  • Duke of New York (unregistered)

    I hope you all realize that the story could easily turned around so that Alex is the architect without any practical sense, whose job the coders end up having to do in addition to their own, who checks in weird code that they just roll their eyes at and keep going.

  • snoofle (unregistered) in reply to Duke of New York

    Yeah, no. I personally witnessed this from two desks away. The offshore guys were truly incompetent. The manager was kind of in a bind as he was told from above to make nice with the offshore guys, and he wrongly took that to mean "Don't ever say no to them". All Alex was trying to do was force the manager to see, and deal with, their utter lack of even the most basic skills.

    As far as the architecture went, I personally did a peer review of the document and Alex did a pretty decent job of it.

    When you can't fix a problem and you can't escalate it, all you can do is make it more apparent in the hope that those above will act appropriately. I helped Alex find a new gig, because in this case, management was TRWTF.

  • Jim Tonic (unregistered)

    That while loop is pretty dangerous. Instead of quickly throwing a NPE you can catch and deal with, the application is stuck in an infinite loop whenever getWidgets returns null (which it very well may, especially when the offshore guys add their special sauce to it).

    I'd go for: while ((widgets = getWidgets()) == null) break;

    Just as confusing, but a lot safer.

  • MiserableOldGit (unregistered)

    Trouble is, while his intention might of been good, his approach was far from it. Sabotaging a team of developers you have worked out aren't very good is not going to work, two things will be seen;

    1. You can't be trusted as you're in it for yourself

    2. The outsource team have been struggling all this time because you've been playing games

    Doesn't matter whether those things are true, that's what management will think, especially because the relationship manager for the outsourcing company is likely to be a silver tongued slippery toad, and your own middle management will have vested interests in not allowing this firm they selected to be perceived as crap.

    I suppose as a parting "fuck you", and a demonstration to those who do get it, it works, but I don't see this achieving any more than a stronger push to offshore more and get rid of the perceived obstruction of an in-house team.

    I used to work with a developer who would boast about how he had driven a former junior colleague out of his job with tricks like this. Unsurprisingly, his own code was far from admirable.

  • (nodebb)

    At least while the junior developers where hurting their brains trying to understand the for-while loop (the travelling library with the Java reference textbook had lent it out to someone else) they weren't industriously breaking something else.

  • snoofle (unregistered) in reply to Jim Tonic

    As a general statement, if by contract a method returns a populated list or throws an exception, and someone changes it to return null, then that person is also obligated to find every place it's called and make sure the downstream code handles a null return value. If they don't, then you'd kind of expect it to fail in interesting ways...

    In this case, Alex was trying to bring to light their inability to even understand the code by forcing a stupid situation in response to the failure of management to act. Desperate times call for desperate measures...

    I went through this myself at WTF Inc...

  • (nodebb)

    "The project manager then assigned units of work to numerous offshored junior developers..."

    Found the symptom of the WTF. Management doesn't value expertise in software development.

  • Duke of New York (unregistered)

    I imagine Alex like the madman in The Telltale Heart, sneaking into the repository every night (since offshore devs are always in another time zone) to add a single line of nonsensical code, then bragging to the boss about his clever plan.

  • snoofle (unregistered) in reply to Duke of New York

    You imagine wrong - Alex and I used to discuss it WITH the boss - in advance - in an attempt to force him to do something to save the project. We even showed it all to B+1. who also didn't care. That's when we threw up our hands, reverted all the code, and found other jobs (my project was undergoing similar manglement issues, with a common B+1).

    Don't assume.

  • verisimilidude (unregistered)

    I have worked with, and been the on-shore supervisor for, offshore developers. They are, in general, not dummies. They are products of a school system that emphasizes rote memorization and development shop employers who emphasize time on task, and that task is entering code into the editor. Most of the ones I worked with were eager for skilled developers to lead them in skill building classes and exercises. If I could get their upper management to understand that cut-and-paste programming was unacceptable the lower level coding grunts were happy since they really wanted to exercise their skills learning to understand the code. It was the supervisors who were telling them 'just copy this other stuff and change it'. The other problem is the offshore shops that will declare anyone a 'junior programmer', regardless of skill level, and keep him/her around only as long as the onshore people are willing to pay the hourly rate. This results in very defensive off shore teams.

  • Peter Bouillon (unregistered)

    Most people aren't narrow-minded fools. So the bosses are bound to have some very good reasons to act as they did. The evidence shows that getting good software was not foremost in their mind in the first place; they must have had some other need that got the priority and was best served by the incompetent offshore guys no matter what they programmed.

    And this is why the ruse failed. At the very best, it might force the bosses to see that the coders aren't competent. But the bosses did not mind that beforehand, so they will still not mind that afterwards. Making the bosses "see the light" won't change anything about their personal agenda.

    It's not about what is true objectively, it's not what the customers want, it's not about what the company wants, it's not about what's written in the mission statement of the company: It's about what they, the specific bosses, really want to achieve the most.

    So in order to change their thinking, you'd need to find out their real objectives first. But of course, this often simply can't be done from the vantage point of someone much lower in the hierarchy. In which case, fleeing to greener pastures ist best.

  • Carra (unregistered)

    And if they change the DAO to return null for some reason, you end up with an endless while loop.

    Yeah, I would not write code like that.

  • Zenith (unregistered) in reply to Kashim

    You know, I find it funny that somebody eventually got around to removing my original comment but left so many others stranded in the moderation queue, especially since Snoofle claims to have watched this story unfold firsthand.

    What Kashim is doing here is shifting blame and it needs to be called out. He's OK with the offshore developers being incompetent. He's OK with them selling services they can't provide. He's OK with them secretly falsifying specifications provided by the architect. He's OK with management choosing to ignore a mountain of evidence that hiring, and continuing to employ, these clowns was a mistake. No, it's mean old Alex and anybody like him that's to blame because they "can't handle" these imbeciles making a mockery of our profession. Don't take pride in your work or offer to help others. Just move on so some idiots can claim "nobody could have seen this coming!1one" and vomit out articles about the "need" for even more visas due to a fictional shortage of talent.

    And some people wonder why we can't get traditional engineering disciplines to take software engineering seriously.

  • Zenith (unregistered)

    "If your company does off-shoring, and you can't handle working with the crappy developers that brings, then don't work for that company."

    It's right here - "you can't handle." That's where the blame shifts. Somebody not siding with the crappy developers would've worded it more like: "if your company starts off-shoring to crappy developers, the best course of action is just to leave." That wouldn't blame Alex who did absolutely nothing wrong. He did not choose to work for a company that offshores, the company he worked chose to start offshoring. There's a difference. Further, as it stands, what he's implying is that crappy offshore developers are immutable. I don't know which interpretation is worse. Is he suggesting they're a force of nature, like rainy weather in Seattle, and a random company's internal workings are as accessible as a daily weather report? Is he just sneaking "all offshore developers are idiots" past the censors by couching it in misdirected blame? Even the ending of "don't work for that company" is blaming Alex. It's telling him to stop doing something wrong (working for the company) instead of suggesting a positive course of action (working somewhere better). The type of mind games that go on with some of these development shops is astounding and perpetuating it with excuses is not helping the situation.

  • Menem (unregistered)

    So this Alex just writes stuff for months without writing a single line of code nor testing an architecture, no prototpyes, nothing tangible at all. Then whatever he did (UML?) gets cut into a million little pieces and is handed to that same number of developers across the ocean who are expected to understand whatever he wanted. Afterwards this Alex writes some weird syntax proving... what again? Even assuming these juniors where the worst in the world I call bullshit on them discussing the for-while for 6 weeks. Heres how these discussions may have actually unfold:

    • hey, did you see what what the architect commited? Does he really know what he is doing? Should I remove the while?
    • leave it alone, dont fight the client, it works anyways The story ends with Alex calling everyone a n00b on a word document, nice. Yhea, sorry Alex, you are TRWTF.
  • (nodebb)

    He should have just claimed that they lacked the necessary training to understand the code.

  • offshoredev (unregistered)

    Curious how all the stories on here make us (the offshore devs) the idiots. While I am not defending the dummies, please do realize that the scenarios can often be reversed. I have had on-shore people who were terrible managers or terrible developers. People who wouldn't listen to reason.

    1. we were 3 offshore devs from 3 different countries, the manager was a "know-it-all" in late 30s who would change requirements at his whim. We had to invent creative ways to keep our sanity. For example, once he wanted a widget on app's main screen that would kill the UX. We tried our best to make him understand but "guys, you don't understand this market, I am sorry, you just don't have the exposure to this cuture". Anyway, I added the button, pushed a new release and sent him build link from integration server. A few minutes later, I got "OH HEY, THIS IS HORRIBLE, PLEASE CHANGE IT BACK". I responded "It's only on your build, I did not change it for anyone else" (I had added a check for his device ID to show that to only him) . The other two guys just laughed.

    Another guy, this one was a developer. He had content sharing scheme for his app. The spec was overly simplistic (may I say stupid?). So, I changed the spec and implemented what made sense to me. 3 months later, he came with a new spec for content sharing, I told him give me 30 minutes. That guy, "I just gave you the new spec, you sure you can do it in 30 mins". I told him that I never implemented his original spec because it was flawed. The implemented spec (my spec) would need changes to a few LoC. Thankfully, he was not mad that I ignored his spec.

    there are other stories too.

    Sorry for the rant. I have been lurking here for a few years and I have not come across any stories where offshore guys had some brain cells. It feels a bit bad.

    Oh and I hate Alex for sabotaging already struggling devs.

  • Peter Wolff (unregistered)

    TIL that in "C-flavored" languages, a closing "}" always is followed by an implicit semicolon.

    Except when it is not, that is. E. g. in "do {...} while()".

  • (nodebb)

    Also in pretty much any braced thing that can have typedef before it, you need an explicit semicolon at the end of the statement.

  • Jag (unregistered)

    I always thought that the proponents of agile development shun doing BDUF (Big Design Up Front). Critics of BDUF believe it is poorly adaptable to changing requirements and that BDUF assumes that architects are able to foresee problem areas without extensive prototyping and at least some investment into implementation. In light of that perspective, the fact that the offshore team updated the spec seems okay to me. But others might disagree.

  • (nodebb) in reply to Loren Pechtel

    To be fair, it is not totally uncommon to teach students something like

    if (condition)
  statement
else
  statement;

    or

      while (condition) statement;

    so it's "obvious" that curly braces {} [em]combine[/em] statements to a single big [em]statement[/em].

    But what {} actually do, is just [em]group[/em] statements, similar to indentation of code blocks in Python.

    This behavior is really counterintuitive to minds educated in Mathematics (in particular set theory) and having learned Pascal-style syntax before C-style syntax. (Not to talk about someone that learned Mathematica language before really plunging into C-style syntax languages and learned to appreciate Mathematica's effort to reach maximum consistency everywhere.)

    (And I dislike it as much as ever.)

  • (nodebb) in reply to Steve

    Now that's silly - management doesn't read code.

    OTOH, management's wish to believe to understand code is exactly what I always assumed to be the origin of COBAL's ancient venerable syntax.

  • (nodebb) in reply to Jag

    the fact that the offshore team updated the spec seems okay to me

    No. Never. Ever. You can propose to change the specs of course (and I'd appreciate that - or at least hope so), but unless you're actually on-shore and know not only the project but its environment as well, you are not supposed to know the requirements of your client better than your client themselves.

    What they did (if I understand it correctly), is something like, "You said you wanted an armchair, but we corrected that for you, for you obviously need a stool - e. g. because you can get off a stool to all directions."

Leave a comment on “The For While Loop”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article