I think the C# tutorials made by Microsoft are a good start.

https://msdn.microsoft.com/en-us/library/aa288436(v=vs.71).aspx
http://www.microsoftvirtualacademy.com/training-courses/c-fundamentals-for-absolute-beginners
http://www.microsoftvirtualacademy.com/training-courses/developer-training-with-programming-in-c

And the ultimate list of free programming books online is always a good start...
https://github.com/vhf/free-programming-books/blob/master/free-programming-books.md#professional-development

Not true, judges also need to follow the law, and in contract law the main rule is the "Parol Evidence Rule".

It basically boils down to this: If the written words of a contract are enough to come to a conclusion, but one party gives testimony in court that their intention was different, then the judge is not allowed to use the testimony and has to follow the written words in a ruling. Even if the judge might feel that both parties understood the intention, he/she cannot follow the verbal testimony.

Example: Microsoft gives testimony in court that they meant that the promise was not a contract that's enforceable, then the judge is still not allowed to rule this, because the legal definition of the word "contract" is

Bilateral and Unilateral Contracts The exchange of mutual, reciprocal promises between entities that entails the performance of an act, or forbearance from the performance of an act, with respect to each party, is a Bilateral Contract. A bilateral contract is sometimes called a two-sided contract because of the two promises that constitute it. The promise that one party makes constitutes sufficient consideration for the promise made by the other.

note the specific mention of the word "promise" here.
So due to the parol evidence rule, a jude would not be allowed to rule that the promise is not an contract in this case.

Other example: Microsoft testifies that it had the intention the contract was terminated retroactively. However because the legal definition of the word "termination" is

The termination or cancellation of a contract signifies the process whereby an end is put to whatever remains to be performed thereunder. It differs from Rescission, which refers to the restoration of the parties to the positions they occupied prior to the contract.

So due to the parol evidence rule the judge is not allowed to grant a retroactive termination, because the correct legal wording for that would be "rescission" or "retroactive termination" and neither was used in Microsofts promise.

For whomever wonders what the exact definition of the parol evidence rule is: http://legal-dictionary.thefreedictionary.com/parol+evidence+rule


It seems to me that Microsoft took great care in the wording of their promise to make sure they can enforce it in court. I have this feeling because of the way how the promise is set up: its a promise between Microsoft and you personally, and you personally will not be involved in a patent case against them. And if you are the promise will terminate. All of this points to the promise not being valid as soon as you are standing in front of a judge, by which time the judge will ask Microsoft if they have a counter claim. I speculate that they wanted to give a feeling of security to the open source community, which is why they didn't retroactively terminate the promise. With the amount of patents Microsoft holds, that's not really needed anyway.

Microsoft could not have pulled their pants down much lower in my opinion, but if you still like to think that Microsoft has some evil intentions with this patent grant, then, like with any contract, you're of course allowed to not accept it. If you're a programmer however, you're most likely still infringing one of those many thousands of patent and intellectual property rights they own.

Still, uber-complex legislation is bad, mmmkay?

-JavaJones (July 14, 2010, 07:28 PM)

I agree

The point of the "Lessons from Grand Central Terminal" article was that the complexity introduced in new laws was bad because it only creates more points of failure. Personally I think the bad part of the complexity in legislation is that it hides the fundamental flaws in them (especially from the usually not so bright politicians).

Take the BP example of the article: "Even the government’s response to the tragically ongoing BP oil spill has been one of triangulation and determined-complexity. Get some supertankers to siphon off the leaking oil? Nope. Help Louisiana Gov. Jindal to build some temporary barrier islands along parts of the coastline?  No sir.  Keep a boot on the throat of BP — hey, that’s a killer sound bite!  Let’s go with that!"

The solutions proposed by the article are overly simplistic. They will work and do well for this specific case, but they will not prevent a next oil spill… The harm here is that the solution is still flawed, even though it looks solid.

Corporations are invented with the sole purpose to parasitize off of the common wealth. If you designed the law this way, you should not put out the accidental fire it caused and then think you solved the structural problem. Corporations are by law not liable for the cost they impose to future generations and the public as a side effect of making a quick buck. No oil drilling company has to provide replacement energy reserves for future generations, and no oil company pays for cleaning up future oil spills. This lending upon the future is true for any kind of corporation.

BP was allowed to parasitize society. They are even required to do so by law!

The main problem of the article was again not analyzing the validity of the example used and misusing the example in such a way it has a killer sound bite...



Anyway I was more interested in the software design side of this discussion, since I do believe complexity is a problem when it grows exponentially (which it does almost automatically if you are not very strict in maintaining architecture).

Take building a house as an analogy.
Doghouse (or small software): You take a few timbers and nails; throw them together and voila a doghouse.

Let’s size it up 10 times.

Normal House (medium sized software): You take a few bricks and mortar; throw them together and voila a normal house. It might just work although having it architectured is usually a better solution.

Let’s size it up 10 times.

Cathedral (highly complex software): You take a few bricks and mortar; throw them together and voila a … uhmm ... pyramid?

Without design a cathedral cannot support its size. The amount of materials is too big and the whole thing will collapse under its own weight. The only way to get a lean structure with so much empty space in it is via architecture and design. Complexity is not the problem, complexity without architecture and design is.