Introductory Programming Lecture Notes: management

Small scale programming management

By programming in the small we mean programs written quickly, usually by a single individual, and for which low design and documentation standards are acceptable.

By design or circumstance, many projects during a student's academic years seem to fall into this category.

This is usually only the case if the software has a short expected life span (several months or less), does not perform any critical functions, and is only going to be used by the developer or by a tolerant experienced user.

For programming in the small, many developers traditionally produce little (if any) documentation beyond the commenting in the code and (perhaps) a short user manual or help facility.

There are still a number of methods we may use to produce quality code (these will become even more important in later semesters when you start working on team projects).

Small project planning and organization

There are two common approaches to small, informal projects:

working to a specific goal
working to a specific time frame

In the first case, there is an exact goal for the software capabilities, and we work on the software until that target is met.

In the second case, we have a set of goals and qualities, but a fixed time frame, so we attain as many of the goals and as high quality as possible in the allotted time.

A rough breakdown of the time spent on small projects is likely to look something like this:

10-15% of the total time is spent on identifying exactly what the product capabilities should/will be and planning the project
40-50% of the time is spent on design and implementation
25-30% of the time is spent on testing, debugging, and refining
10-15% of the time is spent on documenting

Throughout your computing coursework you encounter ways to effectively identify and record product requirements, carry out design and implementation, conduct appropriate verification and validation, and adequately plan and document software.

Many of the techniques discussed will be "overkill" for small projects. In this opening section, we will discuss some of the common design ideas that should be followed even on the smallest of programs.

Perhaps the most important rule of thumb is to write down everything. Keep a written record of

all you have learned about the requirements for the product
all the design decisions you made (how to modularize, which ADTs to use, which algorithms to use) and why you made those decisions.
all the test cases you have thought of and all the test data you have used
all the features that need to be described in online help (if available) or user manuals (if available)

It is probably also worth keeping multiple versions of the source code: often you will introduce bugs or other problems into the code, and having a copy of a previous version to back up to can save a great deal of time and effort "rediscovering" the right way to do things.