C++ Brown Bag Seminar
Contribution

21 February 1996
Brian Gary
Databases and Information Department

Many of the following apply to development projects in all languages, but seem to be more important in C++ projects.

1. Good standards will carry you through the crunch times

A. Define policies which encourage creativity but don't hamper development AND maintenance.

B. Define policies EVERYONE can live with.

2. Manage the project, not the technology

A. Language guru's don't necessarily make good Project Manager's (PM's).

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++.

3. Fill your toolbox with the right tools!

A. System construction should be your best friend, not your worst enemy.

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!

4. DOCUMENT, DOCUMENT, DOCUMENT!!!

A. Maintenance effort is inversely proportional to the amount of GOOD documentation.

B. Team member ramp-up time is inversely proportional to the amount of GOOD documentation.

C. Start from the beginning and utilize automated tools.

5. Abandon your hierarchy, abandon your design!

A. You designed your class hierarchy this way for a reason. If you documented it, you can defend it.

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!

6. Code for maintenance, not the "Programmer of the Year" award.

A. Just like going to the doctor, objects should be able to tell you where it hurts.

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!

7. Leave your pride at the door and get training!

A. FORTRAN != C++ != C != COBOL != etc....

B. Raises the lowest common denominator of project team knowledge

C. GASP! The team might actually learn something!


Legal Notices