Scott Hanselman

This error is more than a little irritating, especially considering this is Visual Studio 2005 SP1. I'm getting this, now, for one file, every time I run my application.

The way I "fixed" it was to exclude the file from the Web Application Project, recompile, then re-include, the recompiles.

Seems to me that the error handler that threw this message box should spend more time fixing the problem automatically and less time informing me of a problem I can do little about. Maybe that's just me.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By

We love bargains. We shop a lot at Goodwill, a local thrift shop where folks donate their old stuff. Sometimes you can find some amazing deals. I got an iPod Car Kit once, still in the original packaging, for $2. This evening we stopped by after dinner and while Z was running around bumping into things, he bumped into and knocked over a non-descript box.

Inside was a huge set of wooden trains and many feet of track - nearly a complete set. This is the kind of high-quality toy that costs $50-$100. I've always wanted to get Z a kit like this, but they are just too expensive to justify. It was only $9, so I had to pick it up.

We watched the news while I set up the tracks...as I was getting finished I revelled in the deal. I just love saving money and finding a fantastic thing like this, especially when I know Z will have fun with in in the morning.

I started putting it together and my wife wondered if I bought the train for myself or for Z. I began to take some pictures of the setup...

...and this story came on the news, literally as I was taking photos of the layout...I turned and took a picture.

...crap. You ever have one of those days?

How would one recall a piece of software...just release a patch? What if it were such a bad piece of software that it hurt babies? What a nightmare for these people.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By

Patrick Cauldwell is one of the architects on our Next Generation Banking System. A while back I asked him to write up our guiding principles for not only educating new developers but also for indoctrinating existing team members into our world view. He published it on his blog as This I Believe...The Developer Edition.

It's a great list. Here's a partial listing of the first two levels of his outline. Be sure to visit his post for the complete outline. It's bent towards .NET, because the stuff he's doing is .NET, but the general ideas are usable elsewhere.

• Our "guiding principles"
  • Test Driven Development
  • Continuous Integration
• Unit Tests
  • Two kinds of tests
  • Automation is equally possible for both sets of tests
  • All UI development should follow the MVP pattern for ease of testing
• Test Coverage
  • 90%+ is the goal
  • NCover runs as part of the build, and reports are generated
• Buy, Not Build
  • Take full advantage of the platform, even if it only solves the 80% case
  • Don't write a single line of code you don't have to
  • Take full advantage of .NET 3.0, SQL 2005, Windows 2003 Server, plan for- and test on Longhorn.
  • Don't invent new solutions to solved problems.
• Limit compile time dependencies on code you don't own
  • Everything not owned by us should be behind an interface and a factory method
• Define your data contracts in C# (think "active record")
  • All persistent storage should be abstracted using logical interfaces
• Fewer assemblies is better
  • There should be a VERY good reason for creating a new assembly
  • The assembly is the smallest deployable unit, so it's only worth creating a new assembly if it means NOT shipping something else
  • Namespace != assembly name.  Roll up many namespaces into one physical assembly if they all must be deployed together.
• Only the public interface should be public
  • Only make classes and interfaces public if absolutely necessary
  • Test code should take advantage of InternalsVisibleTo attributes
  • VS 2005 defaults to creating internal, not public classes for a reason
  • If it's public, you have to support it for ever
• Windows authentication (good)
  • Just say no to connection strings
  • Windows authentication should be used to talk to SQL, ADAM, the file system, etc.
  • You can take advantage of impersonation without impersonating end users
• Tracing
  • Think long and hard about trace levels
  • Use formatted resource strings everywhere for localization
  • For critical, error, or warning, your audience is not a developer
• Error Handling
  • Method names are verbs
  • If anything breaks the contract, throw an exception
• The definition of "done" (or, how do I know when a task is ready for QA?)
  • Any significant design decisions have been discussed and approved by the team
  • For each MyClass, there is a corresponding MyClassFixture in the corresponding test assembly
  • MyClassFixture exercises all of the functionality of MyClass (and nothing else)
  • Code coverage of MyClass is >=90%, excluding only lines you are confident are unreasonable to test
  • No compiler warnings are generated by the new code
  • Before committing anything to source control, update to get all recent changes, and make sure all unit and integration tests pass
  • FxCop should generate no new warnings for your new code
  • Compiling with warnings as errors will flush out any place you forgot documentation comments, which must be included for any new code

What guiding principles do you follow at your development shop?

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By

The folks at Channel 9 dug up another interview I did with Jeffrey Snover, PowerShell architect. Here's the one I did in November of 2006, for contrast. The project has grown

I think we filmed this in March. In this one I sing the praises of PowerShell and our team at Corillian that wrote "Project Evergreen," a deployment philosophy that turned into our Corillian Member Advantage product. Check the video out. Watch it via Windows Media or download the WMV. I hope you enjoy it.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By

A gentleman emailed  thanking me for http://www.hanselman.com/tools, and suggested I make a list of great Programming Books. I don't think it'll be as long as the Tools List, but here's my list. I specifically made the list Language Agnostic. Also, many of these books are by authors who write gold. That means, nearly everything they write is worth taking a look at. I haven't listed every book they've written, in those cases, just their "Greatest Hits."

When it comes to programming languages, I'm not a religious zealot or C# apologist. My religion in these matter is strict Apatheism. I just don't care enough to fight (except for VB people. They're just nuts. (kidding!)) . Pick the language that makes you smile and ships the project. It is for this reason that I prefer to read Language Agnostic Computer Books.

Code Complete - Steve McConnell - Darn near a bible of software development goodness, Code Complete reminds us of our priorities. It's essential and everyone who writes code should read this book.	The Pragmatic Programmer - Andrew Hunt and Dave Thomas - I like to read this book at least every six months or so. It's clean, clever, clear and full of concrete tips you can use to be a better, simpler, pragmatic programmer. A new classic.	Programming Pearls - Jon Bentley - This may feel initially like a C book, but it's really an algorithms book at its heart. It's old school with techniques and thought problems that can be applied today, even in language like Ruby and C#.
Refactoring - Fowler, Beck, Brant, Opdyke, Roberts - Although the language used is Java, the concepts are universal. This is a very linear, easy to read, learn by example book. If you think you know how to refactor, but you haven't read this book, pick it up and refresh yourself. You'll find names for Refactorings you've used for years and you'll definitely not only pick up new ones, but be better able to spot opportunities to use them.	Design of the UNIX Operating System - So few programmers today can answer questions like "explain how virtual memory is managed" or "how are Unix processes different from Windows." How did we get here. Know your history.	Design Patterns - Gamma, Helm, Johnson, Vlissides- One of the comments on Amazon says it best, "It is expected that any professional developer has read this book front-to-back. Buy it, read it, then put it in your bathroom and read it when convenient. Also, when you're done, spend some time at the Portland Pattern Repository.

UPDATE: There's some GREAT comments below, and I'm looking into each of them and putting together a list on Amazon.com. I made some pretty obvious gaffes (it was late. ;) ) by not including SICP (Structure and Interpretation of Computer Programs) or TAOCP as well as Types and Programming Languages. A number of folks said the list wasn't very language agnostic because it's very "C" and imperative language focused. Good points all!

What books did I miss, Dear Reader?

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By