To go as fast as possible now, we must do as little as possible now.  To go as fast as possible later, we must PrepareTheWay now.  How do we balance these needs?

Look for parts of your process that aren't paying their way.  

	* Have you put off refactoring some classes and now you're paying the price in editing the same code in multiple places?
	* Are you writing documents that aren't being read, and that may never be?
	* Are you spending hours in Visio drawing pictures that no one understands?
	* Do you have huge framed comments at the beginning of every method?
	* Are there parts of the system that are so confusing that no one can find their way through them without comprehensive comments?
	* Every time you release the code, are you spending more and more time fixing bugs found by the customers in the running system?
	* Is system integration day a living hell?

These may be the signs that you are doing '''too much''' of one thing, in favor of '''too little''' of another.

If, amid it all, you aren't adding functionality fast enough, consider whether perhaps you are doing too many other things that are getting in the way of the code:

	* Refactoring messy classes rather than adding cruft to them can help you go faster.
	* Time spent writing and drawing useless materials can be spent coding or testing.
	* Reduction of comments can help focus on code quality.
	* Treating the need for comments as an even greater indication of the need for refactoring can improve the system and understandability at the same time.
	* More comprehensive UnitTest''''''s and AcceptanceTest''''''s can help you go faster, by providing faster feedback on how well things are working.
	* Keeping the system integrated all the time can be much less effort than integrating at wide intervals.

And one more: are you writing classes and methods in expectation of future use?  Consider whether you would be getting more done by focusing on what you ''do'' need, not what you ''will'' or ''may'' need. -- RonJeffries

----

To address the "Integration is Hell" problem, on my current project (see the GemStone page), we've taken the high road: Once a  week, every week, on Monday morning we:
	* run all regression tests (using a testing tool)
	* package a run-time image
	* build a version of the config map

The time spent up-front on these tasks has more than paid for itself as we approach our deliverable.

Also, we always have a functioning build that can be packaged at a moments notice (for a surprise demo, for example) that is at most one week old. -- AnthonyLander

''Anthony - that's a solid approach.  Also see FrequentReleases for how the C3 project (developed in VisualWorks and production in GemStone) addresses this same issue.  In a nutshell: we make our current config functional all the time!  -- RonJeffries''

But only from a UnitTest perspective, not from a system test perspective. We have sanity tested builds each night.

----

It just dawned on me that TooMuchToDo is really addressed by three strategies, one of which I haven't seen discussed here :
	* ReduceRealScope
	* ReduceHiddenScope
	* ReduceSneakyScope

----
See also YouArentGonnaNeedIt