Technology, Performance and Scalability - Presentation - Anjesh Tuladhar

Editor's Notes

• #2: I am not going to talk about how you are going to scale up your application to serve 1 million users 1 year from now, I am not going to talk about how you are going to improve your performance when your users reach 1 million. I will focus on some of the basic principles you need to remember during your app development and how much focus you should give in technology at this point and not 1 year from today.
• #3: Before we move ahead, I just want to tell you a bit about ebay. I am sure all of you are aware of this ecommerce company where people buy and sell products and do the auction. It’s revenue in 2013 is 16 billion USD and its current number of employees as of Dec 2013 is 33500. You can see the number of active users has grown to 152 million from 89 million from first quarter of 2010. Ebay was not built for 152 million users from day 1.
• #4: As we can see ebay has updated their entire system in 3 instances. Their first system was built over a weekend. The one built in 1995 was not built for 2002 ebay. There could be various reasons – there might not be technology available in 1995 or it could be too expensive or the technology might be changed in 5 years time. The fact is the right architecture to support today’s system might not be the right one in the next 5 years. We should know when we can sacrifice the existing system when the time comes. It’s not just users that are growing, the features/values might change over time. http://martinfowler.com/bliki/SacrificialArchitecture.html
• #5: From the ebay example we can see that there’s always time for you to think about the next 1 million users. Infact we might have to sacrifice our existing system to build for the next version? What we need to know at this instance is how many users will be serving in 1-3 months? Is it 100 or 1 million? And another question is are 10 of those 100 users willing to play for your services?
• #6: So the fundamental question becomes how can we make our app such that it makes the first user to pay for your services? Ofcourse there’s business aspects of your product which you already know about. The app has to be equally attractive and interactive so that users use them. You should have more or less idea about the design concept from the previous session.
• #7: Another fundamental question is how much time do we have? We will just go through the basic principals and good practices so that you can cater to minimum number of users in less time – like ebay did. Dec 1 deadline
• #8: You know your business case, also there will be comprehensive seminar/training on business and marketing. User experience and design – you should have got some good idea from the previous sessions. And we will discuss some time on MVP – what constitutes MVP and also what are the principals and guiding rules for the software development so that you can make best use of your available time, get most out of your limited time.
• #9: MVP is the small thing you can build that delivers the customer value. You are in better position to analyse it yourself or discuss with your mentors and peers to identify what are the key features that your app absolutely need to charge for your services. In case of confusion, you might want to analyse each feature and ask what if I take it out, will it have any impact on the core value of your app. If not, you can cut it out. And move on to the next feature. There might be number of Example in right handyman idea, the app could provide the efficient selection of the service providers based on the location using some algorithm. My feeling is to start with they need to get the inventory of all these service providers and their locations – with that much information, service seekers can search for the right match manually. MVP doesn’t necessarily include the algorithm – that could come to give added value to the users. Similarly there could be rating of the service providers by the seekers so that other seekers could rely on those comments to pick the person and reliable person. These could again go to the next phase or after MVP. But it might also depend on the team to decide what constitutes the MVP. Just make sure that you are able to deliver the right amount in limited time.
• #10: Technology is the core of your work whether it’s MVP or not. It’s important to ask how much depth should we go into technology. We just need to ensure that given the time frame we have, we don’t over engineer our technology targetting 1 million users and also that we don’t do Premature optimisation of the codebase before starting to work. Often times, we tend to spend too much time on small features trying to make it efficient Leaving the important features for later.
• #11: Thinking too much into the future. http://www.codesimplicity.com/post/what-is-overengineering/
• #12: This is the code for applying strategy pattern.
• #13: That piece of code could have been replaced with 4 lines of simple switch case. Avoid those kind of over engineering when you are developing application. How do you know when you are doing over-engineering? It will come from experience as well, sometimes we search for the solution in the web and come Up with complex solution than needed. Look for ways to simpler code while working on your app.
• #14: From the technology perspective your high level architecture would be something like this. You will have a mobile application which talks over internet/sms to the web component through some API. Web would also be the key part of your system and your web is exposed through set of APIs.
• #15: You will be using one of the available web services based on your knowledge. How to choose one over the other? It also comes from experience but you should understand why choose one over the other and what benefits you get. For e.g. I guess many would choose REST over others as it’s easy to understand and implement.
• #16: It’s not just enough to have web services in place, you should also need to consider the security aspect of your API. You don’t want to risk the personal info of your users It’s upto you to decide how to choose one over the other. Again for the start, you may start with the basic authentication and move on to the more complex one.
• #17: There will be no excuse if your application was working yesterday or just an hour ago. Errors are part of the application, you should do your best to capture the exceptions so that users don’t get lost. If your app keep on crashing, do you think your user will come back to use them?
• #19: I am not talking about the tests you do by going into your application manually? I am talking about testing the kind of features which works and yet you are not confident if it’s working or not. Writing tests are your own decisions and if you can sleep sound at night without worry, then you probably don’t need to do that. Otherwise remember that you might become sleep-less at night. Just make sure that your key functions have proper unit-tests to ensure sound sleep.
• #20: Like I said before nobody is going to poke around and see if you have automated deployment in place. But it’s going to be huge time saver if you have to release your changes on a regular basis. Deployments become less error prone with such mechanism in place.
• #21: Your app performance is of great concern. If it’s slow to use, then you are definitely losing your users. Apart from the business case, your user should wait least amount of time to get information in the Use of caching
• #22: Again scalability comes back to the question of how many users your system can support and following the example of ebay, there will be plenty of time to work to handle scalability.