About Me • Self-taught web developer. • Building web apps since 2001. • Started Singapore PHP User Group in 2006. • Co-founded iOS Dev Scout (2012). • Worked in startups: Foound (2010) and mig33 (2012). 4 Saturday, 31 August, 13
About Foound • Won “best of show” at Echelon 2010. • Raised US$500K in Sept 2010. • Launched at DEMO Fall (in Silicon Valley). • Failed to gain traction beyond early adopters. • Relaunched as FoundApp in Sept 2011. X Saturday, 31 August, 13
I have an idea… Let's build it! • So you have a killer idea (you supposes). • You've got some folks believing in your idea. • You've got good vibes on the idea from potential users. • Landing page received promising response. • What next? 5 Saturday, 31 August, 13
Which Platform? • Web, Mobile, Desktop or… ? • Your potential users determines the platform. • Usually determined by who you think your early adopters are. 6 Saturday, 31 August, 13
Which Platform? • Best focus on a single platform first. • Eg. At launch: Instagram, Path, Plants vs Zombies only on iOS, Quora on Web only. Facebook on web only. 7 Saturday, 31 August, 13
Goals of MVP • Establish your product/ market fit. • Interaction model (how users use your app). • Mental model (how users perceive your app). 8 Saturday, 31 August, 13
Single Platform MVP • Limit your exposure to early adopters until your app is ready for a mainstream audience. • Get early adopters who can give you honest feedback (more from how they use your app, less from what they say). • Fine-tune and measure the product improvements in small iterations. 9 Saturday, 31 August, 13
Which Platform? 11 • Understand the features and limitations of each platform. • eg. iOS and Android ecosystem, UI conventions. • Google: mobile patterns, ui design patterns • Seek out open source libraries, services that can help you. Saturday, 31 August, 13
Platform: Web • Not just web browser on the desktop, but on mobile devices as well. • Different screen resolutions. Having responsive web design is a good goal. 12 Saturday, 31 August, 13
Platform: Web • Pros: • More screen real- estate to build features. • Easy and quick rollout of changes. • Allow for immediate and frequent updates. • Cons: • Sandboxed user experience - limited by what the web browser has access to on the operating system. 13 Saturday, 31 August, 13
Platform: Mobile • Pros: • Generally gives a more richer user experience. • Apps that take advantage of the power of the mobile device's capabilities. • eg. Camera, GPS location, gyroscope, accelerometer. • Cons: • Updates might take time to propagate to all users. Users might not update their app for a long time. Some markets, people just uninstall the app (instead of updating) if it stops working. • Tendency to support different versions of your application simultaneously. 15 Saturday, 31 August, 13
Platform: Mobile • Native app development is preferred. • Native apps are optimized for the mobile OS. Easily take advantage of OS capabilities. Predictable UX. • Hybrid apps are web apps masquerading as mobile apps. 17 Saturday, 31 August, 13
Why Not Hybrid Apps? • Cross-platform but usually lowest common denominator support of handset capabilities. • Invent your own User Interfaces for cross platform usability. • Limited hardware acceleration support. Usually via clunky 3rd party intermediaries (e.g. JavaScript). 18 Saturday, 31 August, 13
Platform: Application Backend • Web, mobile, desktop apps can exist as standalone & offline apps. • But modern apps are usually connected to some form of backend for data persistence and additional computation. • E.g. database storage, authentication, social interactions between users, computation of big data. 20 Saturday, 31 August, 13
Mocking Up • Modeling user experience. Flow from 1 screen to the next. • Low res mocks: Visualize the user interactions • High resolution mockups: Sense of proportion • Mock-ups: http://balsamiq.com/ 21 Saturday, 31 August, 13
Things To Consider • Who's the technically strongest person in your team? His weapon of choice is usually the fastest for your team to ramp up. • Are you willing to learn technical stuff? • Or would you prefer to hire / outsource? 23 Saturday, 31 August, 13
Programming Languages: Web • Build with web browser based technologies. • Choices are pretty limited unless you want users to install extra plugins for the web browser. • Essentials: HTML5, CSS3 & Javascript • To a lesser extent: Flash (ActionScript) & Silverlight (C#, VB.net). 24 Saturday, 31 August, 13
Conventional Web Apps • Dynamic web page rendered by a server backend (eg. Rails, CakePHP, Django). • Whole page is pre-rendered in the server and sent to the web browser. • Eg. WordPress.com blogs X Saturday, 31 August, 13
Conventional Web Apps • Pro: • Maximum compatibility on web browsers. • Con: • Longer load time because every request reloads the whole web page. X Saturday, 31 August, 13
Single Page App • Dynamic web page rendered in the web browser by JavaScript • Chunks of code are sent to the web browser and compiled for presentation by your browser's JavaScript engine. • Talks to backend application via RESTful API. Transfer small chunks of data in text format. X Saturday, 31 August, 13
Single Page App • Pro: • Faster page load because you are getting smaller chunks of data without reloading the whole page. • Cons: • Limited support on older browsers. • Horrendously slow on some low powered machines/devices. X Saturday, 31 August, 13
Programming Languages: Mobile • Languages used for native app development • NokiaOS, Android, BlackberryOS: Java • iOS: Objective-C • Windows Phone: .NET (C# or Visual Basic) • Both platform supports some form of C or C++ codes as well. • UI Components: https://www.cocoacontrols.com/ 26 Saturday, 31 August, 13
Programming Languages: Desktop • Depends on the operating system (Windows, Mac or Linux). • Chances are, some variant of C can be used. 27 Saturday, 31 August, 13
Programming Languages: Application Backend • Modern day backends can be build in any language. • For full web page rendering. • RESTful web service that returns structured data strings. • Differences can be negated by throwing servers (ie. money) at the problem. • Eg. Ruby, PHP, Python, Java, NodeJS (JavaScript) 28 Saturday, 31 August, 13
Programming Languages: Application Backend • Best practices: • Use a programming framework (eg. Rails, Sinatra, Laravel, CakePHP, Django, Express) as they have already solved many common problems faced in building an application. • Always use a separate server for testing. • Profile your code to gauge its performance. (e.g. Xdebug, NewRelic). Don’t pre-optimize. 29 Saturday, 31 August, 13
Managing a Team • Processes for rapid innovations • Get your strong & opinionated engineers to agree on a process for working together. • Trust in a process, not just people. • Model for sustainable growth • Industry best practices for *NOT* burning out. 31 Saturday, 31 August, 13
Agile Development Methodologies • Small batch approach to development. • Feature requirements structured as a story of how user will use the app. • Building features in small rapid iterations. • Cycle to Test > Build > Feedback. Repeat. • Working app every step of the way. 32 Processes for rapid innovation Saturday, 31 August, 13
Pair Programming • 2 programmers, 2 sets of keyboard & mouse, 1 computer (preferably with 1 massive monitor). • Counter-intuitive way of improving productivity. • Sharing the mental load in writing code. • 2 pair of eyes focused on a small batch of code changes. • Immediate code-review at time of writing. Improves code quality. • Tag-team approach to writing unit tests and codes to pass the test. 34 Processes for rapid innovation Saturday, 31 August, 13
Kanban-Style Project Management • During the sprint, your team should establish the different "stages" that your code changes goes through. • Eg. Test is written, code is written, code passes tests, deliver to the server for acceptance by product owner, accepted by product owner, await deployment to production. Deploy to production. • Just-In-Time development. 35 Processes for rapid innovation Saturday, 31 August, 13
Continuous Integration • Teams working on code together have a tendency of stepping on each other's "toes". • The sooner you discover the code conflicts and clashes, the better is is for your team. • An automated script that pulls together code from everyone in your dev team, runs automated tests on the code, and return the result. Merge conflicts, breaking tests, etc. can be discovered quickly and fixed (instead of at day of launch). 36 Processes for rapid innovation Saturday, 31 August, 13
Continuous Deployment • Once code is ready, app can be deployed automatically without human intervention. • Minimizes bad deployment due to human errors. 37 Processes for rapid innovation Saturday, 31 August, 13
Metric Driven Features • Features and changes based on measuring and discovering how users are interacting with your app. • Validated learning that leads to feature changes and/or pivots. 38 Model for sustainable growth Saturday, 31 August, 13
Agile development as renewing cycles • Agile dev life cycles can be characterized as "low-high-low intensity". • The low intensity periods are meant for planning and reflection. 39 Model for sustainable growth Saturday, 31 August, 13
Agile development as renewing cycles Iteration Planning Meeting • Structure your feature changes in phases. We sometimes call this an "Iteration". This can last between 2-4 weeks. • As product owner, you decide on the features u wish to see. • The whole team comes together for an iteration planning meeting (IPM) where we discuss the features in more details and discover the complexities involved. 40 Model for sustainable growth Saturday, 31 August, 13
Planning Poker • A good way to determine complexity is via Planning Poker. • Each team member is given a deck of cards (usually with numbers in Fibonacci progression). 41 Agile development as renewing cycles Model for sustainable growth Saturday, 31 August, 13
Planning Poker • After discussing a feature in detail, the Product Manager ask for their assessment - the team members will put up a card from their deck with a number, signifying what they perceive to be the complexity of the feature. • The median number shall be the assigned complexity point. • More discussion can be had if there is a high difference between the perceived complexity points given by team members. • This could be a sign that they do not completely understand the requirements. 42 Agile development as renewing cycles Model for sustainable growth Saturday, 31 August, 13
Retrospective • After each sprint, you wind down the intense period with a "Retrospective" - a kind of post- mortem/evaluation on the sprint. • This is a good time for you to discover weaknesses in your process. • It also allows your team to understand each other's working style better. 43 Agile development as renewing cycles Model for sustainable growth Saturday, 31 August, 13
Conclusion • Team can only be as effective as the product owner is. The product can only be effective when you have users. The business if sustainable when you have monetizing customers. • You point the direction of what to build, the team runs and builds them. • Building a process for rapid innovation will help you discover your product-market fit sooner. • Having a model for sustainable growth will help your team perform at peak levels. It also helps you scale up when need be. 44 Saturday, 31 August, 13
Communities • Hackerspace Singapore • Singapore PHP User Group • Drupal / Wordpress User Group • Python User Group • Ruby Brigade • Singapore JS Group 47 Saturday, 31 August, 13
miccheng
umsys
clown0082
ivargrimstad
k9i
hassaku63
wadayusuke
nozomiito
jrsaruo
deresmos
taikikawamura
mascii
chriscoyier
michaelherold
thoeni
pauljervisheath
rmw
sachag
colly
dougneiner
chrisshort
addyosmani
afnizarnur
jlugia