[1] Many computer programs require being robust and reliable for long periods of time,[2] so any rules need to facilitate both initial development and subsequent maintenance of source code by people other than the original authors.
In the ninety–ninety rule, Tom Cargill explains why programming projects often run late: "The first 90% of the code takes the first 90% of the development time.
The size of a project or program has a significant effect on error rates, programmer productivity, and the amount of management needed.
Some of these can be mutually contradictory (e.g. being very fast versus performing extensive error checking), and different customers and participants may have different priorities.
[5] Furthermore, he notes that programmers will generally aim to achieve any explicit goals which may be set, probably at the expense of any other quality attributes.
[6] Weinberg has identified four targets which a good program should meet:[7] Hoare has identified seventeen objectives related to software quality, including:[8] Before coding starts, it is important to ensure that all necessary prerequisites have been completed (or have at least progressed far enough to provide a solid foundation for coding).
From Meek & Heath: "What happens before one gets to the coding stage is often of crucial importance to the success of the project.
The waterfall model is a sequential development approach; in particular, it assumes that the requirements can be completely defined at the start of a project.
[10] The other methodologies mentioned above all attempt to reduce the impact of such requirement changes, often by some form of step-wise, incremental, or iterative approach.
[11] McConnell states: "The first prerequisite you need to fulfill before beginning construction is a clear statement of the problem the system is supposed to solve.
"[12] Meek and Heath emphasise that a clear, complete, precise, and unambiguous written specification is the target to aim for.
Software architecture is concerned with deciding what has to be done and which program component is going to do it (how something is done is left to the detailed design phase below).
"[17] From Meek & Heath: "The essence of the art of choosing a language is to start with the problem, decide what its requirements are, and their relative importance since it will probably be impossible to satisfy them all equally well.
It is, therefore, imperative that the programmer chooses or makes up a particular set of coding guidelines before the software project commences.
Some coding conventions are generic, which may not apply for every software project written with a particular programming language.
Also, if complicated logic is being used, it is a good practice to leave a comment "block" near that part so that another programmer can understand what exactly is happening.
Complicated logic for achieving a simple thing should be kept to a minimum since the code might be modified by another programmer in the future.
Programmers tend to write the complete code and then begin debugging and checking for errors.
Though this approach can save time in smaller projects, bigger and more complex ones tend to have too many variables and functions that need attention.