Month: October 2006

Why should you fix a code problem as soon as you find it? If things break, a classic example are unit tests, and they do not get fixed, then other breaks appear and get left broken. This effect has a tendency to escalate to the point where people ignore unit tests, eliminating the benefit that units test provide.

The effect was coined as applied to vacant buildings. As soon as a single window is left broken, others will follow and the effect actually spreads out from the building into the neighbourhood. It is easy to imagine that this effect is real; just apply it to the house you live in. If you leave something that requires attention, you are more likely to leave other things as well (I have experienced this effect first hand!).

This principle of Fixing Broken Windows was documented in the US, and has its critics due to the fact that in society it is hard to eliminate/identify all other contributing factors.

Andrew Hunt and David Thomas used “Fixing Broken Windows” as a metaphor for avoiding software entropy in software development in their book, The Pragmatic Programmer. Next time you are coding and you see something that is broken, maybe you should err on the side of caution and fix it?

(Not to be confused with the Parable of the Broken Window)

Patrick Altman reminded me of a question I raised on the [aus-dotnet] list several weeks ago, regarding inheriting from BindingList rather than List. BindingList is designed for data binding and data changed event notifications. If you derive from List and you want to be notified when someone changes the collection, you will have to implement this yourself. David Kean has an excellent blog post on this subject and why FxCop encourages exposing Collection over List here.

The reason I mention this is because at a company where I was working recently, the programmer responsible for writing framework code was not aware of this. Thanks to David Kean, Bill McCarthy, Paul Stovell and Mitch Denny for their input.

Lifehack.org is one of those places you go when either you want to think about something other than programming (perish the thought!), or examine and possibly improve some area of your life. Creating Hardworking Idiots caught my eye:

Today’s fast-paced, macho style of organizational culture creates, and then
fosters, the hardworking idiot. Indeed, I think it takes a great many sound,
useful, hardworking, and clever people and turns them into idiots by denying
them the time or the opportunity to think or use their brains.

Saw this fun post on diggdot.us: Explaining RAID technologies to new clients

Mark Russinovich has understandably not blogged for a while, as I daresay he was a little busy with his recently taken role at Microsoft. He breaks this drought in Holmes-esque fashion with this excellent post sleuthing his way through the labyrinthine windows internals using Filemon. The article mentions the simple but very effective technique of loading lengthy traces into Excel to discard time and sequence related columns and using Windiff to quickly find answers.

If I had to name a Windows programmer who has had a huge impact in the developer community, it would be Mark and the essential tools from SysInternals.

Congratulations to Rob Farley on being awarded his MVP. Rob is active in the newsgroups, his local Adelaide based SQL Server user group and developer community and is always willing to help out someone with a problem (I’ve probably missed a stack of other things). Great news Rob, it’s well deserved.

I’ve been trying out LINQ recently (C# 3.0 language enhancements post coming up) and one of the irritating things I noticed was smart tags no longer work correctly. Karen Liu has posted a fix here.