Rule of engagement on software product (system) development

• Mission: Our mission is to establish processes, employ technologies to design and develop a high quality software product in the most effective / efficiency way possible.
• Productivity improvement: Any existing process, any employed technology, if they are seen to be counter-productive, is subject to be reviewed and potentially to be modified or replaced. Any suggestion could potentially improve productivity of the team or improve quality of the product are welcomed and entertained.
• Time is of the essence: Decisions are to be made based on the availability of the solutions at time of decision making. If availability is still an issue after projected schedule time, alternative would be sought. 
• Simplicity is the ultimate sophistication: By default, make the solution simplest possible. All architectural design decisions which make the system more Complicated must be driven by requirements (functional and non-functional). 
• Preserve Investment and protect time line: Whenever a technical decision is made on the employment of certain technology or certain design, it is our goal to preserve existing investment as long as it works. Conversion for the sake of conversion or consistency is not to be viewed as necessity. Effort should be made to ensure co-existence and smooth migration process in a period of long time to ensure there is no or minimum negative schedule impact. When a feature is completed, do not go back to do the “rework” for sake of standardization or consistency. As long as it works, we will try our best to preserve it.  However, “Refactoring” is an ongoing activity whenever we put new feature into the code base. This is especially true when we are doing feature based development.
• Empowerment: All team members should be given sufficient permissions to carry out what they are assigned to do, and anybody is countable for what he or she did.
• Trust and Verify: establish 100% designs / code review process. All artifacts, code or otherwise, are subject to be reviewed and will be reviewed. (if the project are using Visual Studio and TFS, For efficacy purpose, conduct code review in Visual Studio in conjunction of work item tracking)
• Tackle the problems instead of working around them: Anybody should be allowed to file issues beyond his or her control identified during his or her work that affect his or her work, and the team as a whole should address these issues.
• Team work: Collectively we own the product. If a member needs help, we are all in the position to help; all in the position to offer solutions. development team, architect team, database team, infrastructural team and configuration team are all part of the project team and all are committed to work together to achieve common project goal.
• Human nature: All processes, employments of technologies must consider human nature and business nature. We have to accept the fact that people make mistakes from time to time; Changes in requirement always happen. We need to adjust ourselves to these natures.
•  Documentation: documentation for operation instead of delivery. (Coding standard, programming guide, development PC installation procedure, system build and deployment procedure, system configuration, Key Architectural Decisions... etc.)
• Common sense rules: Let’s use our common sense and good faith when deal with project issues.