B. Define policies EVERYONE can live with.
B. Good PM's don't always make good implementors.
C. Solution: System Architects.
D. Follow the proven rules:
- Define scope
- Allocate sufficient time to design. "On-the-fly" design will haunt your project until you re-architect!
- Implement your tool sets EARLY!!!
- Test, test, test
E. Don't forget scope control and expectation management. This becomes even more important if you are new to C++.
B. Source code management system.
C. Equip yourself with adequate debugging utilities.
D. Layered architecture's need test engines.
E. Automated testing tools go a long way!
B. Team member ramp-up time is inversely proportional to the amount of GOOD documentation.
C. Start from the beginning and utilize automated tools.
B. If you can defend it, you shouldn't compromise it without an architecture review.
C. Be prepared to make the tough decision of re-architecting, it WILL happen. Will you be prepared? Will your resume?
D. Keep it simple! 500 line methods should be questioned!
B. Just because you can, doesn't mean you should!
C. Conduct code reviews. "Can someone else maintain your creation?" will get answered real fast. Also good learning tool. Throw yourselves to the sharks once in a while; it won't hurt as much as you think.
D. Make smart language decisions
- If you choose C++, use C++.
- If you use C++, don't use all of C++
- C functions should be preceded by the comment "This is not an object method because..." If you can't document that question, you shouldn't be writing the function!
- Successfully cheating once makes cheating easier.
E. Chant the cohesion mantra daily. If you don't, this will kill reusability and leave you asking the question "Now, why did I use C++ to begin with?"
F. System Architects: Remain in your pulpits at all times!
B. Raises the lowest common denominator of project team knowledge
C. GASP! The team might actually learn something!