0% found this document useful (0 votes)

78 views4 pages

SSW Rules For Developers

This document outlines rules for developers at SSW, including: 1. File management guidelines such as storing projects in standardized folders by type. 2. Backup procedures like keeping 4 numbered versions of applications on a weekly rolling basis. 3. Documentation standards like creating accessible product documentation for clients and internal products. 4. Enforcing continuous integration practices like pair programming, daily check-ins, and unit/integration testing. 5. Collective code ownership where all developers can work on any code and improve it. 6. Using a SharePoint image for testing SharePoint work.

Uploaded by

Active88

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

78 views4 pages

SSW Rules For Developers

Uploaded by

Active88

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 4

SSW Rules for Developers http://www.ssw.com.au/ssw/Standards/Rules/RulestoBetterDevelopers...

SSW Rules for Developers

Home > SSW Standards > SSW 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?

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:

1 of 4 8/12/2011 9:33 AM
SSW Rules for Developers http://www.ssw.com.au/ssw/Standards/Rules/RulestoBetterDevelopers...

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:
Prototype - E.g. http://www.ssw.com.au/projects/PA_FRDC/Prototype
Data Schema
Project Plan - E.g. http://www.ssw.com.au/projects/PA_FRDC/ProjectPlan.xls
Incident List - E.g. http://mail.ssw.com.au/public/SSWIncidentPRO/John Liu/SSW-SSW Pty Ltd-Adam
Cogan/SSW LookOut for Outlook
The Public link should be like http://www.ssw.com.au/projects/Public.aspx or http://www.ssw.com.au
/projects/External.aspx
For internal products:
Currently all documentation is done as HTML files on our website in the product directory, e.g.
http://www.ssw.com.au/ssw/teamcalendar/UserGuide.aspx

4. Do you do Continuous Integration when Developing and Testing? (aka Don't use TFS as a Network
Share)
Development is to be done in pairs. The process is:

Check out code What is Unit and Integration Testing?

Do the development (you write test code first) Erich Gamma and Kent Beck started a framework for
Run your tests - keep the errors to 0 - (unit testing) writing tests during your design phase. These are widely
accepted as very good programming practice (in fact,
Get Latest
some may consider it extreme).
Run your integration tests - keep the errors to 0 -
Some background for these people. Erich is a major
(checks the new build including setup.exe) (daily)
contributor of the book "Design Patterns" (must read!).
Check in code (aim for twice a day, lunch and prior to Kent is the author of "Smalltalk Best Practices" .
going home) These are some of the very smart people who pulled
together years of experience and patterns that can be
Add version numbers to your application. If the code is
used in the design and development of goods software.
reviewed by a manager it must be commented that it has
been reviewed. Every application should have a version Their work is JUnit on http://sourceforge.net/Projects
table. For every change a new version number with /junit/ but that is a framework for Java.
comments should be added into the version table. A .NET implementation has been ported, and is at
Modules/Classes should have enough comments to explain http://sourceforge.net/Projects/nunit/ .
the logic for a second developer to understand. After

2 of 4 8/12/2011 9:33 AM
SSW Rules for Developers http://www.ssw.com.au/ssw/Standards/Rules/RulestoBetterDevelopers...

commenting put your initials, this way other developers

know who made the changes.
There is a very good article you should read
The project manager should check it before you release http://junit.sourceforge.net/doc/testinfected
the first few versions to the client, he should finds things /testing.htm
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

3 of 4 8/12/2011 9:33 AM
SSW Rules for Developers http://www.ssw.com.au/ssw/Standards/Rules/RulestoBetterDevelopers...

Benefit from our knowledge and experience!

SSW is the industry leader in Custom Software Development, Software Auditing & Developer Training.
Call us on +61 2 9953 3000 or email us for a free consultation

What does it cost? I’m not in Australia. Can you still help?

4 of 4 8/12/2011 9:33 AM