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.
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.
If Jonathan Ives submitted a design for Google Instant, and his design was better than the "obvious solutions", then it would test well. If a better solution tests badly then, by definition of the word "test", you're not testing it properly. Whether or not the test candidates are "obvious solutions" or created by designers has no impact on whether testing is good or bad. Maybe someone can test whether testing tests better than not testing :)
I'm not saying that designers' intuition can be replaced by testing, I'm only saying that testing can not be replaced by designers intuition as the article implies. A designers' intuition, after all, hopefully comes from the experiences of informally testing out designs in real life.
What really annoyed me about the article was the attitude of "We designers come up with brilliantly ground-breaking yet subtle designs, and if testing says there is a problem, then ignore the tests because we are always right. Isn't that right, boys? YEAH! WE RULE!"
I agree entirely. I'm very happy with Gmail, and switching from Winamp to iTunes just left me wishing that a Mac version of Winamp existed, even after using iTunes for about two years.
The central point of the article is that certain people (designers, for lack of a precise term) can use their intuition to get better results than actually testing alternatives; to quote the article:
"Testing can only tell you so much -- and it often only reveals that people only like things that are similar to what they've had before. But brilliant design solutions convert people over time, because they're both subtle and ground breaking."
The article provides no evidence to support its claim. For all the anecdotes, not a single one describes a situation where the intuitions of "designers" outperformed a solution based on testing alternatives.
However, the pro-designer propaganda flies thick and fast, repeatedly implying designers would have made a better solution, or seen the solution as obvious without the need for testing:
- "While that solution seems obvious and not particularly elegant"
- "Is it just us who find our eyeballs spinning in their sockets...?"
- "Obviously, none of these (prototypes) were going to work"
- "A little design know-how would have made that obvious"
- "(They eventually settled on a blue that is basically the average of all the blues used in hyperlinks across the web. Duh.)"
- "Google's 'solution' to providing instant results still seems so primitive and ugly"
- "But brilliant design solutions convert people over time, because they're both subtle and ground breaking."
- "testing artificially limits the worldview of the people"
- "has your G-mail or Google Reader gotten any easier to use, or less stressful on your eyes? Have either of them become a pleasure to look at or play with? No."
The author isn't interested in making a coherent argument. The author's interest lies in unashamedly gratifying the readers' sense of importance. It is a website for designers, after all.
He doesn't like frameworks? Yeah, it only took Apple a decade and millions of dollars to make the framework, but I'm sure I can knock up something better in a week or two. While we're at it, why bother buying an operating system when we can just write a better one ourselves? Can't be that hard.
As a Cocoa developer, I can say that this is the stupidest stuff I've heard in a long time. I can't believe I'm reading it on the front page of hacker news.
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.