... and the About Visual Basic GOB (Glossary of Buzzwords)

In the spirit of "Life is short, eat desert first!" - here are the facts:

In Las Vegas at the Bellagio
April 12 - 14
Also featuring DevConnections Conferences on ASP.NET, Silverlight, and SQL Server

Microsoft has been partnering with a leading conference organizer to do these things of late. Visual Studio 2005 was held at the Los Angeles Convention Center and was organized directly by Microsoft like previous launch events. But early in 2009, a Microsoft Developer Conference was held "in conjunction with" VSLive in San Francisco. It was actually organized as two conferences held back-to-back in the same hotel. This time, Microsoft is working with DevConnections and it's three conferences held in parallel. The first, of course, is the official launch of Visual Studio 2010.

I'm always impressed at the Rich, Massive, and Agile flowering of buzzwords at these events! If your vocabulary is missing a crucial buzzword, you can miss a lot of meaning in a presentation. So, as a public service, I've started providing a "Glossary of Buzzwords" (GOB) for each event I cover. It's designed to be a downloadable resource and a good read at the same time because I've tried to include some of the flavor of the technology as well as definitions. You can download the GOB to your BLAPER (Buzzword Lookup Assisted Personal Electronic Resource) and search for the buzzwords whenever you need them. (It's just a simple zipped HTML file. Unzip to a folder on your BLAPER and drag DevConGloss.htm to the browser of your choice.)

Download the About Visual Basic GOB

Ummmmm ... Maybe

An About Visual Basic reader, a doctor in a hospital, recently sent an email asking about selling a program she and her husband wrote to make her job easier. "The hospital I work at has very specific requirements for progress notes." She seems to be in a great position because she said, "We are being asked to sell it and haven't a clue as to how to determine its true worth. Obviously we want to make some type of profit from it, and at the same time, we are reluctant to name a price as we want to be taken seriously and don't want to be taken advantage of. There is little competition out there as this program is custom made."

I'd like to have that problem! Gee! How much should I demand for this code I never planned on selling in the first place?

This is a great example of why organizations hire programmers. One size almost never really "fits all". The flip side of that same reasoning is that the custom size you have created isn't really going to fit anyone else perfectly, either. This particular program might not be marketable in its current configuration.

If you already have a willing buyer, the most important consideration that I can think of is making sure that this isn't just a tarpit lightly covered with nice leafy green money waiting to trap you. I would worry more about an iron clad "Don't blame me if it doesn't work for you." clause in the sales contract. At a bare minimum, you should have a clear statement of what you will do to fix it. (And how much it will cost the buyer.) Most organizations have a lot of unique wrinkles in their software configuration.

"OH! We use FishNet as our networking software! Works great for us! Yah, they went out of business about twenty years ago but our FishNet just keeps plunking along!"

Be prepared to hear that it's not quite right because half of it disappears when they send it over FishNet. Custom demands are the Escherichia coli of the software biz.

Anybody else have any advice for Ms. Doc?

Is there a "tension"? What do we do about it?

As part of a project I'm working on, I ran across this statement in the Microsoft Architecture Journal from authors Donald F. Ferguson, Dennis Pilarinos, and John Shewchuk:

---------------------------

End-user programming is an extreme case of opportunistic development, which occurs in departments and Lines of Business (LOBs) in enterprises. LOBs and teams often build simple, "quick and dirty" SharePoint or PHP applications that solve an immediate business problem by extending packaged applications or enterprise-wide core applications.

Opportunistic development contrasts with systematic development. Systematic development is model-driven, replete with requirements gathering, use cases and stakeholder interviews, an application development life cycle that includes quality and assurance, and so forth. Systematic development is the predominant model of the enterprise development team ("the CIO team"). Many packaged application developers (independent software vendors or ISVs) and Systems Integrators (SIs) also produce systematic solutions.

There is a tension in enterprises between opportunistic development and systematic development. This tension will increase if end-user programming becomes common. End users will not be content to wait for the systematic development teams to develop or modify solutions.

---------------------------

The authors (of course) go on to describe how their solution makes it all better and makes the problem go away. In my experience, there is more than just tension; there is outright warfare.

To some degree, many of Microsoft's products are tailor-made for "opportunistic development". These are products like the VBA language in Office products and Visual Basic itself. But Microsoft seems to be tilting toward systematic development these days since many of their products simply have to be implemented through a fairly substantial and long term development commitment. I've criticized VSTO - Visual Studio Tools for Office, the .NET replacement for VBA - because it seems to be positioned and packaged so that nobody except a career programmer in "the CIO team" would be able to convince their boss to buy it and seems to wall out all of the "End-user programmers" who use VBA now.

Is there tension in your organization? What are you doing about it?

How to determine whether a property is a WPF "Dependency Property".

A property must be a "dependency property" for a lot of WPF operations. But how can you be sure which ones are and which are not? This quick tip gives you a quick way.