Forgive me - but I'm not going to answer the question you asked - because code first vs. database first is (IMHO) immaterial. You'll find your own preference, or your circumstances (such as a pre-existing database you have to work with), will dictate what you do. (Also, personally, I'm old school - I create my C# classes, and my Data Definition Language scripts - CREATE TABLE ... - at the same time. I like having precise control of my schema, foreign key constraints, indexes, primary keys, etc. AND I like being the author of my POCOs). If you're new to using databases, there's a chance you're new to data modelling in the relational world. Understanding what makes a good (i.e. easy to understand, reliable and efficient in time and size) schema is far more important than how you translate between database objects and programming language objects.

Nah! Not a bug - just a hacker having a laugh!

The game looks cool enough - but the music is awesome! Is it an original composition - or something from the swing / ragtime era? What's its name, and do you know of anywhere I can find the sheet music?

I concur. Further, once the exception has been handled there should (normally) be no need to rethrow it. This rule leads to the useful guidline: catch exceptions at the lowest level where they can be meaningfully (i.e. completely) handled. The exception to the no-need-to-rethrow rule is when some cleanup action is needed as the stack is unwound. In that case, catch the specific type of exception, do the local cleanup only, and rethrow (ideally, using throw without a paramter - to preserve the stack trace). Do not duplicate the work that will be done in the can-meaningfully-handle-it catch block (such as logging, notifying the user, clearing context). Note that the using (...){...} construct implicitly follows this rule: in the event that the contained block of code throws an exception, it will automatically invoke the Dispose() method on the item allocated by the using() statement.

Vaughn Bigham wrote:

'we can't get the alpha and beta testers in if its all locked down first.'

If the security isn't in the system by the time alpha or beta testing is being conducted, then that testing is hardly valid, is it? :doh: Assuming that your quote is an accurate representation of your colleagues concerns, the following thoughts may be helpful... Unless you've also got gamma, delta and a whole Greek alphabet of testing stages, then you and your team likely share (an approximation of) the following sense of what alpha and beta testing are about:       * beta is it really should be ready for release, but we know there are (likely to be) bugs and/or usability problems that real use will shake out, and       * alpha is it's basically done; we know it's real shaky and there are some features we're not sure whether to polish up or kill, but it's enough like the real deal that real-world evaluation will be valuable Going by those definitions (or even something close to them), without a functioning security infrastructure the product is just not complete and you're not ready for alpha, let alone beta, testing. So the rest of the team (if they even come close to those definitions) need to rethink their justification for holding off on security. Going back to the quote:

Vaughn Bigham wrote:

'we can't get the alpha and beta testers in if its all locked down first.'

A finished, released, product needs to be able to add the first user - so the experience of "it's all locked down" can never be a condition that applies to a finished product. If security is present and you can't add testers to the system, perhaps you need to ask "what is the intended means of adding the first administrative user in the finished product?" and then redefine the scope of "security" so that adding the first user to the system is a security issue, not a content issue. Once the ability to add the first admin user is defined to be a security behaviour, not a 'content' behaviour, then the first round of (unit) testing would be to verify that the security architecture is valid and complete ... and all subsequent rounds of unit, integration and alpha and beta testing build upon it (instead of requiring it to be delayed until the last minute).

I would be interested to know how many readers share your distinction of search (expanding) vs. find (narrowing). While I'm not disagreeing with your definitions, I'd like to add that I haven't ever noticed that I use similar semantics: to me, search is synonymous with find. Also, in common usage (i.e. when talking with non-technical people, using those verbs in a context other than the internet & web sites) I've not noticed that other people make that distinction, either. RANT On the rare occasions when I use search on a web site (other than Bing or Google), I generally am cautious as to what to expect (site search vs. web search) ... and I'm also quite annoyed that I have to ask myself that question. A search field in a web site SHOULD ONLY EVER SEARCH THAT SITE (IMHO!) unless the site exists only to provide internet search (i.e. Gingle and Boob). END RANT So, if search === find, then the choice of icon present in the search/find box is, surely, meaningless. Further, if different people associate search/find to binoculars/magnifier icons differently, perhaps neither icon is appropriate for the purpose - because neither icon's 'orginal object's common value (making a view of things bigger ... bringing out details not otherwise visible) is close enough to the meaning of search or find (locating something that you anticipate being accessible, but you don't know where/how to find it - an interpretation that seems to apply equally to search and find).

As with other replies, I favour the 'x' in the tab itself. I would also strongly oppose putting OK/Accept/Apply/Close/etc. buttons at the bottom right corner of (i.e. inside) tab pages (which is what it sounds like you're currently doing). My objection to the use of those buttons (anywhere) inside a tab page is that buttons of that nature (which are commonly at the bottom right) customarily relate to dismissing an entire form or dialog ... and a tab page is emphatically not the whole form. As programmers we're used to overloading methods; our users, however, have a great capacity for getting confused (does 'apply' apply to just the tab or the whole tab set?, etc.). Having a cluster of OK/etc. buttons outside the (outer-most nested :~ ) tab control is fine - because it clearly applies to the whole form and so is consistent with other places where people will see such buttons. Now that I think a little deeper, however... I think of browsers, Notepad++, etc. (i.e. other apps that use tabs to effectively contain distinct and independent documents (literal or otherwise)) - where the user's understanding of "what's in the tab" may mean that OK/etc. buttons within the tab are less confusing. I still don't like the idea, however. But that, perhaps, is just personal taste. Yet more attempts to understand how I relate to OK/etc. buttons... (For me) they are buttons that belong in, and are used to control, dialogs - not documents. And tabs are either means of grouping parts of a common document or of presenting distinct and independent documents. Either way, however, they are not dialogs. Hope something in the above helps. Chris

look for the spreading puddle as the water finds its way out without pushing up the sprinkler head?

Lovely trip down memory lane :) Haven't come across that instruction since playing around with 8 bit micros!

As CDP said - exceptions are named for the circumstances where you need to deal with the unexpected. In your example "the company already having a project assigned" could perhaps be considered an error; most programmers would not, however, consider it to be an exception. So here, too, the use of exceptions to deal with the situation is inappropriate. Given your specific example, I would venture to say that "the company already having a project assigned" is not even an error, but just a specific condition that you need to manage - and your example of showing a message to the user (second example) is consistent with that interpretation. None - after assimilating what conditions could reasonably considered exceptions (out of memory; out of hard drive space; file not found when it really should be there; web service not responding, etc.) it becomes an interesting question as to what an 'error' actually is, and whether it's a term that's safe to use. I'd say that there is no right answer to that question - but there is definitely value in considering the question and the implications of any answer you come up with.