Recommended
Recommended
More Related Content
Similar to Game development, Start-ups, and Technical debt
Similar to Game development, Start-ups, and Technical debt (20)
Recently uploaded
Recently uploaded (20)
Game development, Start-ups, and Technical debt
- 1. GAME DEVELOPMENT, START-UPS, AND TECHNICAL DEBT Eriks Klotins
- 2. PhD student in software engineering, BTH “How to improve software engineering practices in start-ups?” 9+ years of experience in different roles in software engineering ABOUT ME ERIKS KLOTINS eriks.klotins@bth.se https://www.linkedin.com/in/eriksklotins/
- 3. THE FIRST CONCEPT GAME DEVELOPMENT Video games is A MIX OF ART AND ENGINEERING, a balance of what an artist can imagine and what is technically possible In contrast to other types of software, MOST OF THE GAME MECHANICS MUST BE INVENTED. Customers do not care whether to shoot at zombies, mend a farm, or drive a car, as long as it is fun For game to be fun and engaging, there must be A STRONG EMPHASIS ON NON-FUNCTIONAL REQUIREMENTS VIDEO GAMES EVOLVE OVER TIME, more content is added, games are ported to different platforms etc.
- 4. THE SECOND CONCEPT START-UP COMPANIES New companies created for a purpose to develop and bring a new, innovative product to market. Often lack resources and experience. Teams are minimal and build software ad-hoc way. There is a false belief that start-ups can write off any amount of technical debt if the product turns out unsuccessful
- 5. THE THIRD CONCEPT TECHNICAL DEBT Technical debt is DISCREPANCIES FROM GOOD ENGINEERING PRACTICES causing extra work later Technical debt can be planned and CAN HELP TO ACHIEVE GOALS FASTER at the expense of more work later Technical debt CAN BE A RESULT OF NEGLIGENCE, LACK OF SKILL, POOR DECISIONS and lead to bankruptcy.
- 6. A STORY DEVELOPMENT OF A GAME PLATFORM Build a website with 20 mini-games. Put together something quick-and-dirty to test if there is a market potential Games are mostly puzzle, attention games Use HTML5, because it is new and cool
- 7. A STORY DEVELOPMENT OF A GAME PLATFORM Build a website with 20 mini-games. Put together something quick-and-dirty to test if there is a market potential. Use HTML5, because it is new and cool! Just add 20 more games! 40
- 8. A STORY DEVELOPMENT OF A GAME PLATFORM Build a website with 20 mini-games. Put together something quick-and-dirty to test if there is a market potential. Use HTML5 because it is new and cool! Just add 20 more games! Can we have scoreboards, multiplayer features, and more stuff? 40
- 9. Web ,iPhone, iPad, Android tablets + phones (including cheap ones), Kindle Fire A STORY DEVELOPMENT OF A GAME PLATFORM Build a website with 20 mini-games. Put together something quick-and-dirty to test if there is a market potential. Use HTML5 because it is new and cool! Just add 20 more games! Can we have scoreboards, multiplayer features, and more stuff We want a mobile version for the entire thing 40
- 10. A STORY DEVELOPMENT OF A GAME PLATFORM Web ,iPhone, iPad, Android tablets + phones (including cheap ones), Kindle Fire Build a website with 20 mini-games. Put together something quick-and-dirty to test if there is a market potential. Use HTML5 because it is new and cool! Just add 20 more games! Can we have scoreboards, multiplayer features, and more.. We want mobile version for the entire thing (and 20 more games) 40 60
- 11. Web ,iPhone, iPad, Android tablets + phones (including cheap ones), Kindle Fire 60 40 A STORY DEVELOPMENT OF A GAME PLATFORM Build a website with 20 mini-games. Put together something quick-and-dirty to test if there is a market potential. Use HTML5 because it is new and cool! Just add 20 more games! Can we have scoreboards, multiplayer features, and more.. We want mobile version for the entire thing (and 20 more games) We want the product to be better than a competitor
- 12. A STORY DEVELOPMENT OF A GAME PLATFORM Build a website with 20 mini-games. Put together something quick-and-dirty to test if there is a market potential. Use HTML5 because it is new and cool! Just add 20 more games! Can we have scoreboards, multiplayer features, and more.. We want mobile version for the entire thing (and 20 more games) We want the product to be better than a competitor ..add better sound effects in all 55+ games Web ,iPhone, iPad, Android tablets + phones (including cheap ones), Kindle Fire 60 40
- 13. A STORY DEVELOPMENT OF A GAME PLATFORM Web ,iPhone, iPad, Android tablets + phones (including cheap ones), Kindle Fire 60 40 Build a website with 20 mini-games. Put together something quick-and-dirty to test if there is a market potential Use HTML5 because it is new and cool! Just add 20 more games! Can we have scoreboards, multiplayer features, and more.. We want mobile version for the entire thing (and 20 more games) We want the product to be better than a competitor ..add better sound effects in all 55+ games Why are these small changes taking forever?
- 14. DISAPPOINTMENT! Stalling development of new features to deal with ”small” changes in all the games Unmanageable code, written by different developers in a hurry using an ad- hoc framework Architecture, built for few simple web games, ended up supporting 9+ platforms and 60 games Documentation were in a form of emails and checklists. Knowledge about the framework and platform was implicit Testing the absolute minimum with manual, ad-hoc smoke, regression, and scenario tests A STORY THE OUTCOME
- 15. There always be more ideas than there is time and money Use of immature technologies with unknown limitations Lack of skills to make the right decisions Poorly managed change in quality goals from quick-and-dirty to portable and competitive Communication issues - too much pressure to deliver, too little understanding and trust REFLECTION WHAT WENT WRONG?
- 16. Analysis of 200+ companies suggest that my story is very common among new companies Unwanted technical debt is introduced by smart people in difficult circumstances Testing is the least fun activity in software engineering just after maintaining documentation Larger teams need more coordination Scaling up team and product exposes the technical debt REFLECTION WHAT HAPPENS IN OTHER START-UPS?
- 17. On a team level • Architecture, quality goals • Technology decisions • Quality assurance practices On an individual level • Skills, experience • Attitude COUNTERMEASURES TO UNWANTED TECHNICAL DEBT
- 18. Architecture • Monolithic vs modular application • Architecture should mimic your organizational structure COUNTERMEASURES TO UNWANTED TECHNICAL DEBT ON A TEAM LEVEL
- 19. Manage the shift in quality goals COUNTERMEASURES TO UNWANTED TECHNICAL DEBT ON A TEAM LEVEL time
- 20. Technology decisions: • JAVA vs PHP • Ad hoc in-house framework vs a well known framework • Just released, hyped libraries/tools/frameworks? COUNTERMEASURES TO UNWANTED TECHNICAL DEBT ON A TEAM LEVEL
- 21. Quality assurance practices: • Automated metrics to identify code smells • Linters • Code reviews • Pair-programming • Collective code ownership • Shared understanding what are good and bad practices • Refactoring COUNTERMEASURES TO UNWANTED TECHNICAL DEBT ON A TEAM LEVEL
- 22. • Educate yourself • Read good code, write good code • Contribute to an open-source project • Have a mentor • Mind the Dunning-Kruger effect COUNTERMEASURES TO UNWANTED TECHNICAL DEBT ON AN INDIVIDUAL LEVEL “If you are incompetent, you can’t know you are incompetent… The skills you need to produce a right answer are exactly the skills you need to recognize what the right answer is.” - David Dunning
- 23. COUNTERMEASURES TO UNWANTED TECHNICAL DEBT ON AN INDIVIDUAL LEVEL
- 24. COUNTERMEASURES TO UNWANTED TECHNICAL DEBT ON AN INDIVIDUAL LEVEL
- 25. Three things you remember from my presentation? DISCUSSION
- 26. Three things you remember from my presentation? One thing that you really liked? One thing where you disagree? One thing that you don’t understood completely? DISCUSSION
Editor's Notes
- To maintain the balance there must be a close cooperation between artists and engineers
- To maintain the balance there must be a close cooperation between artists and engineers
- To maintain the balance there must be a close cooperation between artists and engineers Technical debt is discrepancies from good engineering practices now that will cause extra work later
- To maintain the balance there must be a close cooperation between artists and engineers Technical debt is discrepancies from good engineering practices now that will cause extra work later
- To maintain the balance there must be a close cooperation between artists and engineers Technical debt is discrepancies from good engineering practices now that will cause extra work later
- To maintain the balance there must be a close cooperation between artists and engineers Technical debt is discrepancies from good engineering practices now that will cause extra work later
- To maintain the balance there must be a close cooperation between artists and engineers Technical debt is discrepancies from good engineering practices now that will cause extra work later
- To maintain the balance there must be a close cooperation between artists and engineers Technical debt is discrepancies from good engineering practices now that will cause extra work later
- To maintain the balance there must be a close cooperation between artists and engineers Technical debt is discrepancies from good engineering practices now that will cause extra work later
- To maintain the balance there must be a close cooperation between artists and engineers Technical debt is discrepancies from good engineering practices now that will cause extra work later
- To maintain the balance there must be a close cooperation between artists and engineers Technical debt is discrepancies from good engineering practices now that will cause extra work later
- If you notice, I did not mention if games were good or bad, whether the customers liked them or not.. Whether the company had a meaningful business model.. Yet we spent hours arguing about game designs and other nitty-gritty details. We never got to the point where this is relevant.. Mostly due to bad decisions and technical debt! 1. The ideas are exclusively about customer value, visible features. However these features need Internal support in architecture. Sadly, as a developer you are paid for external features only. Internals is your business. 2. Bad decisions were made by good people Under pressure With incomplete information
- Many young companies never launch their product Many never get to the point where the features matter Many never get to the point where the business model matters Knowledge = domain, SE, marketing, sales + means of benefiting from group knowledge Have a nice narrative.. Talk about contributing factors to TD
- Modular – easier to split work, less dependencies. Easier to test. Easier to add/remove features Monolithic lump = grows too big too fast. Interdependencies makes changes difficult.
- Modular – easier to split work, less dependencies. Easier to test. Easier to add/remove features Monolithic lump = grows too big too fast. Interdependencies makes changes difficult.
- “If you are incompetent, you can’t know you are incompetent… The skills you need to produce a right answer are exactly the skills you need to recognize what the right answer is.” - David Dunning
- Things go as low as people are ready to tolerate Software engineering is a team activity and each person in the team is responsible for the end result.