Cool story because Galileo is one of my top 5 scientists:
(CNN) -- Two fingers cut from the hand of Italian astronomer Galileo nearly 300 years ago have been rediscovered more than a century after they were last seen, an Italian museum director said Monday.
Removing body parts from the corpse was an echo of a practice common with saints, whose digits, tongues and organs were revered by Catholics as relics with sacred powers.
There is an irony in Galileo's having been subjected to the same treatment, since he was persecuted by the Catholic Church for advocating the theory that the earth circles the sun, rather than the other way around. The Inquisition forced him to recant, and jailed him in 1634.
The people who cut off his fingers essentially considered him a secular saint, Galluzzi said, noting the fingers that were removed were the ones he would have used to hold a pen.
"Exactly as it was practiced with saints of religion, so with saints of science," Galluzzi said. "He was a hero and a martyr, keeping alive freedom of thought and freedom of research."
If you've deleted the DLL or if you reinstalled a DLL which no longer contains the codebehind class for a user control in a web part, you could end up in a scenario where you have a "dead" web part on the page. In my case, it prevented the page from loading and resulted in an error because it couldn't load the type.
Don't panic! The solution is to add a ?Contents=1 to the URL (i.e. http://moss.dev.com/default.aspx?Contents=1), which will allow you to delete the web part from the page.
UML is a useful tool, no doubt. It's a tool to help model complex logic in a visual manner. It's a language in and of itself and it can aid in communicating design ideas with exacting precision, leaving little room for error. However, at the same time, as with any formal language, it creates strict rules for communicating in that language. Syntax, vocabulary, "grammar"...these all apply to propperly using UML.
Myself, I've never been a big fan of UML. There are different ways to convey ideas, intent, and understanding of a set of requirements, but imposing UML is like asking a blogger to write all of their posts in iambic pentameter when prose would work just as well. What's the point? Your colleagues can already all read English, but not everyone reads UML...why add that burden and rigor?
There's a big difference between the rigor required to build a bridge and the rigor required to build a web application. Miss your target by a foot, and it's a multi-million dollar mistake if you're building a bridge. If your bridge throws you an "unexpected exception"? You're talking possible risk of life! A web application or a portal? Unless there are fundamental, framework level mistakes, most changes are negotiable; it's software for a reason (and oddly enough, on large projects, the cost overhead isn't necessarily associated with the development side, but with the business side and the specific processes for validation, testing, and change management - maybe those guys need to fix their processes...).
Now this isn't to say that getting it right isn't important, but at some point, process and progress starts to drag as you impose an inordinate amount of rigor.
With regards to sequence diagrams, Scott Ambler puts it very well:
The most important things that you can do is to keep your diagrams simple, both content wise and tool wise. I will sketch sequence diagrams on whiteboards to think something through, either to verify the logic in a use case or to design a method or service. I rarely keep sequence diagrams as I find their true value is in their creation.
A common mistake is to try to create a complete set of sequence diagrams for your system. I’ve seen project teams waste months creating several sequence diagrams for each of their use cases, one for the basic course of action and one for each alternate course. My advice is to only create a sequence diagram when you have complex logic that you want to think through – if the logic is straightforward the sequence diagram won’t add any value, you had might as well go straight to code.
I agree wholeheartedly; the exercise itself is more important than the final artifact. It's far too easy to interpret the intent of UML incorrectly; the value is not the artifact, the value is the process.
At the end of the day, it is not a silver bullet! It doesn't make your design more complete. It doesn't mitigate all of the risk. It doesn't make your intent free from misrepresentation or misinterpretation. It doesn't make a design document bulletproof.