The Edge

Web application development insights written for our team, but open to the development community.

Dealing with Issues

Published on August 26, 2010

While we must strive always to create code that is free of bugs, with the custom software we create bugs are inevitable.  This should never lead to complacency – we should be diligent in both testing code and correcting bugs quickly.

Each member of our team is responsible for correcting bugs in any code that they have created.  This is important for our processes to work correctly, and it is also one of the factors that defines a contractor in Australian employment law.

As bugs are discovered, they will generally be added to an issues list, and then assigned to the responsible contractor as part of a Work Week (meaning they will also be assigned to you in Basecamp)

You will see them appear in your Work Week email, without a value assigned, like so;

image

Once they have been added to your Work Week, they are considered part of that Work Week and the Work Week will not be considered complete until the issue is corrected.

On some larger projects, issues will be assigned a priority which defines how quickly they need to be resolved.  This will effect which work week it is assigned to;

Level Description Resolution Time Work Week Assignment
Urgent Broken functionality affecting most users. ASAP (less than 24 hours). Will be added to the current work week if raised prior to 5pm Thursday, otherwise it will be manually assigned to you and then added to the following work week.
Priority Broken functionality affecting some users. Less than 48 hours. Will be added to the current work week if raised prior to 5pm Wednesday, otherwise it will be manually assigned to you and then added to the following work week.
Open New Issues, or Issues causing minor disruption. Within the work week it is added to. Will be added to the following work week, and assigned along with it.
Cosmetic Issues not affecting functionality Within the work week it is added to. Will be added to the following work week, and assigned along with it.

Note especially that urgent and priority issues are expected to be dealt with within the “Resolution Time” and not necessarily by the end of the Work Week.  Not having the issue corrected by the end of the Work Week will cause the work week to be considered incomplete, but if issues are not completed within the expected resolution time then they may be corrected on your behalf by another team member, and the cost of them doing this will be deducted from future payments to you.

The following points should also be considered regarding issue management;

  • Issues should be dealt with before new features.  If an issues arises, feature development should be put on hold to fix it.
  • If a project is live, then you must always develop new features in a feature branch of the source repository.  If there isn’t one, then ask the person managing your work work for it to be created.  i.e. You should never be working with the source “trunk” when that project is live.
  • Always correct issues against the code in the repository “trunk” and check them in as soon as possible. 
  • To aid in the above two points, you should always have ready a working copy of both the trunk and any feature branches you are currently working on.
  • Test, test, test!  You need not test the whole platform every time you make a change (UAT), but you are responsible to test the feature / issue that you are working on and any related code in a variety of scenarios to make sure that it actually works (Unit Testing).  Careless coding on the first run may result in less work being offered in the future.

Always remember: Code is Poetry

Filed under: Work Weeks, Workflow and Policy
Tags: ,

Leave a Reply