Software Development

Practices Presented by Marcin Chady

Background

• Large-scale software development & IT projects are plagued with high failure rates: – Over budget

– Late

– Product does not meet customer’s actual need

– Low quality

• Why? Lots of reasons have been proposed: – High degree of uncertainty (tech platform, requirements, process)

– All aspects of work are “intangible” – from problem specification, design, software solution, deployment

– Tendency to over-engineer / lose focus

– Integration problems – incompatible platforms, 3rd party etc.

• Improvements: – New practices

– New tools

Is Games Development Similar?

• Yes & no

• Similarities:

– It's software!

• The general phases of development are the same

• Most of the problems are the same

– Estimates are really just guesses

– Changing requirements

• Games tend to be like regular software projects on

steroids

– Very large code bases

– Large and varied problem domain

• Need many specialists

• There are more differences though …

Is Games Development Different?

• Fun is the primary goal but hard to pin down • Serendipitous outcome from collaboration between multiple groups

• Exploratory nature of the work

• Art & Design components of project

– Creative vision can be challenging to communicate & steer

– Have different requirements and scheduling needs

– Can be hard to tell if you’re on the right track until critical mass

• Content integration phase missing from other types of projects

• Games do not fit narrow classifications

– Part embedded system, part real-time multimedia, part simulation

• Hard deadlines:

– Street date is set

Code, Design and Art

• A game is really three projects running in parallel

– Cross dependencies can be large & constantly changing

– Work to minimize them

• Designers and artists shouldn't need code work to get new content into

game

• Coders don’t need final art to implement a feature

• Complex & shifting dependencies & bottlenecks

• Having solid design, before starting anything else is great

– Never happens in practice

• Having solid tech up front is even greater

– Studios working on sequels have solid technology before even

beginning content creation

– Purchase tech

Schools of Thought

• Control the uncertainty. – Heavy upfront design

– Sign offs

– Build to specification

– Structured customer involvement

• Embrace the uncertainty. – Iterative & adaptive processes

– People-oriented processes

– Frequent deployment & feedback

– Collaborative customer relations

• If you don't plan at all, you will be using “coral growth prototyping” as your primary software engineering technique

Waterfall Approach

• Often thought of as a strictly single-pass sequential

process:

– Requirements analysis

– Specification & tech design

– Sign-off

– Plan

– Implement the Plan

• Spend lots of time in upfront design

• Typically involves lots of formal documentation

• Emphasizes controls & sign-offs

Waterfall Approach: Pros & Cons

• Pros:

– Simple

– Big up-front design makes team look good (at least initially)

• Cons:

– Doesn’t work

– Large part of project risk is discovered late

– Rate of change invalidates initial design

– Doesn’t account for unknowns

– Need a working game sooner than the end of the project

• Publishers want milestones

• Gameplay must be tested

– Upper management likes a “well-defined” plan

• Not particularly well-suited for games

AGILE & ITERATIVE

APPROACHES

Agile Manifesto

Practical Applications

Agile Manifesto

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Agile Principles

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable

software.

2. Welcome changing requirements, even late in development. Agile processes harness change for

the customer's competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a

preference to the shorter timescale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they

need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a development

team is face-to-face conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users

should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity – the art of maximizing the amount of work not done – is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and

adjusts its behavior accordingly.

Lean Thinking

• Eliminate waste – E.g. features that aren’t high value

• Increase feedback

• Delay commitment – Develop a sense of when a decision is ready to be made or needs

to be made

– Wait for key developments to confirm or disprove

– Avoid committing to “speculative” features or unnecessary details upfront

• Deliver fast

• Build integrity in

• Empower the team

• See the whole

Agile Practices

• Iterative development – Short milestones

– Timebox feature exploration

– Define & deliver software features in working increments

• Feature oriented – Prioritized feature backlogs

– Features described from customer’s perspective

• Iterative planning – Scope & reprioritize at regular intervals

– Respect planning horizon (macro vs micro)

• Emphasize collaboration & communication • Frequent face to face touchbase

• Make project info public

• Frequent reviews, acknowledge successes

• Inspect & adapt

Scrum Practices

• Team meets daily – 15 mins, standing meetings called

scrums

• Team is typically multi-disciplinary

• Chickens don’t speak, Pigs do

• Sprints – 2 to 4 weeks long

• Everyone answers 3 questions:

1. What’s have you done since last meeting

2. What will you do between now and next meeting

3. What got in your way

• Not scrum, but better question for no.2 is:

– “When will you finish feature X”.

• Scrum master – responsible for removing impediments

Scrum Board

Burndown Charts

http://blog.brightgreenprojects.com/2009/07/07/what-is-a-burndown-chart/

Make Project Info Visible

• Information radiator

– One-to-many communication

– Project Info is placed on wall in the team space

– Big visible & simple

Extreme Programming (XP) Practices

• The whole team work together in a common project room

• Evolutionary deliveries – small & frequent releases

• Simple design – do the simplest thing that will work

• Test driven development – write unit tests before or concurrently with feature

• Pair programming – all production code is created by two programmers

• Frequent refactoring – refactoring is continual effort to simplify the code and the larger design

• Team code ownership – entire team is collectively responsible for all the code; peer reviews / code walkthroughs

• Continuous integration – build automation & testing

• Coding standards – establish and follow code conventions

• Sustainable pace

Other Iterative Approaches

• Spiral Model – Variant of waterfall method

– Requirements -> Risk assessment -> Prototype -> Evaluate -> Repeat

– External pressures often shorten/remove subsequent evaluation, requirements and risk assessment phases

– Not very appealing to management

• Prototyping – Throwaway

• Use the first prototype as a test bed for ideas. Once key ideas are proven, chuck it and start over with your new knowledge

• Need to be careful to try and solve real issues

• Need to be even more careful about really throwing it away

– Evolutionary

• Like throwaway, but you plan to keep the prototype (as opposed to accidentally keeping it)

• Need to refactor a lot

Hybrid Approach

• Carefully select a set of practices for your team:

– Based on principles

– Experience of team, values of team

– Needs of stakeholders

• Conflicting needs of stakeholders

– Publisher

– want design details upfront to make $$$ decisions, project sales,

organize marketing & sales

– want to influence product, suggest changes

– Management – wants predictability

– Team

• wants flexibility in schedule, deferring commitments

• wants to reduce rework

Suggestions for Your Project

• Iteration is key!

– Agile method, prototyping, whatever

– Testbed / sandbox environments

– Replicability

• Demo / journalling

• Source control

• Issue tracking

Maintaining code quality

• Code reviews

• Refactor judiciously

• Functional tests

• Make interfaces to systems as narrow as possible

• Reduce dependencies – Don't have pointers into other systems internal data

• Don't get too clever – Never rewrite COM when cut and paste will do

• Defensive programming (asserts) – Asserts are often better than robustness

– Too many asserts can slow down development if failure can in practice be recovered from

• Premature optimisation/pessimisation

Conclusion

• Keep in mind how games are different from standard

software

– Code, design and art distinction

• Pick and choose techniques from a variety of

methodologies

– Iteration is key!

– Early prototyping helps conquer the “it’s fun on paper” problem

– With your assignment schedule, an agile development process

would be very beneficial

• Read these three books:

– “The Mythical Man Month” – Frederick Brooks

– “Code Complete” and “Rapid Development” – Steve McConnell

The End