There are many paths to innovation. At one extreme, we have large companies who create research labs, staff them with world-class Ph.Ds, and set them working for years to solve extremely complex technical problems. At the other extreme, we have the proverbial "two entrepreneurs in the garage" working on a shoe-string budget. Between these two extremes, we have all sorts of combinations of organizational structure, team size, budgets and time horizons.
History shows that world-changing innovation is possible through all of these paths. But history also shows that, as companies grow in size and reputation, they almost inevitably become more conservative and risk-averse when it comes to considering, and investing in, new ideas and disruptive technology – often with disastrous results.
In this presentation, Google's Senior Engineering Director Patrick Copeland will introduce three basic models for innovation: Top-Down, Democratic and "eXtreme". He will describe how Google's core beliefs, culture, organization and infrastructure have successfully encouraged and enabled Democratic innovation throughout its growth. He will conclude by presenting and discussing "Unleash the Innovators", a practical manifesto and manual to stimulate and leverage eXtreme Innovation in any organization.
There doesn't need to be a trade off between application performance and ease of programming. Node.js abstracts the problem of concurrency well; programmers with little experience tend to create servers that scale into the thousands of connections. For example, at Node Knockout, a Node.js programming contest, in 48 hours contestants developed sites that were handling thousands of requests per second, pushing 80 megabits/sec - using less than 256mb memory, less than 1% CPU, in a single process. By addressing the hard architectural problems head on, many development cycles of rethinking may be saved by choosing a completely asynchronous system.
In the last decade or so we've seen a number of new ideas added to the mix to help us effectively design our software. Patterns help us capture the solutions and rationale for using them. Refactoring allows us to alter the design of a system after the code is written. Agile methods, in particular Extreme Programming, give us a highly iterative and evolutionary approach which is particularly well suited to changing requirements and environments. Martin Fowler has been a leading voice in these techniques and will give a suite of short talks featuring various aspects about his recent thinking about how these and other developments affect our software development.
by Sid Anand
The CAP Theorem states that it is possible to optimize for any 2 of Consistency, Availability, and Network Partition Tolerance, but not all three. Though presented by Eric Brewer in 2000 and proved in 2002, the CAP Theorem has only recently gained significant awareness and that primarily among engineers working on high-traffic applications. With spreading awareness of the CAP theorem, there has been a proliferation of development on AP (a.k.a. Available-Network Partition Tolerant) systems – systems that offer weaker consistency guarantees for higher availability and network partition tolerance. Much of the interest in these AP systems is in the social networking and web entertainment space where eventual consistency issues are relatively easy to mask. Netflix is one company that is embracing AP systems. This talk details Netflix’s transition to AWS SimpleDB and S3, examples of AP storage systems.
3rd–5th November 2010