Experiences from building a global scale learning service
Experiences from building a web 2.0 platform<br />AthanasiosPapagelis<br />Epignosis LTD<br />email@example.com<br />
The time paradox<br />Assume a software system that needs 20 days to complete 80% of it<br />How much time will it take to complete 100%?<br />Answer = Infinite<br />As closer we get to 100% time becomes relative. We can never reach 100% as we need more and more time to cover the next step<br />
Balance between time and results<br />It is important to get something working quickly<br />Aim to 90% - this gives you a good balance between functionality-quality and time-to-market<br />Get used to reiterate later your logical and layout issues<br />Don’t loose long-run goals perspective over every-day hurdles<br />Balance is a key ingredient for everything<br />
Care for the “wrapper”<br />Build a decent web-site from the scratch<br />Use your brand as the glue for everything you do<br />Use a forum or blog to communicate with the users<br />Build documents, video presentations … whatever you can to explain your system<br />Look and be professional on all aspects<br />
Get used to people differences<br />Not all people are the same, work the same, produce the same<br />Make a good mix<br />You need the architect, you need the builder and you need the clerk<br />Motivate them and keep them as a team<br />BUT: You need at least a few extraordinary members to lead the process<br />And you need the correct attitude from all members<br />Don’t go with people that cannot communicate at all<br />
Get external support<br />Promoting your system is harder that you expect<br />Find the appropriate channels<br />Measure your site traffic, it is the only trustworthy success mechanism<br />Find people to help you<br />Building a community takes time and it is extremely hard<br />Help them back<br />
Keep it simple<br />In an iterative environment debugging can become a headache<br />Forget about unit-testing and other exotic debugging mechanisms<br />Write simple, well-structured code <br />Use continuous scenario testing (labor or automatic) <br />Have experienced system testers<br />If you have a user community include them to the testing process<br />
Get used to change<br />Change is inevitable<br />You should get prepared to handle it efficiently<br />Filter external interferences from the development team<br />Give them ample time to do it correct / work with them<br />Make sure that everything is simple so as to be able to adjust<br />Re-balance your system frequently to be change-friendly<br />Minimize source<br />Optimize code<br />
Products vs Projects<br />Projects have a deadline, you don’t have one<br />Projects get to 80%, you need to go to 95%<br />Most project management tactics are useless under a continuous development environment<br />A small development team can make miracles<br />But use ample resources for wrapper tasks (documentation, testing, marketing,…)<br />
Pick the correct tools<br />There will always be a variety of tools that can make the job<br />Do not get “attached” to certain tools<br />Pick the ones that can help your time-to-market equation and not based on their superiority<br />Be careful to pick those that will provide an optimized solution for the end-user<br />
Be honest<br />…to the team<br />…to the customers<br />…to yourself<br />Don’t offer biased advices. <br />Or whenever you do so make sure you are open about your bias<br />Don’t promise what you cannot deliver<br />Don’t aim to the impossible <br />Aim to the extraordinary <br />
Don’t give up<br />Building a product is a long-process full of good and bad moments<br />Each day has something new to give. Let yourself grow through them<br />Be persistent but not dogmatic<br />Don’t forget that opportunity meets preparation<br />
A particular slide catching your eye?
Clipping is a handy way to collect important slides you want to go back to later.