When developing custom solutions, it is beneficial to document the project in different ways. One reason for planning out the early stages of a project is to try and foresee any potential problems that may occur. During a project, recording what works and what deliverables are complete that are ready to be shown to the customer are just a couple of the reasons documenting is valuable. It is also useful to log changes in the project if other developers are working on the project, so that everyone is on the same track, or if the developer has taken a break from the project, and then needs to look back on it again. For customers, it can be effective to make a manual on how the solution works. Documenting will take up more time than seems necessary, but in the end, may actually save time.
There are many different factors when pre-planning and doing a project. The size of a project is a good indication of the amount of documentation. Naturally, if the project is larger in size, then there will be more documentation (even on a basic level). An additional variable is how likely the project may change during its life cycle. Most likely some documentation will be put in place to stay on the same scope so that the end solution is not drawn out by other tasks that does not have to do with the original scope. If there is some variation from the original scope and that is recorded somewhere, then if there is time spent over anything estimated, it can be shown why. (Then for next time that kind of actions may be avoided instead of wondering what happened.)
All in all, it boils down to communication between other developers, customers, and even yourself to enable everyone to be on the same page, thus leading to less stress, confusion, and work later. Thus, with like most things we do, we can optimize solutions to different problems; then we will have time to do other things (on the project). We can expand to different and new areas.
