TCC software development guidelines |  |
TCC software development guidelines | |
Abstract
This document describes guidelines for developing software at the New Mexico Tech Computer Center (TCC).
This publication is available in Web form and also as a PDF document.
Please forward any comments to tcc-doc@nmt.edu.
Table of Contents
Why have guidelines for software development at the TCC? Because this is a learning institution, it's probably too heavy-handed to impose Rigid Standards on the developer.
However, the alternative is Pure Chaos:
No one has any idea where all our programs live or what they are supposed to do.
When something breaks, the only resources we have for understanding the defect is the source of the program (if we have it!), and the comments (if any!).
When an employee graduates and their work account gets deleted, things may break, and a lot of work product may vanish without a trace.
Somewhere between Total Chaos and Rigid Standards there must be a happy medium. Instead of Standards, let's call them Guidelines: they point the way, but they're flexible, and we hope they will improve as we get experience with them.
One of the benefits we want for our student employees is that they graduate with a solid portfolio of working, documented code they can show potential employers.
Over and above the TCC's needs for inventory and documentation, these guidelines can give students experience in modern practices that will look good on their résumé.
How much documentation is enough? This document proposes a graded series of practices. Everyone must supply the minimum.
Section 2, “The absolute minimum”: Minimal requirements for documentation.
Section 3, “Apprentice level”: Practices we expect from anyone who considers themselves a student of programming.
Section 4, “Journeyman level”: Career programmers should always do professional work. This section discusses better practices that will pay off in the long term.
Section 5, “Mastery”: For serious career practitioners of software engineering with many years of experience.
The plan is that everyone must follow the minimum standard, just so we know where all the programs are and what they're supposed to do. For a small, quick script that isn't mission-critical, that may be all we need.
However, depending on the size and importance of the project, and the career path of the developer, we would like to recommend a graded series of better, proven practices. As the project progresses, you can add more of the advanced levels to the existing documentation.