Tuesday, June 12, 2012
2012 New Book: How to Create the Next Silicon Valley
By Frederick E. Allen , Forbes Magazine
(This article appears in the April 23, 2012 issue of Forbes.)
http://www.therainforestbook.com/
How to Create the Next Silicon Valley
People everywhere keep trying to ¬duplicate the success of Silicon Valley as an incubator for innovation and wealth. Victor W. Hwang, a Los Altos Hills, Calif., venture capitalist, has been studying what makes the Valley succeed and so many of its imitators fail, and he’s convinced he has found the answer. Not only that, but he’s putting his ideas to the test, trying to foster new versions of the place around the world. How? It’s about how people work together.
“Instead of thinking of Silicon Valley as this exceptional place,” he says, “think of it as a result of the world’s biggest experiment—the opening of the American West. Take people running away from the rest of the world, strangers with diverse experience and talent, and what happens? What emerges is a body of culture and invisible rules, and a mechanism for trusting strangers.” We think of the Wild West as a lawless place, but it was the opposite, Hwang says. And the same goes for Silicon Valley. Both relied on people from vastly different backgrounds and places, driven by passion, coming together to build environments of unusual trust and mutual support.
At age 40, a product of Harvard College and the University of Chicago Law School, Hwang has spent five years as the managing director of T2 Venture Capital, where he has been involved with numerous startups. Trust in Silicon Valley “happens in a million microtransactions,” he says. “It’s sort of understood. In other places they’d think you’re a fool. An entrepreneur in the Midwest will ask you to sign a nondisclosure agreement before he’ll say what he’s doing. In the Valley he’ll blab, he’s so excited. That N.D.A. is a waste.”
Hmm. Doesn’t sound like the sort of argument you hear in multibillion-dollar tech-related patent disputes. But Hwang argues that to develop networks of innovation, you must build “tribes of trust.” His set of rules he has entrepreneurs and investors and others sign: 1) Thou shalt break rules and dream. 2) Thou shalt open doors and listen. 3) Thou shalt trust and be trusted. 4) Thou shalt experiment and iterate together. 5) Thou shalt seek fairness, not advantage. 6) Thou shalt err, fail and persist. 7) Thou shalt pay it forward.
“On the Palestinian West Bank we’ve helped shape the work of 15 to 20 startup companies,
in a fairly isolated place,” he says. “In Bogotá my partner, Greg Horowitt, helped organize a convening point for the ¬entire startup industry.”
Where else should we look for future Valleys? The best places are refugee economies, where people have had to start from scratch. That’s why Israel has become so innovative, Hwang says: “Israel’s an interesting dichotomy, a zero-sum culture of tough negotiators but with a startup community based on collaboration and trust. The kibbutz was the foundational culture.”
Which American businesses get this right? Pixar. “They were so afraid of ¬becoming big and successful, they designed everything around a culture of continuing nascent creative talent. Also a lot of ad agencies. They have had to systematize the process of creativity.”
Hwang and Horowitt just published a book, The Rainforest: The Secret to Building the Next Silicon Valley (Regenwald, 2012). The title reflects their belief that you have to see the Valley and the relationships it requires as a living environment, not an economic system. But isn’t a rain forest a place of brutality and lawlessness? “When we were in a natural state we all lived in highly trusting communities,” Hwang insists. “This actually reflects how human nature was at its inception.”
The Rainforest: The Secret to Building the Next Silicon Valley (Regenwald, 2012).
http://www.amazon.com/dp/0615586724
2012 New Book- THE RAINFOREST: the Next Silicon Valley
Book Review: THE RAINFOREST
The Secret to Building the Next Silicon Valley
http://www.therainforestbook.com/
Hwang, Victor W. and Greg Horowitt
Regenwald (304 pp.)
$12.99 paperback, $7.99 e-book
ISBN: 978-0615586724; February 4, 2012
BOOK REVIEW by Kirkus Reviews
In their debut business title, two venture capitalists offer an insightful, forward-thinking assessment of what makes
Silicon Valley tick.
If Silicon Valley can be held up as a living, breathing example of American ingenuity, why haven’t we been able to recreate it elsewhere? Hwang and Horowitt suggest that Silicon Valley is an innovation ecosystem they liken to a rainforest—hence, the book’s title. Thinking of Silicon Valley as a living biological system “helps innovators ‘tinker’ together in the same way that atoms ‘tinker’ together in natural biological systems ... [to] discover more valuable recipes for combining and recombining ideas, talent, and capital together.” The authors proceed to offer an engaging, highly creative analysis of the workings of a “rainforest,” using Silicon Valley as the prototype. They present 14 compelling “Rainforest Axioms,” for example, “Axiom #2: Rainforests are built from the bottom up, where irrational behavior reigns,” along with the “Rules of the Rainforest,” “Rule #4: Thou shalt experiment and iterate together.” The authors also explain how to build and measure a rainforest. The text is enhanced by well-designed graphic illustrations and explanatory charts. Hwang and Horowitt write with authority and wit, carefully backing up their theory with substantive examples. Readers get the feeling that the authors have unveiled a very big, important concept, one that could serve as the basis for intentionally, methodically developing other “rainforests” similar to Silicon Valley. However, they acknowledge that following the Valley’s winning formula is challenging, suggesting that “The Rainforest concept does not come naturally to many leaders” and that it requires “a new active capitalism” to create a rainforest. While Silicon Valley may not be entirely unique, replicating its ecosystem is no easy task.
A provocative study of innovation.
The Secret to Building the Next Silicon Valley
http://www.therainforestbook.com/
Hwang, Victor W. and Greg Horowitt
Regenwald (304 pp.)
$12.99 paperback, $7.99 e-book
ISBN: 978-0615586724; February 4, 2012
BOOK REVIEW by Kirkus Reviews
In their debut business title, two venture capitalists offer an insightful, forward-thinking assessment of what makes
Silicon Valley tick.
If Silicon Valley can be held up as a living, breathing example of American ingenuity, why haven’t we been able to recreate it elsewhere? Hwang and Horowitt suggest that Silicon Valley is an innovation ecosystem they liken to a rainforest—hence, the book’s title. Thinking of Silicon Valley as a living biological system “helps innovators ‘tinker’ together in the same way that atoms ‘tinker’ together in natural biological systems ... [to] discover more valuable recipes for combining and recombining ideas, talent, and capital together.” The authors proceed to offer an engaging, highly creative analysis of the workings of a “rainforest,” using Silicon Valley as the prototype. They present 14 compelling “Rainforest Axioms,” for example, “Axiom #2: Rainforests are built from the bottom up, where irrational behavior reigns,” along with the “Rules of the Rainforest,” “Rule #4: Thou shalt experiment and iterate together.” The authors also explain how to build and measure a rainforest. The text is enhanced by well-designed graphic illustrations and explanatory charts. Hwang and Horowitt write with authority and wit, carefully backing up their theory with substantive examples. Readers get the feeling that the authors have unveiled a very big, important concept, one that could serve as the basis for intentionally, methodically developing other “rainforests” similar to Silicon Valley. However, they acknowledge that following the Valley’s winning formula is challenging, suggesting that “The Rainforest concept does not come naturally to many leaders” and that it requires “a new active capitalism” to create a rainforest. While Silicon Valley may not be entirely unique, replicating its ecosystem is no easy task.
A provocative study of innovation.
Saturday, June 9, 2012
2012 ACM-ICPC Asia New and Revised Rules
2012 ACM-ICPC Asia New and Revised
Rules
I.
Definitions and Notes
1. The Asia Rules must satisfy ICPC spirits and priority:
a. Geographic balance for the entire Asia – Balance is not by
political boundary;
b. For the Asia site performance/growth 1 - Number of unique universities
participating
c. For the Asia site performance/growth 2 - Number of unique teams
participating
d. Special award teams (0-3 teams) by Asia Director each year.
(Team receiving this award must be ranked 15 or better in an Asia
Regional site and the home university must have made substantial contribution
to Asia Regional contests.)
2.
Contest Site
Steering Committee and Contest Advisory Council.
(Please
see detail guidelines in Specific 2012 Asis Rules.) Contest
Councils have no executive, supervising or management authority over contest
site steering committee. Contest Councils have advisory, assisting, and
coordinating responsibilities to committee and recommendation duty to Asia
Director for host nomination in all levels.
Contest steering committee is semi-autonomous and is reporting to Asia
Director directly.
3.
Members of ICPC
Asia RCD/Council:
The
voting members of Asia Council consists of one vote from each Asia contest site
steering committee and one vote from each approved Asia contest sub-council.
The Asia Council meets once per year during the World Finals RCD symposium.
(Next meeting: June 30, 2013 at St. Petersburg, Russia.)
4. Terms
and definitions:
a. Sub-contests:
There
will be only sub-contest(s) under each Asia Regional Site Contest from 2012. (Before
2012, there were sub-site contests under each Asia Regional Site Contest and
they will not exist for 2012 and after.)
b. Contest
Registration:
Team
registration must be entered thru sub-contests. Teams are promoted (copied)
from sub-contests to Asia Regional On-site Contest by contest steering
committee. No direct registration is
allowed to Asia Regional on-site contests.
c. The
70-25-5 formula:
Counting
for site participation initial scores will only count teams accepted and
solving at least one problem in the sub-contests and in Asia Regional On-site
contests. The 70-25-5 formula will be applied to the site initial score calculation: Total number of distinct universities 70%; total number of distinct teams beyond the first team 25%; total number of teams in
the provincial and national (non-Asia
host) contests 5%. The site initial participation score will be the sum of
70-25-5 formula.
d. Site
reduction factors due to double registration:
Site
reduction factor example:
If
the percentage of students with double registration is 80% in China, for
example, then the site reduction factor will be 0.6 = (0.2 + 0.2+ 0.8) / 2. The
final site participation score is the result of initial score multiplied by the
reduction factor.
e. Each
contest participant can register at most two sub-contests in Asia and his/her
team may be promoted to at most two Asia Regionals.
II.
World
Finals Teams Allocation Formula for Asia 2012:
1.
Contest Site Basic Slot Shares – historical
slot shares
(40%
of WF slots allocated to Asia).
a. Add the number of WF
teams from the last two years within each administrative sub-region to obtain
the preliminary scores for each administrative sub-region.
b. The preliminary administrative
sub-region scores are distributed to each site proportional to the site participation
scores to obtain the basic site scores.
c. The site basic scores
are then normalized to 40% of the WF slots to obtain the Basic site slot
shares.
2.
Contest Site Bonus Slot Shares (60% of WF
Asia slots.)
a. The bonus score for each
site is obtained by adding:
The current year site performance
(site participation score) – 40%;
the growth of the site or
area (increase site participation from last year) - 40%; and the innovation of contest
site plus the need of the Asia growth -20%.
b. Each site bonus score is
normalized to 60% of WF slots to obtain bonus site
slot shares.
c. The slot share for each site is the sum of
Basic and Bonus slot shares.
d. The teams advanced in
each site are decided by applying 0.3 – 0.6 - 1.0 formula within each administrative sub-region
until slot shares of all sites in the administration sub-region are exhausted.
(Asia Director may elect different formula other than that of 0.3-0.6-1.0 when the situation demands.) The formula of
0.3 – 0.6 – 1.0 indicates 0.3 for foreign team and 0.6 for repeated domestic
team to encourage international participation and to take care of the double
registration complexity.)
3.
Discretional
slots (0-3 slots)
Discretional slots by Asia Director are for the growth of ICPC
Asia, for the contribution by a host university to Asia contests, and for the
special award. (Teams receiving these slots must be ranked 15 or better in a
contest site.)
4.
Slots
offered by a steering committee
A contest site steering committee may offer slot to a team from
other
administrative sub-region with a criteria approved by Asia
Director.
III.
Absence in WF by an advancing team
It is
the team’s obligation to do everything to attend World Finals once the team has
accepted the WF invitation. If the advancing team can not participate the WF
for any reasons including visa issue, examination schedule conflict, financial
difficulty or
student job status, the team must inform ICPC
headquarter or Asia Director at least two months before the WF. Failing to do
so, the team’s home university will be penalized that the university will be
prohibited from sending team to WF for the next two years. This allows Asia
Director to have enough time to obtain a replacement team. (No team member
replacement can be accepted.) It is very important for all team members to take
care of the passport, visa, school issue, job situation, and travel problem as
early as possible.
Friday, June 8, 2012
2013 ICPC World Finals Call for Problems
2013 International Collegiate Programming Contest Finals
Call for Problems
The ACM International Collegiate Programming Contest is seeking programming problems for the Contest Finals. Contest Finals Judges will be selected from among those who contribute problems. Each contributor must submit at least two problems, each consisting of
* a problem statement
* an estimate of the difficulty of the problem
* a brief description of the algorithm used in the solution
* a solution in C/C++ or Java
* a comprehensive (but not necessarily exhaustive) annotated test data set
All problems must be submitted by Tuesday, September 4, 2012.
This date is firm and cannot be extended.
I will send an acknowledgement when I receive a submittal. If you do not receive an acknowledgement within a week, please contact me again.
The "Guide for Judges and Problem Contributors" is attached. Please read this document carefully.
If you have any questions or comments, please contact me.
Dick Rinewalt
D.Rinewalt@tcu.edu
PS: Please forward this to anyone who is interested.
==============================================================================
Guide for Judges and Problem Contributors
2013 International Collegiate Programming Contest Finals
Judges for the 2013 ACM International Collegiate Programming Contest Finals
have the sole responsibility for producing the test problems (including test
data and expected results) used in the contest and for assessing the
correctness of solutions produced by teams competing in the contest. This
guide is an attempt to assist judges with those responsibilities.
Problems from previous Contest Finals are available at the ICPC web site
http://icpc.baylor.edu
These may be used as further guides for producing problem statements.
If you have more questions, please contact:
Dick Rinewalt
College of Science & Engineering
Texas Christian University Box 298960
Fort Worth, Texas 76129
Office phone: 817-257-7721
D.Rinewalt@tcu.edu
Problem Statements
1. Each problem must be unambiguously described in English.
2. All problems must require input.
3. Unless the core of the problem is input/output related, the formats chosen
for input data and the displayed results should be relatively simple.
Still, the format of the input data and the appearance of the expected
displayed results must be described in suitable detail.
4. Multiple data sets testing different cases are appropriate; make the
problem statement include iterative data sets as input to avoid using
separate input files.
5. Anticipate questions about special cases. Where appropriate, explicitly
state that certain special cases will not appear in the input data. It is
not necessary to specifically identify the special cases that will appear.
6. Indicate the precision that is required for real results.
7. Contestants must write solutions for problems in a short time. While very
simple problems are not appropriate, neither are problems that require a
great deal of code; a few hundred lines of Java or C should be an upper
limit on what can be expected in a solution.
8. The program and chosen test data should not require excessive execution
time. Contestants' solutions may be less efficient than yours and so a
generous margin is allowed for execution. If your test data requires the
program to execute for a long time, then incorrect student solutions
(e.g., those with infinite loops) will take an excessively long time to
judge. We would like to avoid those situations.
9. The problem description (excluding sample input/output) should generally
require at most one page.
Judges' Solutions
1. For each problem you propose, prepare a solution in C/C++ or Java.
Solutions in multiple languages will be appreciated.
2. Include comments in your code, even though the contestants' code need not
be commented.
3. Make sure that your program correctly solves the problem! Include test data
that illustrates the generic and special cases that you expect the
contestants' solutions to handle.
Test Data
1. Data must be unambiguous when printed. Consider carefully those cases where
trailing blanks (or leading blanks, etc.) will make a difference in a
program that processes input data.
2. If several test cases are included, describe the manner in which data for
the test cases is separated in a single file.
3. Include a rationale for each of the test cases you provide. This will help
identify missing test cases as well as identify those cases where a student
solution fails.
4. Put a copy of the sample input data first followed by general cases, ones
which student solutions are likely to get. Stress tests (boundary values)
should appear last.
Submission of Problems, Solutions, and Test Data
1. Use electronic mail and send all files as either
* MS Word document,
* RTF,
or * flat ASCII.
PGP encryption is encouraged but not required.
My public key is attached to the end of this message.
2. Do not put your name in documents containing the problem statement,
solution, or test data.
3. Be discreet about problem statements and solutions. It is not appropriate
to discuss problems with people not involved with the contest.
4. Problem selection will be completed in October.
Judging Criteria at the Finals
1. Each solution proposed by a contest team will be judged as acceptable or
not. If not, at least one of the following comments will be returned to the
team:
* Run-time error
* Time limit exceeded
* Wrong answer
2. Contestants may ask for clarifications of the problem statements. When
appropriate such clarification will be provided.
Summary
Each proposed problem must include the following components:
a) a problem statement
b) an estimate of the difficulty of the problem
c) a brief description of the algorithm used in your solution
d) a correct C/C++ or Java solution to the problem
e) a comprehensive (but not necessarily exhaustive) annotated test data
set for the problem.
Call for Problems
The ACM International Collegiate Programming Contest is seeking programming problems for the Contest Finals. Contest Finals Judges will be selected from among those who contribute problems. Each contributor must submit at least two problems, each consisting of
* a problem statement
* an estimate of the difficulty of the problem
* a brief description of the algorithm used in the solution
* a solution in C/C++ or Java
* a comprehensive (but not necessarily exhaustive) annotated test data set
All problems must be submitted by Tuesday, September 4, 2012.
This date is firm and cannot be extended.
I will send an acknowledgement when I receive a submittal. If you do not receive an acknowledgement within a week, please contact me again.
The "Guide for Judges and Problem Contributors" is attached. Please read this document carefully.
If you have any questions or comments, please contact me.
Dick Rinewalt
D.Rinewalt@tcu.edu
PS: Please forward this to anyone who is interested.
==============================================================================
Guide for Judges and Problem Contributors
2013 International Collegiate Programming Contest Finals
Judges for the 2013 ACM International Collegiate Programming Contest Finals
have the sole responsibility for producing the test problems (including test
data and expected results) used in the contest and for assessing the
correctness of solutions produced by teams competing in the contest. This
guide is an attempt to assist judges with those responsibilities.
Problems from previous Contest Finals are available at the ICPC web site
http://icpc.baylor.edu
These may be used as further guides for producing problem statements.
If you have more questions, please contact:
Dick Rinewalt
College of Science & Engineering
Texas Christian University Box 298960
Fort Worth, Texas 76129
Office phone: 817-257-7721
D.Rinewalt@tcu.edu
Problem Statements
1. Each problem must be unambiguously described in English.
2. All problems must require input.
3. Unless the core of the problem is input/output related, the formats chosen
for input data and the displayed results should be relatively simple.
Still, the format of the input data and the appearance of the expected
displayed results must be described in suitable detail.
4. Multiple data sets testing different cases are appropriate; make the
problem statement include iterative data sets as input to avoid using
separate input files.
5. Anticipate questions about special cases. Where appropriate, explicitly
state that certain special cases will not appear in the input data. It is
not necessary to specifically identify the special cases that will appear.
6. Indicate the precision that is required for real results.
7. Contestants must write solutions for problems in a short time. While very
simple problems are not appropriate, neither are problems that require a
great deal of code; a few hundred lines of Java or C should be an upper
limit on what can be expected in a solution.
8. The program and chosen test data should not require excessive execution
time. Contestants' solutions may be less efficient than yours and so a
generous margin is allowed for execution. If your test data requires the
program to execute for a long time, then incorrect student solutions
(e.g., those with infinite loops) will take an excessively long time to
judge. We would like to avoid those situations.
9. The problem description (excluding sample input/output) should generally
require at most one page.
Judges' Solutions
1. For each problem you propose, prepare a solution in C/C++ or Java.
Solutions in multiple languages will be appreciated.
2. Include comments in your code, even though the contestants' code need not
be commented.
3. Make sure that your program correctly solves the problem! Include test data
that illustrates the generic and special cases that you expect the
contestants' solutions to handle.
Test Data
1. Data must be unambiguous when printed. Consider carefully those cases where
trailing blanks (or leading blanks, etc.) will make a difference in a
program that processes input data.
2. If several test cases are included, describe the manner in which data for
the test cases is separated in a single file.
3. Include a rationale for each of the test cases you provide. This will help
identify missing test cases as well as identify those cases where a student
solution fails.
4. Put a copy of the sample input data first followed by general cases, ones
which student solutions are likely to get. Stress tests (boundary values)
should appear last.
Submission of Problems, Solutions, and Test Data
1. Use electronic mail and send all files as either
* MS Word document,
* RTF,
or * flat ASCII.
PGP encryption is encouraged but not required.
My public key is attached to the end of this message.
2. Do not put your name in documents containing the problem statement,
solution, or test data.
3. Be discreet about problem statements and solutions. It is not appropriate
to discuss problems with people not involved with the contest.
4. Problem selection will be completed in October.
Judging Criteria at the Finals
1. Each solution proposed by a contest team will be judged as acceptable or
not. If not, at least one of the following comments will be returned to the
team:
* Run-time error
* Time limit exceeded
* Wrong answer
2. Contestants may ask for clarifications of the problem statements. When
appropriate such clarification will be provided.
Summary
Each proposed problem must include the following components:
a) a problem statement
b) an estimate of the difficulty of the problem
c) a brief description of the algorithm used in your solution
d) a correct C/C++ or Java solution to the problem
e) a comprehensive (but not necessarily exhaustive) annotated test data
set for the problem.