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.
FWIW, I've seen good Scrum and bad Scrum. The company I work at currently actually does an amazing job with Scrum. Cases like these help me have faith in Agile as a whole.
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.
Keep in mind though, the statement that "and get 3x the functionality" <- right there, that's what is unmeasurable. We can't know. We have no unit of measurement, so no one could possibly know. A practice could be 100x faster, but because software is rarely as important as marketing, sales, and luck, we'd never know. A dev team that's 100x slower could still win, and it probably happens regularly. It's the essential issue with all tech discussions. We assume that "hand waving" someone would notice. But without any unit of measurement, I posit that no one ever will. There are so many network effects that change the success of a software project that is unlikely that even in another 50 years we will have consensus.
If you read the abstract of the paper that the post refers to, it actually says that the size of a _class_ affects the number of bugs _in that class_. That's something very different to the size/bugs correlation for a whole application.
This is a hugely important overlooked point. When the measurements have a systematic bias, a product optimized to those measurements will have systemic problems. In this case: large, easy-to-understand classes that are excessive in number and completely fail to interoperate correctly.
It's a pretty ignorant criticism to complain that Apple doesn't do enough B2B, that's like complaining General Electric doesn't do enough pharmaceuticals--it's not even in Apple's business scope to worry about B2B, they make consumer and prosumer products. I treat idiots with the respect they deserve.
You get my point thought regardless of the example, Oracle doesn't make phones, and Samsung doesn't make game consoles.
Here is a quote from Jobs: People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully.
And can you give an example and cite how Apple tried and failed to enter B2B?
I am not saying Apple isn't doing well, just that they are great at consumer products but "meh" at business products. That is not a problem though. They are great a consumer products and I admire their ability to release a product without what would be essential features to others because they are not satisfied with it. For example, cut and paste was missing from the iPhone until v3.0.
Apple is great a certain things and at deciding to focus on those areas, such as dropping XServe and WebObjects.
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.