Scale reduces diversity which increases vulnerability. Darwin would interrogate this potentiality in the following way(essentially articulating the characteristics and benefits conferred by his evolutionary model) : reproduction can essentially be viewed as scale in this kind of context: a turtle's reproduction produces lots of turtles, rather than a random assortment of lifeforms such as snails and rabbits, etc. In this sense, biological reproduction results in the 'scale' of some particular thing, i.e., 'more of the same', rather than 'different every time', i.e., differentiation, or diversity. The vulnerability produced by scale in this context is that some peril resulting from a change could render all instances of the scaled thing extict. Nature produces the differentiation required to increase survival chances in such circumstances by mutation taking place in the course of reproduction. What the OP's concern seems to introduce, at least from my perspective, is an argument for exploring the options and practicalities for considering the possibility of somehow contriving something akin to a 'mutation imperative' into the design policy leading up to the development of scaling processes, in order to introduce at least some potential for the level of differentiation to constitute a potential for adaptation and thereby confer a potential for survival in the face of what might otherwise be an extinction level event. It's kind of like advocating applying some kind of 'resilience theory' to 'scalable innovations', no? I don't know if anyone has already proposed or even implemented this approach elsewhere.
Democracy is decentralisation. It doesn't 'work'. It's what Churchill called 'the worst form of government'. Except for all the others. Its most egregious failure is that it often fails to undermine things that can and do subvert it. Decentralisation is like a Yin-Yang kind of thing, constantly challenged by its nemesis 'the forces of centralisation'. Ultimately decentralisation, just like democracy, is more resilient over time. At any one time, centralised systems can potentially bring more resources to bear upon a problem more quickly. But because decentralised systems can be designed to 'temporarily centralise' this 'emergency response capability shortfall of decentralised systems' is just a design problem. It turns out that it is also probably the most serious challenge to decentralisation. But because resilience, in the light of the challenges we currently face, is something we are all committing ourselves to tackling, expect 'designing decentralised systems' to stay at the top of the process design agenda for the forseeable future, notwithstanding any yet-to-be-experienced shortcomings and failings of decentralised systems that appear on the horizon.
Here's my few cents worth. I think this article has got things back to front. Sure, there may be a bubble, but it's nowhere near bursting. Yes, there are fast growth rates predicted for EVs, but they still account for reaching a very small proportion of the overall vehicle market for quite some time. There's every reason to believe that things may change much more dramatically, much more quickly. If this proves to be the case, there is an equally good chance that the number of EV makers could increase equally spectacularly before there is any kind of consolidation in terms of numbers of players. History shows that when we started the journey from horses to automobiles, there was at least one small independent car maker in countless towns and cities at a time when the lack of experience, standard parts or skills meant that the vehicles you built were nowhere near as likely to be reliable or durable as just about any electric car you could build yourself today. In those days it was a challenge to start designing and building a new car (ironically it was almost as likely in the early days that the car engine design would be based upon on electric, steam, gasoline, natural gas or diesel) but today it's actually relatively easy to design and build a car factory. Ok, differentiation might be a challenge if you are going for a low cost market, but guess what, history tells us that localism counts for a lot in nascent automobile markets and 'staying profitable' for a small manufacturer where production costs are as low as they are for making electric vehicles using mostly standard parts may mean that the bubble is going to get a lot bigger, a lot faster and the burst, when it arrives, will probably be much more like a slow leak in a worn-out tire.
Does anyone but me have the suspicion that the animosity towards solar roads was something to do with a 'nerve being touched', some kind of 'triggering'? Sure, they might not work out, but lots of stupid-sounding ideas ('a horseless carriage? Whatever next?') have turned out to work, just as much as lots of somewhat futuristic but nonetheless sensible sounding ideas have turned out not to be here yet ('flying cars are just around the corner'). Who knows, at some point in the future, with different technologies and materials, different efficiencies and performance, we might indeed find solar energy being collected from roads. Just as we are laughing right now at the current, ludicrously oversold and patently unsuccessful efforts, future generations may be laughing at our arrogant dismissal of an idea that might ultimately have just turned out to have been ahead of its time. Let's applaud the audacity of the solar roadways hubris in the spirit of uninhibited innovative endeavour, just as much as we pat ourselves on the back for having successfully spotted its obvious shortcomings and predicted its seemingly inevitable struggle for survival.
If "litter collecting crows" produces an amusing mental image, just imagine my momentary initial misreading of that healine with "intelligent cows" and somehow it seems to fit the "theme park" idiom far more appropriately.
Most of the lean startup methodology is all about 'determining requirements'. The leanness is about not bothering to spend too much time creating things without determining requirements. Sometimes, the requirements are your own and the requirement in question is creating things (like art) and so you can't possibly spend too much time on whatever it was you you were creating. Sometimes requirements need a very long study in order to determine them. Nobody is arguing against long study exercises, especially for wicked problems. Sometimes 'long termness' turns out to be big problems that are made up of lots of little requirements. You need long-not-lean studies and while they are being done, you may also want to try quickly evaluating shorter term hypotheses. So yes, we can talk about where the lean startup fits in to long-termness and wicked problems and yes, claiming that lean startup is over is a great stimulus for debate, so thanks, OP.
I had all sort of 'philosophical' reactions as I watched the video. One was 'wait and see' if this proves to be widely accepted. Another was 'even if this proves to be unrealistic' his concerns appear to be heartfelt and his commitment to pursuing them diligently seems to be strong, so dismissing them out of hand 'in ignorance of respected opinion elsewhere' would probably be hasty. Don't we need to offer a little extra patience with our fallible but often conscientious independent amateur researchers? Aren't these just our peers?
Using the sweeping assumptions embraced in this article, any 3D games which happen to cause motion sickness (due to the player having 'six degrees of freedom' in zero g) to a non-trivial proportion of players when played on a monitor or TV, such as Descent https://en.wikipedia.org/wiki/Descent_(video_game) prove unequivocally that 3D games 'will not work' on TVs or monitors.
Software developed using visual programming languages often has the potential/necessity to include content which constitutes a 'visual/non-visual hybrid' as the application becomes more complex: the boxes to which arrows are connected usually contain things which are lines of text/symbols/formulae, i.e. are not 'diagrammatic'. Visual programming languages tend to use diagrams for structure and 'notationally rich text' for content and are therefore addressing requirements for simplifying the representation of and increasing the intelligibility of the structure of application development as their highest priority. The reason why this rationale can seem to be problematic is because justifying/achieving the job of meaningfully 'separating structure from content' in software brings it's own highly contingent/subjective challenges (as any detractor of object-oriented design will be aware). For instance, how far could/should you go in trying to 'diagrammatise' the notational content of boxes in a boxes and arrows language. Is the fact that you are diagrammatising the app at all enough of a benefit in terms of reducing the learning curve/programming aptitude requirement, such that 'further/total diagrammatisation' is nothing more than a 'diminishing returns' consideration? What criteria do you use to decide the 'diagramtic benefit limit'? The biggest growing business in software development today is 'triple A games development' and visual programming languages are used as a way of giving designers the means to create content and gameplay without requiring the designer to have programming skill levels that match those of developers (developers can then optimise the designer's work by converting it into C++ to get the frame rate up and integrating it with the rest of their native codebase). Here's an example of an impressive case in point done in UE4 Blueprints without a single line of C++: https://www.youtube.com/watch?v=EjCandEgtHo
He was the inventor of continuous public self-reinvention. He saw the job of re-imagining and then sculpting his own public identity as being inseparable from the musical inspiration that propelled it. For him, if any new musical idea he had felt unique enough, he would feel driven to create a new persona to perform it.
It seems to me that if there was ever anything in the cannon of collective behaviour which didn't seem to the participants to be a game, but nonetheless actually happened to have some of the most uncannily engaging 'game mechanics' ever to grace a non-game, it is that decidedly odd phenomenon that is the cargo cult.
As long as you wake up in the morning with something to look forward to, something you are going to feel good about doing in the future, you will be able to get through anything.
The whole thing about 'wasting the crucial years of your life' applied to a time which has now passed. The Y Combinator observation that it's getting cheaper every day to start something potentially world-changing by making something a lot of people really want is not going to go away, just because you're older. Yes, your energy and health may decline in the coming years, but that could happen even if you were working on the startup of your dreams right now.
Never imagine that you're going to miss the boat: when you're feeling ready to do another startup, that will be the right time for you. This notion of whether you have a 'window' in your 'lifespan years' as far as starting startups is concerned might have once been 100% true, but if anyone tells you it's still true now, you cannot use expect the past to be a reliable guide.
Ok, I get it, we're all looking at page design and visualisation issues, which is the kind of thing we do here. But isn't anyone going to just marvel and express wonder and astonishment at the sheer majesty of the extraordinary achievements described in the videos?
How many of us deserve to be described as consistently:
1. beautifully spoken?
2. profound in thought?
3. joyful in outlook?
and yet despite possessing these outstanding qualities, never allowing those who do not seem to, to feel anything but encouraged to try to follow her example.
Rubin helpfully fills in a lot of blank spaces in what we already knew about this. The one nagging doubt that still lingers sits somewhere between what is doable, versus what is done. The Kinect, for all it's technological triumphs and impressive market performance, still leaves us waiting for whatever it was that made it seem like it was going to change everything. While few who have ever had the Oculus experience have any doubt that it could change everything, we mustn't forget that we are also all still waiting for the first concrete confirmation that this expectation will be met.
Kudos for the skepticism here. Sorry to have to rain on anyone's parade, but when there is a 'need' for opacity regarding the specifics of the technology in an announcement which exclusively confines itself to positivity in the way that this does. Admit it, 'an analytical chemist in the palm of your hand' does sound magical, but surely we are all duty-bound to ask probing questions. Personally, I am getting a good feeling about this project, but I sense that am just being swept up in the excitement. So please, please continue to act as a counterbalance to my optimism. The risks posed by either being misled or by sharing unrealistic enthusiasm can only be mitigated by a relentless disregard for such sentiments. I want to believe the dream that the protagonists portray: I need others who are less convinced to challenge it, even if I feel irritated by their cynicism.
Sensitivity to the user's emotions, and thus their capacity to feel insulted by such things as simplicity, explanation and repetition, is not an excuse for failing to address the need for simplicity, explanation and repetition, but advice to interface designers on the need to be both relentlessly explicit and yet at the same time not insultingly condescending is both familiar and unhelpful.
His examples are clear elsewhere in this otherwise thought-provoking talk, but in the case of reconciling treating the user as 'being drunk' with treating them as 'not being dumb', I think he leaves the door open to interface designers not still subjecting their work to sufficiently rigorous scrutiny: what does a dumb drunk user do that one who was drunk but not dumb would not do? How drunk do you need to be be to act dumb even if you are smart when you're sober?
Are you finding that you are getting better at asking the kinds of questions whose answers identify potential problems that would have otherwise only been apparent after you had accepted the job? It's just possible that this might be too much to ask, especially if the problems are sufficiently different every time. The answer to the 'is it me' question may quite possibly have less to do with your compatibility or suitability but may have more to do with 'diagnostic skill', in which case, perseverance may just pay off as you get better at it over time.
For and on behalf of any genuine non-mathematicians, a couple of questions: (1) what would have to be the case such that his latest advances in proof assistance would not live up to his expectations (2) what things outside the world of abstract mathematics (such as in, but not restricted to the world of software) would change (such that anyone outside the field would notice) if they did live up to his expectations?
This is a very interesting comment indeed.
I am far too poorly informed to be able to tell if anything you say here is reasonable, but I must admit that your comments all sound very reasonable.
But lets please get instead to the substance of the article that you are commenting upon: tell us more about what do you think regarding the implications of the central claims of the article itself?
Would you say the same if the article turned out to act as a spur for each of the two parties concerned to respond to its claims: if they do, and they do so candidly, you might find that at least some of the speculation that I made was correct.
Well, showing concern (by saying 'alas') that someone, or some thing had suffered Yorrick's fate, does not, as a phrase, or even in a headline, necessarily indicate that one has 'taken sides' in terms of whether that that fate was desirable. The article 'didn't clearly take sides' but instead speculated as to why the outcome of this challenge to the Rift could be both dramatic and unpredictable.