As the saying goes, there are two main problems to address in development: naming things, cache-invalidation, and off-by-one errors. As such, I wanted to do a shout-out for a recent problem that Scott Hanselman raised on his blog—because it's something I feel very passionately about, and I'm assuming that other developers feel similarly.
My Technical Crush on Scott Hanselman
Blogging is seriously hard work. Consistently posting content that readers find helpful and engaging is a tall order. To that end, I'm convinced that one of the best blogs in our industry (i.e., developers using the Microsoft stack) is Scott Hanselman's. He consistently provides content that both informs and inspires. Scott has a way of constantly "challenging" developers to be better—because of his passion for technology and because he's such a knowledgeable technical bad-ass. Similarly, even when Scott is grappling with a tough or problematic issue in one of his posts, he always ends up taking a positive, results-based, approach that amounts to doing more than just complaining (something I hope to aspire to some day).
Which brings two things to mind: First, if you're somehow reading this article and aren't subscribed to Scott's blog, then you're missing out. Second, is that one of the smartest things that Microsoft ever did was to hire Scott as part of the Developer Division. Because, simply put, Scott is one of us. He's been in the real world, he's worked in development on real-world solutions, and he's grappled with what's awesome and not awesome about the .NET Framework along with all things Microsoft that pertain to .NET development, .NET deployment, and .NET management.
Consequently, not only did Microsoft get access to Scott's regularly honed presentation skills and natural passion for teaching developers about new technologies and paradigms in captivating fashion, but they also picked up a passionate developer who's "been there, done that" and who is eager to provide Microsoft with feedback and input from the developer community at large.
Scott's Call to Action
All my awkward gushing aside, Scott recently raised a call to action for developers on his blog about some recent naming conventions for upgrades to the .NET Framework coming out of Microsoft. Specifically, his post "Request for Comments: Issues with .NET and Microsoft Product Versioning" focuses on recent additions and updates to the .NET Framework that are coming out of Redmond with absurd names like the following:
.NET Framework 4 Platform Update 1 (KB2478063)
EF 4.1 Update 1
True to form, Scott not only does a great job of enlightening readers about how these recent releases were named more or less accidentally, but he also then earnestly seeks feedback on whether or not this is as big of a problem as he thinks it is.
But rather than summarize his post, I'll let you go read it. In fact, I'll wait until you get back—because it very succinctly outlines the problems, points to some obvious and logical solutions, and then asks for input from developers.
If you look at the comments, you'll see that .NET developers all feel pretty much the same way—meaning that we really don't like these new, non-intuitive, names. In fact, I don't think anyone has really summed up how rabidly I feel about this whole affair as well as Hadi Hariri (a member of the ReSharper team and a consummate .NET developer), whose post made it abundantly clear that he prefers a simpler, logical, major/minor approach to versioning.
Confusion Is Only the Beginning
As I see it, these names aren't merely just dumb and confusing. Instead, they're going to make application deployment and versioning that much more difficult (which seems like the last thing any rational person would want). Stated differently, which would be easier to target for deployment: .NET Framework 4.3 or .NET Framework 4.0 with Platform Update 3, Entity Update 2, WCF Security Endpoint Update 2, and Service Pack 1?
The other thing that bugs me about these new, accidental names is that they're going to make it that much harder for .NET developers to advocate for the Microsoft stack with development efforts. And while that sounds a bit extreme, I'm convinced that if Microsoft keeps up with these goofy naming conventions for additions, we're going to see numerous cases where developers will build "latest and greatest" solutions on the .NET Framework only to see IT pros and sys admins get quite cranky about how costly, ugly, and finicky the .NET Framework is to deploy, maintain, and manage. And that is to say nothing of the field day that zealots for other platforms will have when discussions about which platform to use for new development efforts crop up.
For Developers' Sake, Simplify the .NET Versioning Model
In some ways, it might seem almost petty of me to spend so much time on something as simple as versioning and naming. But from my perspective, I was very happy to learn that these latest releases were named effectively by accident—rather than as part of some idiotic new initiative to come up with the most confusing and idiotic names possible.
Consequently, if anyone at Microsoft stumbles upon this article, I'm hoping that they take two things into account: first, that Scott Hanselman is a great asset and really does have the ability to speak accurately for developers (because he is one, because he's constantly interacting with them, and because he regularly solicits their feedback), and that .NET developers really do want a normal major/minor versioning model that keeps aspects of the .NET Framework simple to manage—both mentally and logistically.
Michael K. Campbell ([email protected]) is a contributing editor for SQL Server Magazine and a consultant with years of SQL Server DBA and developer experience. He enjoys consulting, development, and creating free videos for www.sqlservervideos.com.
