Dan Appleman: Kibitzing and Commentary

A group of VB MVPs recently signed a petition regarding the future of VB6 . I thought I’d take a minute and address some of their issues. I myself am a VB MVP, and have chosen not to sign at this time because I disagree with the recommendations listed in the petition, but not the objectives.

First, consider the objectives of the petition:

1. Preservation of assets
2. Continued support for the Visual Basic language
3. Ease of migration of unmanaged VB/VBA code to VB.NET

If you have a business that has invested years of development effort in VB6 and VBA code, should you port that code to .NET? We�re talking existing working code here - not new projects. By any sane economic rational, the answer is no. In most cases porting is stupid and a complete waste of money.

The rational way to migrate to .NET is incrementally - using it for new development and porting selected components that can truly benefit from the .NET framework, relying on interop to allow existing code to work with .NET code.

The problem, if not tragedy, is that many developers are porting code to .NET purely out of fear - fear that they will no longer be able to receive support for VB6, fear that existing VB6 projects may not run on future operating systems, fear that they will not be able to obtain VB6 licenses.

Microsoft, perhaps in its desire to promote .NET, has not done enough to assuage these fears. Either they value .NET migration more than the best interests of their customers (which would be shameful), or they are just not able to get the message across. Porting is stupid (for proof  - ask what percentage of the MS Office code base has been ported to .NET).

The classicVB petition recommends integrating some future VB6 into the Visual Studio IDE. I think this approach would be mistaken and a waste of resources.

I would like to offer the following recommendations as an alternative:

1. A longer term commitment to providing support for VB6 and VBA
2. Guaranteed support for VB6/VBA under future OS’s for an extended period (definitely including LongHorn and at least one more beyond).
3. A commitment that once a decision is made to stop support on VB6/VBA, that the entire VB6/VBA code base will be placed into the public domain as an open source project, or perhaps a foundation similar to Mozilla, to assure that interested parties can continue to support and perhaps fork the project in the future.

I believe these alternatives would provide sufficient peace of mind for most VB6 developers to base their migration plans on sound economic factors relating to their individual situation - and not on fear, uncertainty and doubt.

Links:
Petition
Scobleizer (who blogged the petition under the “revolt” moniker, even though it isn’t)

It’s a rare conference that doesn’t include at least one (dozen) “best practice” sessions. A search on Amazon.com found 166 computer books with “best practices” in the title, an astonishing 2500 that have “best practices” somewhere in the description.

What are best practices? When you come right down to it – they are for most people a shortcut to expertise. The knowledge base required to be a professional software developer today is huge. To be a good one, even greater. Learning programming and a language or three is trivial, and just the beginning. There are also the tools, for both development and management. The platform you’re coding to (.NET framework, Win32 API, etc.). The services you’re using (web servers, databases, etc.). Each of these has to be configured. Most have their own languages as well (I just finished a project that required me to simultaneously program in VB .NET, C#, Regex, Javascript and SQL).

And the knowledge base is a moving target – every year or two it changes, grows and becomes more complex (sure .NET 2.0 twice as good as 1.1 – there’s twice as much to love, and learn.)

We can’t know it all. We can, if we’re very lucky, learn those parts of it we need to solve the problems at hand. If only an expert could come along for each of these technologies and teach us just what we need to know – being sure to include those “gotchas” learned through harsh experience. In other words – “best practices.”

Sounds good, right?

The problem is, those best practices can come and bite you. Because the phrase “best practices” is misleading. It’s incomplete.

The correct phrase is: “Best practices for solving X class of problem”

“Best practices” are always associated with a particular set of scenarios. And if you don’t know those scenarios, you can be in deep trouble. Because best practices for one scenario can quickly become worse practices for another.

Case in point:

Imagine if you will, an ASP .NET web application. Everybody knows that it’s a good thing to reduce round-trips to the server. Most ASP .NET “best practices” emphasize techniques to reduce round-trips and reduce network traffic. Like spitting out client side script for validation and to handle some of the user interaction. Like turning off viewstate where possible.

And you know what, those are all good recommendations.

Unless…

Imagine this ASP .NET application has section, say maybe half the site, that is very rarely used. Maybe it’s for administrators only. Or maybe it’s used rarely, say to view 1099 forms at the end of the year.

Coding a web application that makes heavy use of client side scripting is hard. It’s hard to develop. It’s harder to debug. It’s harder to maintain. It costs more. It turns out that for low traffic portions of a site, those performance “best practices” are actually worse practices. They cost a lot, and no one may ever notice the benefit.

I’ve seen projects like that – where developers follow the “best practices” recommended by Microsoft or experts, only to come up ultimately with brilliant implementations of flawed architectures. Best practices are not a substitute for understanding the fundamentals.

So next time you attend a talk that promises to teach you best practices, or read a book with that in the title, be sure to take a minute and ask “best practices for what kind of problem?” Because if it’s not your problem, chances are you’re about to be led astray.

Joel Spolsky has an interesting discussion on his site in which he challenges the Microsoft Solution Framework (if not software development methodologies in general) using the Hebrew terms “rosh gadol” and “rosh katan” to describe the characteristics of two types of developers.

While I would hesitate to try to translate the two terms (I think Tamir Nitzan does a much better job than I could), I thought I’d share my own way of looking at it. Though it may be a bit of an over-generalization, when it comes to approaching a task there seems to be a spectrum.

On one end you have the individual who solves problems. When they have a task or goal, and run into obstacles, they will solve them, overcome them, bypass them, work around, above or right through them, even if it means redefining the problem to do something just as good or better than the original task or goal. These people would, I think, be Joel’s “rosh gadol.”

On the other end of the spectrum, you have the person who stops at the first excuse. In other words, as soon as the individual as a justifiable reason to stop looking for a solution, they are finished. While this can be intentional (Joel’s example of a “work to rule” situation applies), it is more often just part of their nature. These would be the “rosh katan.”

There are, sad to day, a lot more of the latter than the former.

And this also supports Joel’s assertions regarding software methodologies. A true “rosh gadol” won’t actually be suppressed by a restrictive methodology – he or she will likely solve their problem by finding a better company to work for. A “rosh katan” won’t have trouble with it either – as the more complex a methodology is, the more opportunities there are to find excuses (uh, the additional 3 week project delay was caused by the requirement to review and rename every local variable to have camel casing…).

Of course, this isn’t just applicable to software development. It’s part of the human condition. In fact, I strongly suspect that this is part of one’s character that is formed when very young, because I don’t know of any reliable way to convert an adult from a “rosh katan” into a “rosh gadol.”

I’m pleased to announce the publication of my latest eBook “Visual Basic .NET or C#: Which to Choose (VS 2005 edition).” Based on VS 2005 (Whidbey) beta 1, it is a major rewrite/revision of the previous VS 2003 title, based not only on changes to the two languages, but on the evolution of .NET in general.

Available from Desaware, Amazon.com and Lockergnome

Now that we have reached the home stretch of the political season, the chance to actually vote on something… and the prelude to what is likely to be an extended and painful period of lawsuits, recounts and recriminations for one side or the other, it’s time to look ahead at what we can do to occupy our spare time for the few months until the next election cycle begins.
Fortunately, there is an ongoing contest that is quickly becoming just as extreme, just as polarized, and just as lacking in honesty as any political contest we’ve seen yet. Yep, it’s the good old closed vs. open source debate.

This is prompted by a couple of friendly messages I’ve received lately. The first sent by a good friend is an presumably objective report in the Register comparing the security of the two systems.

The other, an email from my good friend Steve Ballmer (who I’ve never met, but have seen from a distance at a technical conference or two), containing six pages (2700+ words) extolling the benefits of Windows over Linux in every possible way (including, of course, security, with an indirect reference to a study by Forrester Research).

Now, the Register article seemed to me well researched, but it’s pretty easy to see that despite the innocuous title “Security Report: Windows vs. Linux”, the piece is clearly advocating the Linux side. Let’s face it, an objective report is unlikely to have it’s first couple of sections titled “Myth: There’s Safety In Small Numbers” and “Myth: Open Source is Inherently Dangerous.” Still, it makes for a fascinating read, and the author’s arguments are based both on technological reasoning and hard statistics – not the anecdotal evidence so common in white papers and political campaigns.

I’m afraid this time the “Swift Boat Veterans for Truth” spam of the year award has to go to Ballmer’s letter. It was just too easy to see the spin. My first hint came with the name dropping – while reading the list of customer case studies I couldn’t help but see Kerry in his second debate name dropping an endless list of senators and generals. I also found Ballmer’s choose Windows because “being on the wrong end of a software patent lawsuit could cost a customer millions of dollars, and massively disrupt their business” argument comparable to Dick Cheney’s “if you choose Kerry the terrorists will attack us” tirade (as a technologist, the idea of choosing software to avoid lawsuits instead of based on cost represents a huge failure on the part of our industry and society).

Then there’s the security article itself. The MSDN page is headlined “Windows Users have Fewer Vulnerabilities.” Imagine my surprise when I found the actual title of the Forrester report was “Is Linux more Secure than Windows”

Ok, so maybe the MSDN page refers to the conclusion? No – the executive summary of the report concludes: “both Windows and four key Linux distributions can be deployed securely”.

Ok, so do Windows users actually have fewer vulnerabilities?

Well, Windows users do have fewer overall days of risk by their metrics – which might explain this quote. But the study also shows that Windows had the highest percentage of high-severity vulnerabilities.

I’m not going to try to guess which system is really more secure. I don’t have time to reconcile the methodology of these two reports (the Register report found that Windows had more vulnerabilities). Which brings me to my greatest frustration.

With technology advocacy and marketing becoming as polarized as a political campaign, who can we look towards to be honest brokers? Even non-sponsored objective reports are inevitably influenced by the biases and backgrounds of their authors, and their results spun by each side.

On one hand, I truly sympathize with anyone who actually has to make a choice between platforms. Between the lack of trustworthy information and the flood of marketing noise, the chances of being able to truly choose the best one for your situation are slim. On the other hand, perhaps there is good news after all. Both platforms work, and can be secured. Cost studies go both ways, but few of them seem to claim a real difference in total cost of more than 20%, which is probably well within the margin of error when calculating the cost of a large scale platform deployment anyway.

So if the two approaches really are comparable in cost, and security, maybe the right answer is to choose based on a more arbitrary standard, like which name you like, or which fits better with your personal politics, or maybe the roll of a dice. Who knows, the money you save by not studying and comparing and analyzing the choice may be more than the ultimate cost difference between Windows and Linux.

In my recent blog “Spolsky 1: Scoble 0 – Stegman’s Video, while Great, doesn’t apply to the API war” the most surprising results were in the responses. While many did address the focus of the item (that of API changes), there were a number of responses directly relating to Windows Forms as a technology. Recently, Mike Harsh elaborated on this topic as well. Clearly there is interest in where Windows Forms fit into the greater scheme of things. I think this is worth of further discussion.

It’s possible Mike may be too conservative about the future of Windows forms. Curiously enough, the very issues that Joel brings up with regards to the API war actually work in favor of Windows Forms. You see, even though Windows Forms is a managed wrapper for User32, the key point is that it does wrap User32 – the old Win32 GDI API that every Windows developer in the world is familiar with.

So here comes Avalon – a new approach and new API. Do the features that Avalon promises truly justify the investment in learning this new API? It’s too soon to say. It will likely prove compelling to those developers who really need to take advantage of new UI features, just as the DirectX API is worth learning for those who need that capability, but that may prove to be a minority of Windows developers.

My point is this – you have a huge number of Windows programmers, who grew up and know User32, how it plays with VB6, MFC, ATL and now Windows Forms. Do you really think they’re all going to just jump to Avalon overnight? Over a year? Over 10 years? .NET has compelling advantages over COM, and the transition is proving very slow. There’s every reason to believe that the transition to Longhorn and Avalon (that in my mind are still classified in the category of vaporware) will be as slow or slower. If there is no compelling economic advantage, Windows Forms might be the dominant managed forms package for many years.

Unless, of course, Microsoft abandons Windows Forms, either on purpose, or by implication (say, by failing to make interop work as smoothly as promised on future OS’s).

It’s a tough problem. Technically, I do believe Windows Forms is better than VB6 or MFC. But it suffers from the .NET distribution issue. Even ClickOnce may not change that (a topic I’ll be writing about soon). Avalon will suffer the same runtime distribution issue, plus the additional problems of limited OS support and the need to learn a new API.

I was discussing this earlier today with Christian Gross, and he suggested I take a look at GTK# . I doubt it’s as cool as Avalon, maybe not even as cool as Windows Forms. But I must confess, the idea of a forms package that runs on Windows, OSX and Linux is intriguing. Something to look at… in my copious spare time.

In a recent blog item, Robert Scoble suggests that Joe Stegman’s video on Windows Forms answers Joel Spolsky’s article “How Microsoft Lost the API War.”

Sorry Robert – but it doesn’t.

Make no mistake, Windows Forms is great stuff. Ok, perhaps you hype it a bit too much – that great looking Outlook application that is created with 100 lines of code largely looks like Outlook because it uses an Outlook control. But nevertheless – it’s great.

And yes, Windows Forms will “play” with Avalon. Microsoft’s “Developer’s Guide to Migration and Interoperability in “LongHorn” on MSDN chapter 5 addresses this.

But “play together” in this sense is an interoperability issue. Avalon and Windows Forms represent two different programming models or API’s.

Let me stress the word “interoperability” here. Sure, Avalon can host Windows Forms and vice versa. Just as Windows Forms today can host COM ActiveX controls. But do you know many people writing COM ActiveX controls for use with .NET? No.

Why not?

• Because people are reluctant to trust an interoperability layer, both from reasons of compatibility and reasons of performance.
• Because once Microsoft adopts and promotes a new technology (.NET), they tend to stop development and gradually support on the old one (COM).
• Because psychologically, developers want to play with the latest technology, and managers feel pressure to adopt the latest technology.

Having two technologies that have different API’s have all the costs Joel discusses such as the cost to learn a new technology and the cost to port applications (even when there is no feature, performance or economic benefit in doing so).

With Avalon and Longhorn we are faced with the same process. Sure Windows Forms is being invested in big time. Sure Windows Forms controls will be hosted in Avalon through an interop layer (and vice versa). It doesn’t matter. The same pressures will apply in just a few years to migrate to Avalon. There will be inevitable problems in the hosting, concern about long term support, and pressure in the media and development community to use the latest and greatest thing.

Sure, if you’re writing software with a lifespan of a few years, Windows Forms is a great way to go. But we all know that software, enterprise software especially, lives a long time. Can Microsoft categorically promise to maintain a full commitment to development, maintenance and support of Windows Forms for the next 15 years? (A more typical lifespan for enterprise software). Will they maintain that commitment during at time where their marketing department and media are pushing Avalon and Longhorn?

Do you really want to invest full bore in Windows Forms today given the uncertainty of which technology will become dominant, run on the most platforms, and have the best long term support?

For smaller applications, absolutely. But if you’re going to invest in a large project, this is a very difficult decision, and waiting for Avalon might be the better strategy. It’s too soon to know.

RSS feeds for sites referred to in this item:

Joel on Software
Scobleizer

Let’s start with the obvious. Almost nobody reads software licenses. You know why – they’re incomprehensible, too long, and in cases where you have to use the software anyway, you’re stuck with the license regardless. The only exceptions are the large corporations who have the lawyers, time and money to deal with them. Normal people don’t bother.

Unfortunately, this has some pretty serious side-effects. Aside from the obvious fact that millions of people are in effect agreeing to contracts they’ve never read, one of the common ways that spyware and adware are spread are by having users agree to them without realizing they are doing so.

I think it is time to completely revolutionize the way we deal with software licenses. To do so, I offer the following modest proposals.

• A law should be passed that restricts the length of software licenses for consumer software to no more than 500 words. For comparison: the BSD Open Source license is 225 words, The Claria (formerly Gator) adware license agreement is over 6600 words (15 pages single spaced).
• Software licenses must be written in plain language that can be clearly understood by the average 13 year old.
• Security updates to software may not include any license terms that were not present in the original software.
• No license for released (not beta) software may include any terms that restrict speech, review or benchmarking of the software. For a software publisher to restrict free speech and commentary on their products is shameful and unethical. I do think, however, it’s fair to require that any benchmarks include the source code of the benchmark so people can independently review the results.

My Challenge to Microsoft

As the software industry leader, I call on Microsoft to take the lead in coming up with creative and user friendly solutions to this problem. To start with, try taking the software licensing process out of the hands of your lawyers, and hand it to your user interface people. They’re good, and if they can’t figure out a way to revolutionize software licenses so they work, then we should all go to open source, because the situation will truly be hopeless.

My Challenge to the Government

Yes, I know – asking Congress (which is made up primarily of lawyers) to create laws that simplify license agreements seems like a long shot. But I can dream, right?

How else do you think software licenses need to be changed? Comments welcome.

This week I was quoted in an SD Times story about 64 bit Windows. In it I say:

“Migration to 64 bits is likely to be slow, as is migration to any new technology. What’s more, delays of major products from Microsoft are common, so it’s hard to get excited about them.”

Now, for the record, I was not misquoted. Nor was this taken out of context. However, also for the record, I’d like to include the remainder of the quote that was not included in the article:”

Not only are delays on major products common, but as an industry we would much rather Microsoft take the time needed to “do it right”, and make sure the technology is secure and reliable, than to rush something out the door.
Kudos to Microsoft for having the discipline to wait until it’s truly ready to ship.

Now, on another note. I saw the most remarkable phishing email scam today. The misdirected link was subtle and hard to spot in the message source code, even when I knew what I was looking for. I wrote up a description of this IE specific attack at alwaysuseprotection.com. Visit the page using IE – it’s a trip.

Like many developers, I’ve started the process of getting acquainted with beta 1 of Visual Studio .NET 2005, along with the new versions of both C# and Visual Basic .NET. One thing has become increasingly apparent – Microsoft is effectively abandoning the Common Language Specification (CLS).

If you think back a couple of years when .NET was first announced, the CLS was one of the lynchpins of the .NET message. The idea that every .NET compatible language would be able to work seamlessly with any other .NET language was one of the key innovations of .NET. This meant you could create components in any language, and easily use them from any other – a vast improvement over the previous generation where mixed language development required great care to match calling conventions, parameter count and type, and responsibility for reference counting and memory management.

There is no doubt that .NET is a huge improvement over previous approaches. As a component developer, and someone who strongly believes in software reuse and component based software development, the CLS was gospel. I believed that every assembly should always be CLS compliant (even private code, in the hope that one day it might be refactored into components). Visual Basic .NET 2002-3 produces CLS compliant code by default. C# does not, though it’s not hard to maintain CLS compliance, and the compiler can check for it if you wish.

With Visual Studio 2005 it seems clear that Microsoft has effectively abandoned the CLS in favor of a new standard: specifically – the set of language constructs supported by Visual Basic .NET and C#.

Want proof? Visual Basic .NET 2005 no longer creates CLS compliant code by default.

And you know what? Microsoft made the right decision in this case. Leaving these features out of VB .NET would have crippled the language (both in perception and in reality, though mostly the former – a subject I’ll return to later).

The three major non-CLS compliant features I’ve seen so far are generics, unsigned variables and different access levels for property procedures. All of these are extraordinarily useful features for VB .NET. All will make it easier for VB .NET and C# assemblies to work together.

What does this mean to other language vendors? Can they leave out these features with the argument that they are not necessary because they are not CLS compliant? Of course not – how can you be less than 100% compatible with the two major .NET languages? In effect, VB .NET and C# will define the new de facto standard.

The idea of a common language specification is a good one, and the truth is – they are so close that it’s hard to see this as a big deal. But language interoperability is important – especially if we are ever going to convince developers to truly adopt component-based development. Both VB .NET and C# should produce CLS compliant code by default and require an explicit developer choice to turn it off (just as systems should be secure by default – same concept). But I’m not suggesting they change the default attributes for VB .NET and C# projects. Rather, Microsoft should update the CLS to match the new de facto standard and make that the default setting for VB .NET and C#. This will help vendors of other components and the folks developing Mono to have a clear common guideline to work with, and in the long term ensure that the interoperability promised with .NET does not devolve into an illusion.

Related Articles:
How Microsoft Lost the API War by Joel Spolsky is essential reading to every Windows software developer. Check out his new book.

RSS feeds for sites referred to in this item:

Joel on Software