Skip Navigation LinksHome > SSW Standards > Rules > SSW Rules for Developers

Before you start development work
  1. Do you know how to manage your files?
  2. Do you keep Backup Versions?
  3. Do you create product documentation and make it easily accessible?
  4. Do you do Continuous Integration when Developing and Testing?
  5. Do you enforce Collective Ownership of code by all developers?
  6. Do you use the SharePoint image as a test environment when you work on sharepoint?

    7. Doing the development work
  7. Do you make sure you have a Release plan for any project longer than 3 days?
  8. Do you give customers a daily update?

Do you agree with them all? Are we missing some? Let us know what you think.

  1. Do you know how to manage your files?

    We need to differentiate between web projects and Windows projects. But we want the two different types of projects to exist in basically the same location. So we use the following method.

    Create a folder on your working drive (usually C: drive) called 

    Data<firstname><lastname>
    using your first name and last name.

    e.g. 

    C:\DataAdamCogan

    Then create the following folders underneath that folder

    • ProjectsWinTFS - To store Windows Project / TFS e.g. 
      C:\DataJohnPrince\ProjectsWinVss
    • ProjectsWin - To store Windows Project / Non-TFS e.g. 
      C:\DataJohnPrince\ProjectsWin
    • ProjectsWinTemp - To store Windows Project / Demo/Temporary e.g. 
      C:\DataJohnPrince\ProjectsWinTemp
    • ProjectsWebTFS - To store Web Project / TFS e.g. 
      C:\DataJohnPrince\ProjectsWebVss
    • ProjectsWeb - To store Web Project / Non-TFS e.g. 
      C:\DataJohnPrince\ProjectsWeb
    • ProjectsWebTemp - To store Web Project / Demo/Temporary e.g. 
      C:\DataJohnPrince\ProjectsWebTemp

    What projects do we use Team Foundation Server with:

    • Yes - .NET. The master version for VB6 and .NET projects should be kept in TFS.
      If the settings are in Access then the .mdb is in TFS
    • No - Access Frontends. As it corrupts the .MDB with all the forms in it
      The .MDB and associated files should be stored on a network share
    • No - Web Site. Stops you from using front page
    • For further information see Do you know how to use source control properly?

  2. Do you keep Backup Versions?

    Often we will be asked to "fix up" existing Web or Windows applications. We should always keep a copy of the original version so we can compare the latest version with the original. We also keep a rolling 4 versions of the application saved on a weekly basis. The versions should be saved as following:

    • ApplicationName - Current version
    • ApplicationName_v001 - Original version - This is NEVER deleted
    • ApplicationName_v008 - Oldest version apart from the original
    • ApplicationName_v009 - Second oldest version apart from the original
    • ApplicationName_v010 - Second youngest version apart from the current version
    • ApplicationName_v011 - Youngest version apart from the current version

    At the end of the forth week the oldest version is deleted (in the above example _v008) and the youngest version saved (_v012).

  3. Do you create product documentation and make it easily accessible?

    • For client projects:
      • Make a HTML file for the Client to read. E.g. http://www.ssw.com.au/projects/PA_FRDC
      • On that page refer to the:
    • For internal products:

  4. Do you do Continuous Integration when Developing and Testing? (aka Don't use TFS as a Network Share)

    What is Unit and Integration Testing?

    Erich Gamma and Kent Beck started a framework for writing tests during your design phase. These are widely accepted as very good programming practice (in fact, some may consider it extreme).

    Some background for these people. Erich is a major contributor of the book "Design Patterns" (must read!). Kent is the author of "Smalltalk Best Practices" You are about to leave the SSW site. These are some of the very smart people who pulled together years of experience and patterns that can be used in the design and development of goods software.

    Their work is JUnit on http://sourceforge.net/Projects/junit/ You are about to leave the SSW site but that is a framework for Java.

    A .NET implementation has been ported, and is at http://sourceforge.net/Projects/nunit/ You are about to leave the SSW site.

    There is a very good article you should read http://junit.sourceforge.net/doc/testinfected/testing.htm You are about to leave the SSW site

    Development is to be done in pairs. The process is:

    • Check out code
    • Do the development (you write test code first)
    • Run your tests - keep the errors to 0 - (unit testing)
    • Get Latest
    • Run your integration tests - keep the errors to 0 - (checks the new build including setup.exe) (daily)
    • Check in code (aim for twice a day, lunch and prior to going home)

    Add version numbers to your application. If the code is reviewed by a manager it must be commented that it has been reviewed. Every application should have a version table. For every change a new version number with comments should be added into the version table.

    Modules/Classes should have enough comments to explain the logic for a second developer to understand. After commenting put your initials, this way other developers know who made the changes.

    The project manager should check it before you release the first few versions to the client, he should finds things like tab order etc...

  5. Do you enforce Collective Ownership of code by all developers?

    • Developers should not have ownership of code - if you see something wrong fix it and them email the original developer the fix you made (with the aim he/she learns).
    • Pair Programming - two people together write production code
    • People move around e.g. Work on other people's code, that way they see all the code and they work with all the developers
    • Developers must write readable code

  6. Do you use the SharePoint image as a test environment when you work on sharepoint?

    Once you work on sharepoint,you will ask the sharepoint manager for the SharePoint image(about 14GB) to quickly setup a SharePoint test environment.

    Please see Product Managers page to find out who is the sharepoint Manager.

  7. Do you make sure you have a Release plan for any project longer than 3 days?

    Get an OK on a "Test Please" email

    Release with a "New Release and Debrief" email generated by Incident PRO (prefered) or Time PRO! Smart Tags.

    So, this is the basic release pattern:

    Send Pre-Release Summary for Release 1 to Primary Contact
    Complete Release 1
    Send "Quick Test Email" to one Tester/Customer - wait for "OK"
    Send "New Release and Debrief" to SSWAll/Customer


    Send Pre-Release Summary for Release 2 to Primary Contact
    Complete Release 2
    Send "Quick Test Email" to one Tester/Customer - wait for "OK"
    Send "New Release and Debrief" to SSWAll/Customer

    And so on.... for the other releases

  8. Do you give customers a daily update (aka Reply "Done" to your emails every day)?

    Keep the customer informed. Every time a feature is complete (1 to 3 days) then let the customer know. You don't have to do this but keeps the customer confidence. As per above there are a minimum of 3 mini releases (see the breaks in the bullet list).

    See Rules to Successful Projects regarding project plans and deadlines.

Acknowledgements

Adam Cogan
Cameron Shaw
Tim Fletcher
Edward Forgacs