...: Marsh Chatter
Go 1/2 way, then go 1/2 way, then go 1/2 way...
Or "When is it... done or good enough or complete"?
How do you know when to stop working on a project? That sure is a tough question! Do you realize that many book publishers have to stop authors from continually rewriting parts of a book? Well they do. Just like a programmer revamping one more method, a book author is always "tweaking" just one more word or paragraph. Once published, you spot many more items that you wanted to change.
When is a program done? Well that is a decision you and your client will have to make. In nearly all cases you will find the decision revolves around 2 things - usually referred to as...
Most 'bang for the buck'
Or more appropriately - it's a features vs. cost decision.
Let's break this down a bit...
After the initial design stage and the heads-down programming process begins, I tend to "see" 3 separate functional stages or tiers. The lowest tier: the 'rough-in' stage, the mid-tier: the 'closing in' stage, and the upper tier: the 'finishing' stage.
For anyone who has watched a few shows of This Old House or various HGTV shows - you will find my use of house building metaphors to be a close fit. If you don't watch these shows or have never owned or built a house... well just play along, you'll pick it up.
Low Tier - rough-in stage
The lowest tier is where there isn't enough of anything for the client to see, much less do anything. Think of this as staking out the footprint, laying the basic foundation parts, and pouring the concrete. The stairs are really a ladder, no floors, walls, or roof. Hard hats are required and contractors usually don't want the customer on the job-site because of the dangers.
Now contrast this to a program. You're developing the database, the code to connect to the database, the basic form structure, there is the high probability for parts not to work, and the slightest change causes a crash. As with the house job-site, this stage in the project can be upsetting to the client. They "don't get the picture" yet, the errors scare them, and they wonder why the demo worked, but now the product doesn't. Clients hovering around do not help at this stage of development.
Mid-Tier - closing in stage
The mid-tier is where your client can actually begin to see the product. In the house build - this is where the framing goes up, electrical, plumbing, and heating & cooling is installed. The end of this stage sees the drywall go up and the rooms take shape. Customers can really see "the house".
For the program, this stage seems to be the longest, but it is also where the product really takes shape. Data can be entered, buttons pressed, functionally the program begins to work and could begin to provide some productivity gains.
Clients can now see the whole picture and thus they begin to make suggestions - call them 'what-ifs' or 'how about this' or 'can this be done'. We call this scope creep. In the building trades... it's a change-order. Either way it means extra work and not always easy work because of the redesign and structural changes necessary to weave in the new parts.
Upper Tier - finishing stage
Keeping with the house building metaphor, this is the stage where the moldings are put up, the final paint work, staining, wallpaper, and more are completed. At this stage, the customer is getting anxious. They see the house, they can walk through it, and they wonder why they can't move in yet. "It doesn't seem like a lot of work, to them". But the final details - precision cutting/fitting of moldings, flooring, drying time between applications, etc. all take time.
To the developer, optimization thoughts creep in. Change this code to make it faster or more lean in code lines. Refactoring benefits future development, but again, you must weigh the time value in this "first version". Make the change that saves processing time, make the change that creates a more intuitive process, but don't make the change "just because" - be sure there is value in a change.
In the program world, I consider this the "high-cost, high-effort" tier. This means that it will take a long time and cost a lot of money to make something 100%. As if any program can ever be 100% - some feel it can, yet they immediately suggest one more feature - thereby making it less than 100%.
This stage in programming can eat up a lot of time, without equivalent monetary return. It is this stage where most consulting contracts break down. Errors are reported, but turn out to be function or design changes - not true errors. Essentially the design & planning was not deep enough to ensure everyone would be satisfied. These what-ifs have to be turned into version 2 or 3 features.
1/2 step, 1/2 step, more
You would think "good enough/complete" would be understood by all, as it is prevalent in all industries where "building" takes place. But the "when will it be done, foot tapping" always occurs during that third stage, right after the scope changes have been submitted.
Consider setting up the project to have shorter goal "steps". Get to an early productivity step and roll the product out. Enable the client to use the product while you weave in the next puzzle piece. Each stage you increase the client's productivity, while enabling yourself to work on the project a piece at a time. Business wise - this enables you to start and maintain the cash flow. For the client, if they want to stop the project, they can - while still having a product that works and provides some level of productivity.
All projects, be they: applications, programs, or buildings - reach a "good enough" stage - for that time, knowledgebase, and conditions. There will always be a new room to add, paint to change, menu item and form, code that can be tweaked - understand that at the beginning and your development life will be much easier for you.