Select distinct is considered bad

Correction; Considered a warning.

Here is a good rule-of-thumb: If you have to write an SQL with Select Distinct, do adjust your chair, get a cup of coffee, walk around the office but above all talk to someone else because Select Distinct is a symptom of something being wrong, either in the database or in your solution.

/* Select Distinct is normally not needed when your database is lagom normalized. But if you do need a Select Distinct then this is a very good example of a situation that needs to be documented.*/

Software architecting lacks good notation

I found a blog entry at http://www.matshelander.com/wordpress/?p=74 which although lengthy and wordy hits the spot.  There is no good notation system for software architecting.

My words: Comparing software architecting to building houses is ridiculous.  Just because they share the same name (architecting) doesn't mean they have a lot in common.  Compare a sea horse and a horse and you get the same useless result.

The romans would never be good at mathematics since they lacked a good notation.
What software architecting needs is a good notation.  UML is one way but it is not very good for evolving solutions and finding bugs.  Code is the best notation I know of but it is too close to the very program and not good at describing architecture.

Besides, after several thousand years of building houses we still miss the estimated cost.

How to write xml comments in c#

My prefered way to write XML comments in C# is to write the first sentence on the first row like this:

///

This method does nothing.
///

public void Foo()
{
    //NOP.
}

because when one folds the code (ctrl-m-o) one can see the first row like this:

///

This method does nothing. ...
public void Foo() ...

This is not an issue in vbnet.

To create a document out of this use Sandcastle which takes over after nDoc which is discontinued.

No information is better than wrong information

With no information you have one task.
1) deduce the right information

With the wrong information you have to:
1) understand the information
2) find out that the information is wring
3) deduce the new information

Communication, communication, communication

Arguably one of the most important things in a project is communication.

In a project I started all briefing for new participants with the words
"I have three things that are the most important things in this project. They are communication. Communication. And communication." I then wrote this on the black board and let it stay there for the rest of the meeting.

I still believe communication is one of the most important things and if anyone has any input about how to communicate better - please drop me a line.

What I am primarly looking for is
- how to aid communication, how to make it naturally
- how to communicate lots of information in little time
- how to store communicated information
- how to search and retrieve communicated information

Comments are code

Not totally correct;
Since it doesn't compile;

Too often when I look through code I step on comments that say one thing and code that says another.
This has even made me waste time hunting bugs along the wrong track.

Documentation - less is more

I got the coding rules for a big company. 200 pages. I put it to the side with the thought "Noone else has read it either."

Too little documentation, read or unread, is better than long that is not read.