Peter Bromberg's UnBlog

In my short happy life as a developer, I’ve run into all kinds of development efforts that include frameworks, libraries, web sites, and much more. The one thing that stands out as an irritant to me is complexity. Specifically, unnecessary complexity. I’ve seen developers author entire library assemblies that provide wrapper utility methods consisting of calls to .NET BCL methods that take one line of code – methods that could have been called inline without even the need for the “helper” classes. I’ve seen frameworks that duplicate code that is already present in the .NET Framework, usually because the developer didn’t know they already existed (e.g., writing your own “connection pool” when the providers already expose a perfectly fine one). I’ve seen frameworks with layer upon layer of interfaces, base classes, derived classes and convoluted, multiple code paths that are inefficient and slow down execution because the developers kept building and building on top of something t...

The government's view of the economy could be summed up in a few short phrases: If it moves, tax it. If it keeps moving, regulate it. And if it stops moving, subsidize it.  - Ronald Reagan This has become a personal pet - peeve of mine, having been in various developer groups using the .NET platform since 2001 (ancient history, to be sure -- at least by Internet standards). When I write a class library, if there is even the HINT that it may be used by other developers (or  -- even by me myself at some later date) I've learned to produce decent documentation in the standard XML comment format that has been available in .NET since the very first BETA 1.0 was distributed at the Orlando PDC (Professional Developers Conference) in 2000.  Here's the "thing": as you progress in your career as a professional .NET developer, you'll learn to produce libraries and classes of useful code that you'll use again and again. The idea is that as you gain more and more...