In a recent meeting, someone brought up the agile development topic of not quite enough (actually mocking it, something like, "there's a methodology out there where you actually don't do all of the work"). I took a few minutes to rant a correction.

Not quite enough is a powerful concept that revolves around the idea that it is almost impossible to identify the 'enough' mark on a given development project. How much documentation is enough? How much testing? How abstract should the implementation be? These are all questions that are hard to answer until all the variables are known, and they can't all be known until the project is over with. The only way to deliver enough is to over deliver - and anything delivered that's more than enough is wasteful and inefficient.

Not quite enough tells us to do as little as possible (comparatively speaking, please don't spin in your chair for hours and expect the software to code itself) and depend on frequent customer feedback. This allows us to develop exactly what is needed quickly, adapt to rapid change with ease, and deliver great software in the most optimum manner.