boyakasha

> It's a risk _mitigation_ strategy.

It's designed to mitigate _delivery_ risk, not _organisational_ risk.

> If a team can't pull off agile what do they think would have been a safer strategy?

I would probably argue that Scrum (which I barely consider to be "agile") is more resilient to inexperience, and therefore lower risk. It's the McDonalds of processes. You're not going to get amazing results, but it will still operate despite hiring a bunch of inexperienced people into it.

That's something to keep in mind, but it's not the whole picture. Just because it's not guaranteed to be true doesn't mean that it's unpredictable. Like, you can't guarantee that the file for a Rails controller exists in `app/controllers/`, but that doesn't mean that they are randomly scattered across every directory of the project. It also doesn't mean that every developer puts them in a different folder depending on their personality. Sometimes you need to read carefully to determine the exact behaviour, but you only need rules of thumb to quickly navigate around a project.

I literally hit two today. Off the top of my head:

    def enhance_payload(payload)
      payload[:h] = thing_h

      if situation_one?
        payload[:a] = thing_a
        payload[:b] = thing_b
      end

      if situation_two?
        payload[:x] = thing_x
        payload[:y] = thing_y
      end
    end

Which RuboCop suggests to turn into:

    def enhance_payload(payload)
      payload[:h] = thing_h

      if situation_one?
        payload[:a] = thing_a
        payload[:b] = thing_b
      end

      return unless situation_two?

      payload[:x] = thing_x
      payload[:y] = thing_y
    end

But if you move the first line of the method down to the be the last line, suddenly it's not important to use a guard clause anymore.

If you can't think of examples, then you haven't been doing much thinking.

> I've discovered that I am nonplussed by patterns that leave other devs downright emotional and it's just not worth the effort to discuss

One thing that annoys me (and I'm not saying that you're doing it here) is that the people who say it's not worth arguing about are usually the ones doing the arguing. Like, if it makes no tangible difference either way, then just let people do whatever. It literally doesn't matter. But that's not acceptable to the "it's not worth discussing" people, and suddenly it becomes very important to discuss consistency. And not just any old consistency. We can't just flip a coin. No, it has to be consistent with their favourites, which are correct and therefore not worth discussing.

My personal standard is that if somebody suggests a rule and nobody really opposes it then great, enable it. If there is opposition, then it stays disabled until one side can persuade the other. If they truly care about consistency then they are welcome to change sides at any time. Attempts to browbeat the opposition should result in some private feedback from their line manager. There are exceptions for things that matter, but a lot of this stuff just doesn't.

So you, I, all the HN commenters, and the author, all had the same probability of making $100,000 from iOS icons last week? Was it just a random roll of the dice? I guess we were just unlucky then. Fingers crossed for next week.

To say "it is really just luck" is honestly just ridiculous. Our probability was 0%. His probability was significantly higher, due to the previous work and decisions he has made. That's not "just luck".

There is no such thing as a deterministic, risk-free business strategy. You can only make bets, try to maximise your odds, and repeat. That's what the author is doing. I knew nothing about him before today, but I can see his business ethos. He's doing a good job, and the market is validating that with their wallets.

Exactly. There is a lot of post-hoc rationalisation happening, along the lines of:

> I like language/technology X. Why? Well I'm obviously a super smart and rational person, so my preferences could only be based on facts and logic. Therefore everything I like must be objectively correct. QED.

Anecdotally, the more someone prides themselves on being intelligent and logical, the less skeptical they are of their unsubstantiated emotional judgements.

Despite primarily working in dynlangs, I would guess that type systems affect developer productivity somewhere in the range of +-50%. While I have pulled that number directly from my ass, I think that if the effect size was larger then there wouldn't be much of a debate. If a company could swap languages for any given team and get 3x more functionality, or get the same work done for 1/3rd of the cost, we would know about it already. And to be clear, 3x productivity is achievable, but not by simply switching to Haskell.

> You're never going to get sensible dietary advice on HN.

> If you can't get sun you should eat a variety of food that contains vitamin D.

It's admirable that you prove your own point two sentences later.