Daniel recently discussed the Minimum Viable Product development approach.

As discussed in his article it has the disadvantage that it results in a lot of code that will be thrown away after being deemed to be insufficient.

An alternative approach is to do some analysis up-front and determine the full set of functionality and split the work into sub-projects, so that each component is a project of value by itself.

For example, you may be writing a daemon in python which needs to be able to safely create and read PID files.

You would then need to investigate which projects exist for doing so, evaluate whether they are sufficient, and if not either develop a replacement or contribute to an existing project.

For an ambitious project this can provide more good in the short term, since while it will take a while before the project's main goal is achieved, some of the component parts are already of value.

This can be better for motivation than the Minimum Viable Product approach if the developers involved tend towards obsessing over minutiae and having the "correct" solution for every little part of the project.

However it is particularly vulnerable to losing motivation from introspection of the current state of the project compared to its goal, since it takes longer to get to something demonstrable if feedback on the individual components is not readily available.

This may be viewed as an agile vs. waterfall development methodology, since it requires a large amount of analysis up-front to determine which components are required and which should be split out into separate projects, but those individual components may be reusable.

Similarly, if it turns out that the goal of the project was bad, then at least the component parts of the project are salvageable.

If the project does eventually fail, then at least lessons will have been learned for future attempts.