Windows Live Writer Beta 2 Now Available

The last Windows Live Writer blog post was dated November 21 10:41 AM. That is until yesterday, May 30 2:59 PM, when they announced a new beta was being released (Windows Live Writer Beta 2 Now Available). I haven't had a chance to try it out yet, I just found out about it, but I am looking forward to it.

The big question is why did it take over 6 months to update their blog much less to just release another beta? Is this project just one guy working on it in his (or her) spare time? Or is this a serious project that Microsoft is committed to? It would be nice to know the answer to this question so I can properly set my expectations.

One of the new features that I'm looking forward to is the support for Blogger labels. Currently I have to edit my blog post in Blogger after I've posted it using Live Writer in order to apply the labels. This is problematic for a number of reasons. One, it's a pain. Two, I often forget. And three, it messes with my web tracking.

I will definitely be posting a review after I've had a chance to play with it. Stay tuned :).

New Browser Stats

The last time I posted browser stats (back in January, Browser Wars), Firefox was in the lead by a fairly healthy margin (Firefox had 57% followed by IE at 37%). New stats shows that IE has regained the lead (please remember that this is a developer blog so these numbers are not representative of the Internet as a whole).

1. Internet Explorer - 53.49%

2. Firefox - 40.37%

3. Opera - 3.54%

4. Safari - 1.35%

5. Mozilla - 0.62%

6. Mozilla Compatible Agent - 0.31%

7. Camino - 0.21%

8. Netscape - 0.10%

VB.Net Vs. C# (part 2)

Anybody notice that .Net is very similar to our political system (USA)? It's essentially a two-party system where the parties (in this case VB.Net and C#) are substantially the same. There are some 3rd party candidates, such as J# or IronPython, but they don't have enough support to be taken seriously.

Even though the language are so similar, people get very passionate about their language of choice and argue at great length over minutia such as case sensitivity. Not that there is anything wrong with discussing the pros and cons of such language features, however, in the end, both languages are fairly equal in their ability to accomplish the task at hand and in the level of productivity they allow.

Personally I'm glad that there are multiple competing languages. As an example, look what happened with the browser wars. Netscape owned the market only to lose it to Microsoft due to some great innovations. Once MS owned the market, they stopped innovating and we were stuck with IE6 for years. Along came Firefox which started gaining enough market share to get the attention of MS and suddenly we have IE7. Both Firefox 2 and IE7 are great browsers, but imagine what would have happened if Netscape never faced any competition. Would we still be stuck with Navigator?

Although the two primary .Net languages (C# and VB.Net) are both developed by MS, they still compete (for professional pride if nothing else) and we still get to take advantage of the benefits of that competition.

The 3rd party languages are also valuable for competition and experimentation. For instance, dynamic languages seem to be getting somewhat popular again. There has been a lot of talk about Ruby lately, Microsoft even announced they were going to support a version of it for .Net called IronRuby. We can already see some of these dynamic language concepts finding their way into the mainstream languages, for instance, anonymous methods, LINQ, extension methods, lambda expressions, and anonymous types (many of these are coming in .Net 3.5 due later this year or next).

Thankfully this two-party system doesn't include national elections. People are free to pick whichever language suits them best. Of course, you might still end up with elections at the local, project team level, but if they pick a language that you really don't like, you can probably find a new job without having to leave the country :).

VB.Net Vs. C# (part 1)

Jeff Atwood from Coding Horror wrote a blog post the other day about C# and some of the deficiencies in the IDE, specifically the lack of automatic background compilation (C# and the Compilation Tax). The comments were very interesting. I love the fact that there are so many people out there that are passionate about development, but sometimes I find it a bit strange what they choose to debate.

I develop in both VB.Net and C#. I spend most of my time in VB.Net because that is the language that the company I work for chose (prior to me getting hired) due to their experience working with Visual Basic (VB6 and VBA). Before I went to work for them, I worked at Microsoft (as a contractor) on a C# project. I also do all of my own personal development using C#.

For all intents and purposes the languages are the same. They are both based on the same libraries and can accomplish the same tasks (perhaps with a couple of minor, mostly esoteric, exceptions). They both compile to the same bits and can easily work with one another when needed. If asked which language I prefer, my answer would probably depend on my mood at the time :).

For the most part, I think VB.Net is a better language, especially when working with events. C# forces you to write far more code into order to create or use events than VB.Net and using the handles keyword in VB.Net really makes removing event handlers easy. I also appreciate the background compilation and case insensitivity of VB.Net (as long as the auto-correct feature is on). I also like optional parameters, as long as they are used judiciously, and the greater flexibility of the Select statement over the C# equivalent switch. Other things I like about VB.Net is that I only have to declare the root namespace in the project settings which means I only have to declare a namespace if I am adding to it.

Of course, C# has some nice features as well. My favorite is that the language is designed to be terse. It also is closer to the underlying MSIL than VB.Net which means that when you write code in C# you will have a better understanding of what is going on behind the scenes (I am always having to explain how events work to VB.Net developers, I think most of them think it's some sort of magic). C# also has anonymous methods and coming in .Net 3.5 are automatic properties.

It seems that if you are working on a LOB (line-of-business) application and want maximum productivity, you should stick with VB.Net. If you want to learn .Net then C# is definitely the language for you.

However, I doubt that the productivity gains from using VB.Net are truly significant when compared to the overall schedule of any software project. I spend far more time eliciting requirements, designing, meeting, testing, etc then I do actually writing code. So in the end, personal preference will probably prevail. Of course, the whole team should be in agreement over which language a particular project should use. Just because it's possible to mix multiple .Net programming languages for a software project doesn't mean that you should.

Software Usability

I remember playing bumble-bee soccer (see footnote below) when I was a young kid. I was never around the ball, I was always looking for the position that needed to be filled, usually somewhere between the swarm and the goal. When I look back at most of the activities that I have been involved in, I see the same pattern being repeated, I always look for the most important task that is being neglected. Sometimes that has meant stepping on somebody's toes, other times I have been seen as a savior :).

Within the last couple of years, I have become more and more interested in software usability. Based on my soccer experience, this is probably because the company I currently work for has never concerned themselves with usability (or rather, the CEO and president were the usability experts, period). We never did usability testing, other than a demo to them. In fact, we never even bothered having a review process to make sure areas with similar functionality functioned similarly. Within the last year we were purchased by another company that alleges they are more focused on supporting existing customers than on attracting new ones (the difference as I understand it is more focus on the user and less on a feature checklist).

In my career I have come to the conclusion that most software sucks. In fact, it seems that the quality of software is inversely proportional to the price. Although the field of software usability is not new, it doesn't seem to be getting as much attention as it should (what could be more important than the user interface?). The benefits of creating usable software are well known. For the end user the benefits include increased productivity, reduced training, improved data entry accuracy, and reduced anxiety over fighting with bad software to get the job done. Their are also many benefits to the software company such as increased sales (to both new and existing customers), ability to charge a premium for the software and/or service, and decreased customer support costs. Although there is a cost to usability (you have to commit to it as a company, train developers, testers, and managers, and perform some type of usability studies which should include talking to real customers), based on what I believe to be true (from reading and limited experience), the benefits seem to far outweigh the costs.

I have recently read the book The Design of Everyday Things by Donald Norman. This seems to be the beginners handbook of usability. It lays the groundwork for understanding usability from a designers perspective. Although Donald is an academic (professor of cognitive science at the University of California), the book is well written and understandable even for those without a PHD. The book was originally published in 1988 and was recently reprinted with few modifications. One of the things I enjoyed most when reading his book were the predictions he made, some of which have come true already and others we still have not reached yet. If you are interested in learning about usability, I would recommend starting with this book.

The next book in my queue is The Usability Engineering Lifecycle: A Practitioner's Handbook for User Interface Design (Interactive Technologies) by Deborah Mayhew. This book is a bit larger and seems to go into a lot of detail on how to actually do usability. Of the few pages I've read so far, it seems like a good book :). Of course, I also read many different blogs that frequently include posts on usability. One of my favorites is Jeff Atwood's blog, Coding Horror. Jeff writes often and well and has become a minor celebrity within the software industry for posts such as The Programmer's Bill of Rights. He frequently writes posts on software interface design and usability and has a number of people who comment on his articles. He has also been featured on some popular (for developers anyway) net casts such as .Net Rocks.

Bumble-Bee Soccer - When young children play soccer, it resembles a swarm of bees around the soccer ball.

Team Foundation Server is Cool, but a Bit Underwhelming

I had the opportunity to evaluate Microsoft Team Foundation Server (TFS from here on) over the last week and I have to say, I'm not as excited about it as I was before. Don't get me wrong, I think TFS is compelling, it's got a lot of great features and they seem to be very well integrated with one another and with Visual Studio. However, it seems to be suffering from an acute case of versiononeitus (though I don't think it's terminal).

My main object was to evaluate the Team Foundation Build (TB from here on) for our product. TB is based on MSBuild. Anything you can do in MSBuild you can do in TB. As far as I can tell, TB is just a way to start a remote MSBuild process and report the results. It is well integrated into the IDE which makes it easy to know the status of the build at any given time.

Unfortunately, because it is based on MSBuild, it is very difficult to configure. MSBuild is a very powerful build system, however, it is not exactly simple to understand. For companies that have a full time, dedicated build engineer, MSBuild is probably great, otherwise, it is difficult to learn and it's easy to forget if you don't use it often (we tend to update the build process about once a year or so). I was not able to find a tool that would allow me to configure an MSBuild project, hopefully somebody is building one.

I have a love/hate relationship with the version control (VC from here on) in TFS as well. It has some very nice, advanced features that are missing from VSS. One of my favorites are shelves. A shelf is a place to put code before it is actually checked in. Other developers can access the shelf if they want (which is great for buddy testing).

Unfortunately, it is lacking in some basic usability features. For instance, depending on context, there are many different menu options that can be disabled and it's not always obvious why they are disabled. If you are used to VSS, trying to figure out how to create a directory in source control can be very frustrating. I think you have to map a workspace (which is similar to working directories in VSS, but slightly different), but it took me a few days to figure that out (and I'm still not sure if that's it or not). If this is the case, why do they have the menu option disabled? Why can't I just map a workspace when I'm creating the directory?

One of the nice things about VSS is that the directory structure in VSS does not have to match your directory structure on your local machine. Our VSS structure at work tends to be a bit deep for the local machine, so we map a couple of different VSS directories to the same directory on the local machine. When I tried to do that with VC, it refused to allow me to do that.

I did not evaluate the issue tracking, but I did glance at it. It certainly seems to be a much better issue tracking system then the one we're using at work now (it's a home-grown system).

If my company was more willing to spend a lot more time and money on TFS, I'm sure I would be able to get it working to suit our needs very well, however, they're not. I had about a week to evaluate it and put something together that would be functional.

Overall, I really like TFS. There are many products on the market that do similar things and are well integrated, however, none of them seem to do everything (most of them miss the build aspect). I am really looking forward for version 3 (the magic number in software) of Team Foundation Server.