A program may never be truly finished, but often in practice you reach a stage where the bug count is low and there isn't much extra to be added - at least for

A program may never be truly finished, but often in practice you reach a stage where the bug count is low and there isn't much extra to be added - at least for certain types of application. This probably doesn't apply to things like operating system kernels, but does for more specific stuff like a datamatrix reader. Also it is a good idea to avoid too much software architecting from the top down. I made this mistake early on, because "divide and conquer" was how the books said it should be done. Often a more bottom up approach works better, and is more adaptable to mid-project changes in requirements.