To elaborate what I meant by "Research/Design/Thinking", I meant to say that all cogitation about a project, be it on the problem domain, the answer domain, the implementation domain, and/or the testing domain ... all of that should consist of at least 3/4 of a given project's time.

You cannot build a good set of test suites unless you've thought about how the requirements need to be tested. This includes black and white box testing, as well as other methods. (Bounds testing comes to mind...)

You cannot build a good implementation without thinking about the ramifications of a given concept. A few things I like to think about would include:

• Is it easily extended?
• Is it easily maintained?
• Is it easily documented?
• Is it legible? (This is probably the most important, in my mind.)

And every other domain you can think of falls into this catch-all category. I thought about possibly breaking it down further, but realized that you might have to research a lot of non-programming stuff (like I've been having to do) for one project, but have to research a lot on algorithms in another. Or, you might be spending a lot of time designing the test suite. Maybe the implementation is conceptually easy, but the testing is damnably hard. Or, it could be the other way round, or a mixture of both. Code Complete makes it very clear that what goes into the pre-coding aspect of a project is impossible to determine for all projects. That's why they pay us the big bucks. :)

------
/me wants to be the brightest bulb in the chandelier!

Vote paco for President!