Posts Tagged ‘agile’

Do or do not


Assertion is a valuable tool that many languages provide, but recently I have come to think it is used too much and in the wrong places.  I put forward the idea that asserts should not be found anywhere in the main body of your code.  Permanently burying asserts deep inside your code could end up causing more problems than they seek to solve.  Asserts embedded in methods  are useful while debugging, but should rarely be committed to source control.

I extend this thought to other defensive practices like checking for nulls indiscriminately – even where there never should be one.   Sanitization of external data is prudent and necessary, but once things are safely inside your own codebase you have control of the expected range of values and should be able to trust that.

What an assert does

An assert stops execution and flashes up a message when a condition fails.  If there is a debugger attached then if it can it will direct the programmer to the source where the assert fired.  Great for the programmer trying to track something down, rubbish for someone else who has to skip the message (perhaps many times) to do what they are trying to do.

Asserts disrupting workflow for other programmers and disciplines have been mitigated in a few ways.  The following are some more common methods:

  • Builds with asserts turned off
  • Asserts with a concept of levels or categories that can be toggled
  • Assert instance toggle – it will appear once but as well as skip there’s an option to ignore

Crying wolf

Asserts that continually fire create too much noise; unless the game completely falls over then people start to not take any of them seriously.  Just like compiler warnings there is a point where many eyes just glaze over the number and a number above zero becomes an excepted part of life… perhaps even becoming a joke.

Do or do not, there is no try

Yoda: 'Do, or do not!  There is no try'.

Asserts show a lack of confidence of an operation being successful – so much so that a human being should be warned.  It is a developer communicating with themselves and others that at some point something is in a state so dire that normal execution must be interrupted so someone can take a look.  I do not believe having that kind of warning permanently buried and hidden is healthy.  It is preferable to either formally test and handle the situation if it really is expected, or get to the real root of the problem and prevent that invalid state from ever occurring.

Sanitize the data once properly rather than repeatedly sanitizing the same data in the same way throughout the program just in case.  Every time a conditional statement is encountered there is a computational cost associated with that.  A code block could have its own setup and destruction costs – perhaps more so if exception handling is being used.  This may seem like premature optimization but clear concise code is easier to digest for man, compiler and machine.  After all the best kind of processing is the processing you can eliminate – look to improve your algorithm.

Asserts in the middle of a method after a long conditional block could indicate that the method could be broken in to smaller more focused testable methods.  If possible architect so that a method will always succeed in some measure to allow callers to expect the same predictable outcome.  If a function should always return a populated something, use a default something rather than null.   For example use a valid bright pink texture for missing data and log the error rather than just returning null and forcing everything from that point on to check for nulls.

Silent but deadly

A badly written assert may cause a side effect as part of testing the condition perhaps without the programmer even realizing it.  When an assert like that is disabled it causes different behavior between types of builds.

Worse is when an assert expects to be heeded in the same way as exception.  Ignored or absent through compilation options, execution blunders on and states become corrupted, going on to cause unpredictable problems later.  Perhaps that problem will even mask itself as an issue with a completely unrelated system.   In the worst case corrupt data could be persisted, ruining a saved game.

Asserts encourage a codebase that constantly tries to correct itself rather than addressing the real problem.  Methods no longer trust each other to fulfill their remit.  Expectations of callers change from “I should only give it foo” to “I can give it foo, bar or nothing at all”.  Those expectations can virally spread throughout the codebase causing more methods to second-guess each other and bloat.

The truth is out there

Earlier I stated that asserts in the main body of code shows a lack of confidence and are used to try to mitigate bad states.  Used in the context of test functions they serve to communicate an expectation of success.  The tests can be run independent of running the game or application itself and provided with sample of runtime data to consume.  Instead of the same assertions being made in multiple places against the same method scattered across the codebase, an expectation for a specific scenario can be stated exactly once.

Asserted expectations can be gathered in a test suite to form a living document in code that provides examples of use that are easily found.  Compile time can be quicker for coders because tests can be separated out in to different projects – run only during the testing phase of a change and on the build machine.


Asserts in the main body of your code clutter the logic and could be expressed more concisely elsewhere.  Programming too defensively could blur the responsibility of what is being written.  Do not always code “just in case” otherwise callers will start to rely on the defensive parts.  Either set the expectation of a method to always sanitize (and perhaps hint at that extra processing in the name) or fail as gracefully and quickly as possible.  Methods have to be able to trust each other.  Many applications and games are closed systems that have predictable points of failure, only the input from the boundaries should be considered for sanitization.  Failed asserts should be a point of immediate failure – though I would argue there are better ways of indicating failure.

Asserts are very useful for debugging, but be wary of the costs of permanently committing them to the main body of your source code.  Logging error messages and substituting inert values can be far less obtrusive then relying on asserts breaking execution and popping up message boxes.  It is outrageous for a tool that is supposed to run unattended to stop everything waiting for input, just fail and exit.

Asserts do belong in source control when used to formally test methods and when they clearly express specifications.  This kind of living documentation created by asserts is a form of cover fire.  If you cannot separate asserts in to formal test methods to create clear behavior specifications, try and gather them together close to where the bad state will first occur.  Group them close as possible to where an errant call could first appear on the stack, rather than scattering the expectations around deep in the code.  Let the developer see everything that is expected at a glance.  Asserts should help avoid detective work after all!

There are many advantages to taking asserts scattered through your code and creating test suites from them – see my previous article Cover Fire for Coders.

Further Reading

Some other related #AltDevBlogADay articles about debugging and asserts you might be interested in:

Some books you might be interested in:

McConnel, Steve (2004).  Code Complete – 2nd Edition.  Microsoft Press.  ISBN: 0-7356-1967-0 UK Amazon FlagUSA Amazon FlagCA Amazon FlagDE Amazon FlagFR Amazon Flag

Chapter 8 covers the split between debugging tools and effectively handling failure in production code.  It supports quite some things that I advocate in this article in a much more detailed discussion.  One of my favorite quotes from the chapter: “Sometimes the best defence is a good offense.  Fail hard during development so that you can fail softer during production”.

Keith, Clinton (2010).  Agile Game Development With Scrum.  Addison Wesley.  ISBN-13: 978-0-321-61852-8 UK Amazon FlagUSA Amazon FlagCA Amazon FlagDE Amazon FlagFR Amazon Flag

This book covers how spending time eliminating technical debt can help create a more predictable schedule and end up with a more focused, polished game.

[Paul Evans is a central technology programmer at Lionhead Studios.  He has worked on the Fable II, Fable III and other unreleased titles.  You can find him on Linkedin, see other things he has written on his personal blog, and follow him on twitter.  Everything in this article is Paul’s opinion alone and does not necessarily reflect his employers views. Copyright ©2011, Paul Evans.]

(Originally posted for #AltDevBlogADay)

Industry featured my blog!


Many thanks to Ryan at for recording one of my articles.  It is very flattering to have been approached and amazing to be able to download a podcast with my own words read back to me on the subject of Agile Vocabulary.  Perhaps I should read aloud new articles to myself to make sure they are friendly to that format!

I have another article in draft that I started on the Bank Holiday Monday and will try and finish that over the weekend.  If anyone has a subject they might want me to try and cover suggest it and if I can I will over the next few weeks.

Agile Development – RPS Estimation



Previous article:

This estimation technique based on a simple game of rock, paper, scissors (RPS) is something we have already experimented with to estimate story points for a task.  A story point is a measure of complexity and size of a task (see Agile – Vocabulary), though could be used to estimated time too.

Rock Paper Scissor Estimation… For the win?

Planning Poker

First of all planning poker seems to be way more documented than rock paper scissors estimation, and there are tons of resources about it already on the web.  If planning poker is not familiar to you I would definitely recommend reading up a little about it.  Feel free to also comment if you have come across another discussion on rock paper scissors used in this way for estimation.

In planning poker each player involved in estimation is given cards with a Fibonacci number on representing how many story points a task is worth.  Sometimes decks use a base 2 binary numeral system – something probably more familiar to many software developers.  These are played face down, and on reveal the highest and lowest guessers talk about their estimation with the other players.  Play continues until the values converge.  The strength of rock paper scissors is no props are necessary!


The rock paper scissors method has roots in the Delphi and Wideband Delphi methods of estimation – but less formal.


Make sure the people you are playing with have the same idea about what a unit story point is.  It is best if it is a completed simple task you are all familiar with, otherwise you have to start with an agreed duration of time on a task (e.g. half a day).

Nominate one person to marshal the session.  This might be the scrum master (if you are practicing scrum) but the role should switch between team mates.  Rotating the role allows members of the team to grow in confidence talking with their co-workers, encourages joint ownership of the estimation process and it helps the team to jell.

A list of tasks should be given to the marshal to familiarise him or herself with.  The marshal then arranges the meeting.


Personally I prefer play with the binary numeral system because it is really easy to remember.  You may prefer the Fibonacci numbers which is fine.  Adjust the scale for larger problems or use both hands. Large amounts of story points indicates that the task estimated should be broken down in to more manageable chunks.

  • 0 Fingers:
  • DSC_0264  - 0 fingers Less than 1 story point
  • 1 Finger:
  • DSC_0259 - 1 finger 1 story point
  • 2 Fingers:
  • DSC_0260 - 2 fingers 2 story points
  • 3 Fingers:
  • DSC_0261  - 3 fingers 4 story points
  • 4 Fingers:
  • DSC_0262  - 4 fingers 8 story points
  • 5 Fingers:
  • DSC_0263  - 5 fingers 12 story points
  1. The marshal introduces a task to the group.  Brief further definition of task might be necessary but the marshal should not allow too much detail to be discussed at this point.  It may sway initial estimates, especially if the perceived senior authority on the subject starts talking about complexity and size too deeply.
  2. Marshal counts to three.  At the count of three everyone presents their hands at the same time to the rest of the group.
  3. The person with the largest estimate explains to the group what made them guess the highest.  This helps to draw out unknown facets of the task.
  4. The person with the lowest estimate explains to the group what made them guess the lowest.  This helps to draw out false assumptions, or perhaps something helpful that could simplify working out the task.
  5. Marshal calls for another round of estimations (back to step 2).  Process repeats until the estimates converge.  Estimates should converge, once they do return to step 1 and repeat for each task.

Scale of tasks can be an issue with this form of estimation using the binary numeral system “is Task X really twice as hard as Task Y?”.  Greater scale accuracy can be achieved by using different combinations of fingers.  If using the binary method that could be holding up different combinations of fingers (thumb and index finger could mean “3” for example).  That has it’s own problems because some combinations of fingers are actually pretty hard to carry off for people with less flexible hands.

The strength of this method is that it does not necessarily even need a formal meeting or marshal.  A group of a few people can easily estimate using this method in a corridor, at a desk, etc.


Agile Development – Vocabulary



This is the start of a series of articles about agile development.  The motivation behind writing these articles is to expand my knowledge of the topic by explaining how I currently understand it.  I imagine feedback from readers about their own experiences and understanding of the topics discussed could help my own comprehension of the material.

This entry focuses on some basic vocabulary used in the project management side of agile practices.   The vocabulary presented here concentrates on requirement gathering, describing deliverables and estimation and will be used in later articles in this series.

My Experiences

The game team I am currently on use scrum (though purists would called it “scrum but”) which is common methodology adopted for managing time on an agile project.  I have myself used “agile” style development practices like unit testing and continuous integration (using NUnit, Cruise Control .Net and Trac) in my past life outside of the games industry.  I have made sure to make time to read about these agile practices for years.

Most of the week beginning 8th of February 2009 I took part in a lab called Agile Development in C# and I had a glimpse of techniques used in teams around the mother-ship.  Spending the week building a project, managing the backlog and taking turns at being the scrum master and team lead was a very educational experience.  “Living it” with guidance in this way was like a crucible of learning (there was an element of competition too).  It was very rewarding yet quite draining!

My current lead developer attended the same course – thus I am more confident about “buy-in” of some agile practices at that level because of the extra common ground that brought me.  I have already had the opportunity to apply some development techniques discussed in that course to the main code base I work with day to day.

Vocabulary: User Stories

User stories are requirements written from the perspective of the customer.  A collection of user stories make up the “product backlog” and can be prioritised by how important they are to the user.  This allows the developer to concentrate on things that would be immediately useful to the customer for when a vertical slice of the product is delivered at the end of the “sprint”.

A user story is an expression of what they want and why, rather than any technical detail of the how.

A good example might be: “I would like my lawn to be short so it is pleasant to lay back and read in the garden.”

A poor example might be: “Mow lawn to 2 cm using a rotary petrol mower.”

The user stories concentrate on requirement gathering and intent.  These stories help communicate how the development team understand the requirements.  They also allow quick feedback from the user on any good or bad assumptions made.

Vocabulary: Story Points

Story points were introduced as a way of quantifying an estimate of a user story.  Where as estimates are usually expected as a duration, story points are based on an estimation of size and complexity.

For example a gardener might want to estimate the size of the lawn, see how overgrown it is and how much edge work would be necessary to keep it neat before attempting to estimate a time.  Depending on weather conditions on the day, it may even take slightly longer on some days than others.

The customer expects a regular fee and period of time spent in the garden rather than taking in to account difficulties from one week to the next.  One week the garden may not have grown very much and the whole thing will be quicker to complete.  Perhaps the gardener might take the time to make nice little extra touches to the garden to add value that easier week where there is ample time left over.

So a story point is not directly translatable to time because of the various unknowns.  The number of story points against something keeps track of how much effort will be required – something with more story points is harder to complete.

Vocabulary: Tasks

Tasks are derived from breaking a user story down in to small chunks of functionality.  These tasks are estimated in hours (or story points).  The estimated time remaining is updated daily during the scrum.

A task is only counted as “done” when it is verified.  A consistent measurement of “done” is important so it can be signed off for the sprint.  Quality gates can be used to measure if something is actually complete.  This could include passing tests and automated code quality tools.

Once all the tasks for a user story have been completed, functionally tested and verified, then it can be taken from the product backlog.

For example tasks for large garden could be (in the form of Task (verify) – duration):

  • Mow lawn (lawn appears visibly shorter.  Regular straight lines can be seen in the grass) – 2 hours
  • Tidy garden and rake lawn (no debris can be seen on the lawn or path, grass cuttings bagged and loaded) – 1 hour

Vocabulary: The Daily Scrum

The Daily Scrum is often a short morning stand-up meeting only including people doing the work itself.  The scrum master role can be taken up by any member of the team.  The scrum master asks the questions:

  1. What did you do?
  2. What will you do today?
  3. What is blocking you?

The estimates are updated on the current tasks, and the scrum master goes about trying to unblock the team where they are blocked.  Blockages could be something technical, through to waiting on another team to complete a task.

Continuing the gardening example – if the gardeners have noticed the lawn mower blades have become blunt and causing the team to slow down, it would be up to the scrum master to communicate with the tools team and ask them to sharpen the lawn mower blades.

Vocabulary: Sprints

A selection of user stories are chosen for the sprint.  Stories can be added or dropped from a sprint, but the deadline for a deliverable does not change.  If the deliverable, demonstrable version of the software is created ahead of time and the team feels confident they can take another story from the backlog and if it’s too big, break it down where possible.

The idea of a sprint is to always have something to show for the work everyone has done at a regular interval, to allow the users to feed back.  At the point a sprint begins, the requirements of the stories they are working on are locked.  A sprint can be completely aborted, or a story dropped… but the requirements of an existing story should not change.  The motivation is that the team are not aiming for a moving target and can concentrate on getting the unit of work done.

Ideally each sprint delivers a vertical slice to show progress.  For the running gardening example I have been using – this might be completing the more simple front garden entirely to prove the gardeners have understood the requirements sufficiently to maintain the garden to the customer expectations.  It also gives the customer an opportunity to feedback or change their mind “actually, I want my lawn to have circles rather than lines”.

Vocabulary Cheat Sheet

Daily Scrum Short stand-up meeting.  What did you do?  What will do today?  What is blocking you?
Product backlog Prioritised list of user stories.
Quality gate Checklist of things to verify work against before it is counted as completed.
Scrum master Leads daily scrum.  Tracks work completed and remaining, and organises removal of things blocking the team.  Ideally a role rotated between members of the team.
Sprint A period of time where user stories are chosen to work on.  External influences are not allowed to change the requirements of the stories being worked on.  Sprints are a fixed length, but stories can be postponed or additional ones taken from the backlog.
Story points Unit of estimation measuring complexity.
Task A user story can be broken down in to one or more tasks.  Tasks are estimated daily in hours (or story points) remaining by the developer working on them.
User stories User requirements expressed in sentences from the customer perspective.
Vertical slice Showing off a feature in an application that works from start to finish but may be limited in scope.  For example a rope bridge crossing a chasm is immediately useful and allows people to cross.  Having that in place can help to build a better bridge later.


Some of my references are company confidential and cannot be shared here – the web is full of useful information though.  The sites below are useful launch pads to further reading.

EDIT: Thought of a few more references:

Please comment any useful links you have stashed away 🙂

Book review: Practices of an Agile Developer


A couple of weeks ago I was in Southampton and the Borders there was having a sale on all computer books… so I picked up “Practices of an Agile Developer” by Venkat Subramaniam and Andy Hunt.  Before I discuss the book I am going to go in to a little background.

One of my annual commitments I made back in October 2008 for 2009 was to learn about Agile practices… partially motivated by already being enrolled in a course that I’m taking next week.  I have been interested in these practices for quite some time though so this book is not my first exposure to agile thinking.  Before I left Ds Ltd for Lionhead Studios just over two years ago I had already co-authored an internal standards and practices document that encouraged various agile practices.

During university and the first year as a full time developer I was way more interested in learning some C++ tricks and a then newfangled language called C# that the management were for whatever reason excited about ;).  It is very easy as a developer to neglect the soft skills when there are cool new programming things to learn.

At university we were taught things like the Waterfall model, PRINCE and ISO 9000 accreditation – and whereas these things are important they do create a lot of paperwork.  ISO 9000 for example can fantastically document a horrific failure.  Things like “requests for change” that had to be signed off by more than one person are there to chain a customer to their original requirements.  GANNT charts created by MS Project used to make pretty diagrams that end up being a work of fiction because of unexpected bumps along the way.  It felt like setting up ways to assign blame for what goes wrong rather than concentrating on working together for a solution.  You get requirements, develop the software for a while, then hand it back.  It was contract negotiation over customer collaboration. Knowledge of these management principles is important so that you can make informed choices and discussions later on – but you will find every company has their own twist on the above anyway (the twist at university was everything was so literal and to the letter).

Other soft skills taught at university like uml, data flow diagramming, crc cards, database modelling are immediately useful in the real word for a graduate developer.  Sometimes these things are taught in a way that divorces them from the code too much; design everything first, code everything using the design later. This again isn’t the best way in practice (though probably a good way to create an assignment marking scheme).  While it is important to design up front, going in to too much depth lends itself to over-engineering. For example, classes created where properties would do, usage of patterns adding needless complexity to a solution, another layer of abstraction to solve a problem, “is-a” being taken too literally when applied to inheritance in class designs, etc.

So what better way to stop yourself wasting time and creating software that doesn’t please your users (or even get finished) than to read about other people’s experience first and not make the same mistakes?

“Practices of an Agile Developer” is a decent book that is all about how to be a positive influence on those around you no matter the position you hold.  It holds extra value for managers, producers and those that are in a position to lead from the top of course – but there are many things you can do on a personal level suggested in the book.  Committing to some of the things it suggests has the potential to make you more effective, and perhaps your work day more pleasant.

The book itself is quite short, but that is reflected in the price and concise style.  A chapter concentrates on a specific area of agility skills that is broken in to sections describing individual techniques.  Each technique is documented with a clear structure – identify a good and bad practice (represented by an angel and devil next to a box-out), then a personal experience from the authors and to finish off clear bulleted list of things to do.  The solutions at the end are particularly interesting in that they are always clear that taking the suggested practice too far can often be as harmful as not doing it at all.  Each technique also has “what it feels like” heading which describes the agility pay off when it has been applied in a balanced way.

The authors balanced, non-fanatical standpoint is much easier to digest than other books I have come across.  Ruby is mentioned a few times in a very rosy light, but considering the authors have close ties to the language you can let that pass.  The book does often refer to other books in the pragmatic programmers series which almost seems like advertising – though by not repeating other books it does mean the book keeps a tight communication and personal practice focus.

The first book in the pragmatic programmer series I brought was “Ship it!: A Practical Guide to Successful Software Projects” back in 2005 – which concentrates more on the practical detail of setting up a good production environment and development pipeline than team and customer relationships.  It is another insightful book full of practical examples of how to get things done – I have not read it front-to-back for a while but I may review it in the future.

“Practices of an Agile Developer” is a pragmatic look at practices that have been proven to work in the field.  It is a management book written for developers by developers.  Primarily I would recommend the book to students that aren’t quite getting the connection between modelling, code, and time management.  As for anyone else a bit more experienced  it is a good introduction to agile practices that isn’t terribly preachy – and does not smell of Power Point.


“Practices of an Agile Developer”

by Venkat Subramaniam and Andy Hunt

Buy from

Buy from

“Ship it!: A Practical Guide to Successful Software Projects”

by Jared Richardson and William Gwaltney

Buy from Buy from


P.S. Anyone have any requests for a subject you would like me to write about?  Anything sensible that doesn’t break my NDA will be considered 🙂

%d bloggers like this: