IE 8 Browser Privacy, the Death of IE 6, and Thrashing

For over a year and half I've authored many WinDevPro Updates as your DevProConnections mentor. My goal is to provide you with valuable advice, content, or insights that will make you a better developer. Based on the feedback I've received on articles about problems with browser privacy, the continuing difficulties of dealing with Internet Explorer (IE) 6, and the challenges of life as a software development consultant it’s clear that these issues have resonated deeply with you. Today I want to revisit a few of those hot topics with some additional insights and information that I hope you’ll find beneficial.

Nearly a year ago I ranted about browser vendors playing a game of FUD when it comes to security and privacy. I also touched upon the notion of data collection and privacy as well: I don't care if businesses collect information about my browsing, purchasing, and other habits— as long as they don't tie that information back to my actual identity. Some of you let me know your feelings, and a lot has changed in the last year. But I recently read a very logical article (How 10 digits will end privacy as we know it) on data collection and privacy that sheds some powerful light on how privacy will morph over the next few years. It's a great and quick read—and highly applicable to those of us who work in information technology.

About a month ago, I mused about a future free of IE6 and what that would ultimately do to the browser landscape. Feedback that I received included support for my hatred of IE6 along with skepticism that we'd never get rid of IE6.

After writing that article I encountered a great new site: www.IE6NoMore.com, which is actually trying to do something more than just complain about IE6. In addition to pointing out why IE6 is outdated on the home page, IE6NoMore.com also provides some very easy-to-use code that developers can put into their own sites and pages to let visitors running IE6 know that they're using an outdated browser. More importantly, the notification displayed to visitors gives them links to download FireFox 3.5, IE 8, Safari 4, or Google Chrome. This approach may not do much to dent the potentially large number of users who are on IE 6 intentionally (though some could end up doing side-by-side installs of FireFox), but  it will help educate users of IE6 who have no clue that there are better options available to them.

Of course, Microsoft has also addressed the increasing pressure to retire IE6, and a blog post (http://blogs.msdn.com/ie/archive/2009/08/10/engineering-pov.aspx) by Dean Hachamovitch of the IETeam points out that there's really no way that Microsoft can effectively just pull the plug on IE 6 because it's a core part of Windows XP. Sadly, that means that IE 6 is officially going to be with us until 2014—when XP is officially slated to be retired. Had Windows Vista done a better job of converting larger numbers of corporate users away from XP, the fate of IE 6 might have been different. And only time will tell if large numbers of corporations see any benefit to switching to Windows 7—though there are some, initial, encouraging signs. The sad truth though, is that while it would be great to be rid of IE 6 once and for all, we're all probably saddled with supporting it for quite a while unless something aggressive is able to change the landscape.

Without a doubt though, one of the biggest sources of feedback was the Update I authored about a failed software project that I completed near the beginning of 2009. I'm still licking the wounds to my ego at this point, but I was glad to get lots of great feedback and even words of encouragement from readers about the lessons I'd shared.

Interestingly enough, I recently gained some great insights into what else went wrong with that project while watching a great video with Seth Godin about Quieting the Lizard Brain. In this video, Seth talks about the difficulty of realizing dreams and ideas; he equates delivery and success with the ability to ship products on time. He then leverages some great wisdom from the folks at 37signals about how to ensure that you ship on time while dealing with “thrashing” (which I called design-by-committee).

So, for those of you out there looking at software, project management, and ways to avoid feature creep or derailed ship dates, I'd recommend watching Seth’s video presentation Seth's video presentation, and then looking very seriously at implementing the pre-project thrashing and sign-off processes he outlines in order to remove the negative effects of thrashing from your own projects.

On a related note, I've also come to believe that my experience as a consultant played a big role in why I failed so miserably as a contract software developer. And, since the few WinDevPro Updates I've written about consulting have resonated with readers, I'll close this Update by expounding upon this seeming dichotomy a bit more. Specifically, I think that the biggest enemy to contracting, software development, and project management is thrashing. Yet, when it comes to consulting, thrashing is actually a primary goal and indicator of success.

Stated differently, the best value I provide to my consulting clients comes from thrashing. Whenever they have a problem with a project, performance, security, or their environment it's because of something they haven't adequately experienced, mastered, or dealt with. Accordingly, as a consultant, it's my responsibility to watch for that subsequent thrashing, identify it, and impart additional background, understanding, guidance, and experience in order to help them best attack their own problems going forward. In other words, my focus as a consultant isn't so much on getting things done as it is on helping my clients get things done. The value I provide actually stems from helping them when thrashing occurs and where they need additional opinions, insights, and options. And in order for me to provide that value, thrashing needs to occur.

But that's the complete opposite of what you need when you're a contractor. Yes, contracting still requires thrashing. But it shouldn't be the focus of contract work, and steps need to be in place to minimize the impact of thrashing as the project proceeds. What I learned was that to be successful I need to distinguish between a consulting and contracting mindset (and put adequate safeguards in place) so the .project can ship on time.

I hope that my explanation of the differences between contracting and consulting will help any of you interested in going into consulting yourselves. Or, perhaps, it could help any of you considering bringing on either a contractor or consultant to work on your project.