I see Taleb's ideas more and and more frequently applied to software development e.g. by authors such as Kjell Jorgen Hole in his "Anti-Fragile ICT Systems", and Michael T. Nygard in his "Release It!: Design and Deploy Production-Ready Software" (2nd Edition).
I think it's a little risky to transfer concepts from one domain to another, without taking into account the working assumptions and the surrounding context. For example something as fundamental as the definition of the concept of 'Black Swan' à la Taleb, is a tricky one, let alone its application to the world of software development. Maybe the best we can do so far is to take this in a very broad sense, and interpret it as a general principle: "first, avoid ruin". But, almost by definition, the events outside the control of a software development/project team can be so extreme that it might render the practical application of the principle almost meaningless. (Think about it: what does it really mean in the context of creating a software product really?)
There are of course meaningful principles that apply to creating investment portfolios, strategies, etc.; do they really apply to software development? Are we using similar data sets and statistics for software development and combination of financial instruments? Can we? That's something I can't say "yes" immediately.
Thank you for pointing out where my analogy breaks.
My point is not to denigrate any popular process or advanced technological tools. And I don't embrace big design up front for everything, especially when it makes it even more easier (and more expensive) to paint yourself into a corner. I wanted to draw attention to a simple fact: sometimes the medium of production is not necessarily the best medium for thinking about that production and being immersed in that medium can prevent you from realizing this, thanks to the human psychology that took hundreds of thousands of years.
"... a host of new features such as file and webpage manipulation and advanced colour sensing, cloning and much more besides, Panther provides advanced usage for avid Scratchers around the globe as well as new programmers looking for a fluid, easy to understand starting language."
I was just about to write a response to 'Scratch bashing' ;-). Luckily you have voiced most of them. So I'd like to add the following:
The Scratch programming environment, being the most child-friendly system I've ever seen so far (and I have tried to teach children, as well as adults with zero prior programming experience, using environments as different from each other as StarLogo and Python), lets children create amazing programs, but most important of all introduce the fundamentals of computational thinking and creativity with almost zero barriers for entry. From a programming perspective it definitely has a lot of shortcomings (most of which have been addresses by 'add-on's or similar systems built on top of it) but if you want to show the basics to a bunch of kids who are 7 or 8 year olds, then it is a great system.
Moreover, the social aspects of Scratch, namely easily publishing your projects and seeing the source code of others, are a gift. Try to do the same with Python and GitHub (one of my favorite combinations when I'm not dealing with children ;-), starting from scratch (some pun intended) and showing them all the tools... I'm curious how far their attention span would go.
As part of the Eclipse Juno release, a new project, Eclipse Code recommenders joins the train.
The idea of the code recommenders is to adjust and filter the set of proposals given when the code proposal key sequence is triggered. By default, Eclipse will show the list of public methods (or fields) in alphabetical order. However, when coding against unfamiliar APIs, or ones with many overloaded methods (Quick! Which of the 6 Date constructors is the right1 one to use?), it is not always clear which one should be called.
The code recommenders tool has a database of prior code samples, along with frequencies of the method callers, and uses that to prioritise which method or constructor to prompt for. If most Date constructors use either the zero argument (or single long argument), then these two choices will be presented first, with other ones filtered out. In addition, the proposal can use context sensitive information, so if completing a method call of timezoneOffset = date.get it will prompt the getTimezoneOffset() method as the first selection.
The recommenders project also provides a list of context-sensitive snippets of code. These can be constructed manually, or inferred from existing code samples. As with other Java templates (such as main or syserr), these can be used to quickly implement code.
InfoQ caught up with Marcel Bruch, creator of the recommenders project, and started by asking what prompted the creation of the project:
The "Pedagogy" section is superb: "Systematically investigate the interaction of pedagogical approaches and motivational levels so that teachers can broaden participation. With school sites in Alaska, California, Georgia, Ohio, South Dakota, Texas, and Wyoming and over 10,000 student-created games and simulations, we were able to explore a uniquely rich set of motivational and educational data.6 We found the main common factor supporting motivational levels and skills across different school contexts, gender, and ethnicity was scaffolding. Of all the factors we considered, scaffolding was the only significant one. Scaffolding, a pedagogical aspect indicating the degree and kind of support provided by a teacher, was assessed through classroom observation. Direct instruction, which provides a very high degree of scaffolding, highly polarized motivational levels between boys and girls. With direct instruction a teacher provides step-by-step instructions at a detailed level (for example, "click this button," "paint the frog green"). Direct instruction is particularly unappealing to girls. With less scaffolding, such as with guided discovery, a teacher employs a more inquiry-based approach that includes classroom discussion (such as "what should we do?" and "how can we do this?"). In guided discovery, the motivational levels of girls not only approached the motivational levels of boys but often exceeded it. In a number of classes, using guided discovery raised the motivational levels of girls to 100%. This is exciting because it suggests that broadening participation is not a question of difficult-to-change factors such as school affluence. Preconceived notions such as lower interest of girls in programming turned out to be unsubstantiated. Even in cases where most literature would suggest a gender effect, for instance if there were significantly fewer girls in a class, we found that the right level of scaffolding could raise the level of motivation in girls to be even higher than that of boys."
I think it's a little risky to transfer concepts from one domain to another, without taking into account the working assumptions and the surrounding context. For example something as fundamental as the definition of the concept of 'Black Swan' à la Taleb, is a tricky one, let alone its application to the world of software development. Maybe the best we can do so far is to take this in a very broad sense, and interpret it as a general principle: "first, avoid ruin". But, almost by definition, the events outside the control of a software development/project team can be so extreme that it might render the practical application of the principle almost meaningless. (Think about it: what does it really mean in the context of creating a software product really?)
There are of course meaningful principles that apply to creating investment portfolios, strategies, etc.; do they really apply to software development? Are we using similar data sets and statistics for software development and combination of financial instruments? Can we? That's something I can't say "yes" immediately.