DBC - Design by Contract
this one's another idea in Software Engineering.. the basic idea being that any object/routine has to satisfy certain rules at all the times for it to be accepted as working properly.. i.e. you specify the contract for the object/routine which says the conditions just before and after the usage/execution of the object/routine that it must satisfy.. the objects/routines that satisfy the contract ensure that the software does exactly what it's supposed to do.. and in DBC, we start by defining the contract and then we write code to satisfy the contract..

I see some concepts of TDD lurkin in there, only they're a lil better.. in TDD, we start by writing a test that tests the behavour of the object/method once it's in place.. in DBC, we specify the contract which's pretty much the same except that it also ensures the conditions that must prevail before an object comes into existence for the object to satisfy the contract..

I kinda liked the idea.. first impressions are pretty good :) but I'd like a combination of TDD and DBC.. call it whatever ;) but write tests and the contract both and make your code pass them.. of course it's extra effort, but I the quality of the software generated makes it worth the effort..

there are problems that I could see abt this.. say for example, it's not always feasible/easy enough to describe the contract succinctly.. theoretically, one might say that the class/method shouldn't exist if it's purpose can't be defined crisply.. but in practical situations, it's a bit hard to say so :(

but then the same applies even to TDD.. it's not always possible to start off with a good test for the code you're writing.. well, theoretically it's possible, but practically, at times the effort for the test overshoots the effort you put to write the code for you functionality.. but then, that's not the point of TDD right? all these practices that we ('re supposed to) follow are for the code quality and to help us in the long run while modifying the codebase..

neways, the arguments and counter-arguments can always be made.. but I think both are good practices and believe that a combined approach would be far better..

one major problem I see with DBC is that all the material I found has been Eiffel centric :( Eiffel provides certain constructs which make it easy to do DBC.. maybe we can write external tools for other languages.. just like JUnit/NUnit etc.. but I'd prefer a builtin language construct for that.. hope Microsoft guys integrate all these in the next release of C# (a.k.a C# 3.0) :) or maybe we can use the C# attributes to do all these stuff, in a pretty clean way.. but not sure how clean would that be..

follow these links for a nice presentation describing DBC (using Eiffel of course ;) )
http://www.eiffel.com/developers/presentations/
http://www.eiffel.com/developers/presentations/dbc/partone/player.html?slide=
http://www.eiffel.com/developers/presentations/dbc/parttwo/player.html?slide=