Absolutely Don't Repeat Yourself and Keep It Simple, Stupid! (A DRY KISS) .
DRY and KISS are common concepts between software developers, but are very difficult to follow. Specially when you start with some idea, run with it, and it starts to layer up in complexity. Without even recognizing it goes out of control. With each of there added layers, you might find yourself repeating things without even recognizing the fact.
Drawing the very fine line between simplicity and and complexity is a very difficult task. It gets even more difficult without taking a step back to look at the big picture, the original aim, the purpose.
This is why an external review of the matter by a 3rd party is often vital. It gives perspective that helps the general good. Such a review process is often excruciating, painful, and long. But in the end of day, without it there is no real gain.
A a final note, I believe that A DRY KISS is something to try and follow in general.
Disclaimer: The following content is of an idea which might be already existing, so please feel free to comment if you find it in existing testing frameworks :)
A common problem I face during test-driven development is when having to tests (for ease i'll call them T1 and T2). T1 and T2 test the functionality of F1 and F2 respectively. The fun starts when F2 is dependent on F1, and both tests fail. In a test suit of thousands of tests, it would be hard to see the correlation from only the report of running the test suite.
It gets worse when the dependency between tests is not direct. For example if F3->F2->F1 (-> means "depends on"), where only T1 and T3 fail and T2 is fine. These relations need a very careful reviewer of the test results, and one who is well aware of the relations between components and their tests. This might be impossible in HUGE teams spanning many components.
But what if the testing framework was aware of these relations, and was able to report them. Such relations could be represented for example as new annotations in JUnit. With building the relation graph between tests it would be easy show that T2 might have failed because T1 failed.
So this is an open call, any one willing to try creating this, if it is not already out there?
One of my main uses for Google search is not the searching, but has slowing move towards often queries just for the sake of spell checking. Recently Google released its instant search. With that, I can easily see my spelling mistakes as I type, no more need to press enter :).
What I found by accident and found it even more useful is using instant search as a calculator. Some of you might know the Google easter egg about the answer to life universe and everything. Google calculator has been part of Google's search features for some time now. With the instant search, the results of the calculator is also changed live. A cool and useful example (that was the way that made me discover this) is the binomial coefficient function. Give it a try and play around with it here.