I've attended the "Zero to ten million users in four weeks: sustainable speed is the king" by Jodi Moran. Here are my notes (and bonus here are the slides from the talk: http://www.slideshare.net/plumbee/sustainable-speed-is-king-qconlondon-2012)
The session was a high level look at how maintaing a sustainable speed of delivery can be the key to the success for teams working in fast paces, high traffic, web based industries.
1. Speed - end to end time for each change. Sustainability - maintaining the speed for a long time period. Long probably means the lifetime of the project/app/game :).
2. Sustainable speed is desired because it gives your project responsiveness - you can react to changes in your users behaviour/business model changes/any external factors, it means greater returns - as you are able to deliver more features, especially in social gaming business it means you can earn more off your users, your investments are less - you deliver fast so you work less (time-wise, but not only).
3. Couple of methods Jodi used to achieve sustainable speed in her projects: Iterate & Automate, Use commodity technologies, Analyse and Improve, Create high-speed culture.
4. Iterate & Automate - be agile, break things down, focus on principles, reflect on what you did and adjust. Automate all routine work - building, testing, provisioning, deployment. Isolate your changes, high-risk components need to be separated from low-risk ones, so you can deliver faster.Launch with minimal product, minimal process and minimal technology. Prepare for the technical debt. Decide early on how you'll pay for it and when. Take it on intentionally when needed.
5. Use commodity technologies. This means it's easier for you to find people who will work on your product. It will be faster to set your development process up and running. Your team will understand different components of your system, and will be able to change them/work on them faster. Even complicated systems can be build on commodity technology as was proved in presented case stud (read/write game properties management tool that allowed the product owner tweak properties of the game and deploy it to test environment in "one step").
6. Analyse and Improve. You never have "too much" of data - you need this information for reporting, monitoring, data mining, predicate analytics, personalisation, split testing (a/b testing). We should collect both user and system data so we can track both application state and user behaviour as both are important. Split testing is especially important when maintaining sustainable speed - if you can analyse your data quickly you can react quickly. Good test means you don't invest time implementing things that do not work for your product.
7. Create high-speed culture. Teams arrangement is similar to you'r apps components arrangement - you want small, well specified modularised components that are responsible for providing a service and are independent from others. To manage communications keep the teams that need to talk to each other close to each other. You can than "reuse" your teams ike you would reuse your services. Hire best people, trust them, make them responsible and excited about your product.
8. "Source Code Is A Liability, Not An Asset" (http://blogs.msdn.com/b/elee/archive/2009/03/11/source-code-is-a-liability-not-an-asset.aspx).
9. Testing: think about out why do you test your application. Shouldn't developer be responsible for the code quality (if the code does what developer intended)? Shouldn't product owner be responsible for features implemented (Is the application doing what he intended?). Won't user behaviour verify if the feature implemented is what users wanted (react fast, a/b test)?
10. Load testing: why do we perform load tests? If we're testing for capacity for new users mind that hardware is cheap now and scaling is easy with the cloud being around and all. If we're testing new feature capacity, we can do the same more effectively and safely with a dark launch.
11. Creators are responsible for quality, as well as for the product being alive in production - you don't need a separate operations team to be "on call", taking care of production environment. Engineers are responsible for the environments as well.
No comments:
Post a Comment