As Peter Sellers, as 'inspectur Clouseau' used to say: "I will say this only wunce...':: There is no 'one true language'. Language fights are so stupid. The quality of software is much more determined by proper design, coding practice and programming style, than by languages. Every language has its pro's and con's. Usually programmers idolize the language they know. They think that language is the best, because they can use it best.

Why is it wrong? I think it's well worth that money. It's their software and they have the right to have you pay for a license. So, I repeat, Thanks Redgate, for allowing to use Reflector so long for free!

Oh, there are many things to add to this list, like: -use exceptions for ALL conditions, not just the exceptional ones. It will kill performance even more. -Don't ever refactor code. -Make large, complex nested if/else structures, and initialize variables in almost every branch of it, so the reader will never now if variables have been initialized after that structures. -If a function requires more input, don't add parameters. It will require you to change all calls to it. Rather add a global variable... -Put many classes in a single source file and avoid the file name of that source file to make sure nobody will ever find your classes. And much more, sigh... And all of this really happens...

Of course. Running around not knowing where you wanna go means you'll end up running in circles and I've seen that all too often. If a building were built the Agile way - as some people see it, it would probably be something like a sky scraper built on the foundation of a little cottage, with no elevator, because in the beginning we thought just stairs would do, and so on. It would collapse. Every project without a clear-cut vision on what's to be accomplished is bound to fail, whatever development method is used.

I think it's a bit to simply stated. Admit it, or not, but most software designers either aren't capable to estimate development time accurately if they're given a detailed design. And, even if there is a proper design, the as-built end product is often not really what was designed. There's what I'd call the 'design paradox'. On one hand, you can't estimate costs accurately, if you're design isn't detailed enough. As a result, the details will be designed while coding, design flaws will creep in and that causes a lot of additional debugging. On the other hand, if the design is very detailed, in theory this would lead to less bugs, and a better manageble project, but in real life many "bugs" will be built into the design already, because what looks nice on paper, might not work in a real program. And we all know it's virtually impossible to correctly estimate the time involved in finding the cause of a bug. So having or nog having a detailed design mostly means moving the problem from one end of the project to the other: the 'law of conservation of misery'. So we have to find a compromise between detailed design and hands-on programming. Several things have been proposed in the past. In the mid-'90s, RAD was promoted, now it is Agile. At first sight, Agile looks as if it's just throwing ingredients into the pot, hoping something edible will emerge. But then we overlook a few things. Agile is not only about taking the product the market sooner, it's also about collaboration with the customer and even better, with the end user. To many end users, a detailed design of a complete product is too abstract to comprehend. That's where the communication problem starts and in the end the software turns out not to be doing what the user wanted. Agile tries to address this, by shortening the design/develop/test/deliver cycles. The idea is not to leave out design, but not to design all at once in detail. Personally I'm convinced you'll always need an overall picture, a 'grand design', but that doesn't mean you have to design everything in detail upfront. To some extent, it is what we've been doing all the time already - or rather, should have been doing all the time: start to make a rough design of what we want and then refine it. Tradionally, all of this was done by the designers, but Agile aims to get the end user involved. The way to accomplish this the Agile way, is to refine a basic number of features, build them and present them to the user for evaluation. I don't expect anyone to dispute that if that turns out