Musings

Generic or Specific

Bill Sheldon — Fri, 02 May 2008 23:46:00 GMT

This is one of those musing posts and comes from one of the challenges I have when teaching a feature that Microsoft chose to call 'Generics'. I think this name was picked by someone, who while reasonably familiar with English wasn't a native speaker of the English language. Thus they found a definition and thought it applied - allow me to elaborate.

What is a .NET Generic - well in short - under the original implementation of .NET collection classes contained a set of other objects. However, these classes didn't know specifically what kind of object they contained. Instead a given collection might contain more then one different type of object, for example numbers stored in a collection with strings and image objects. It wasn't possible to say thata given collection would contain only a specific type of class.

With the introduction of 'Generics' it was possible to indicate that a given collection would only contain a specific type of object. That's right the feature Generics describes a set of rules and syntax for ensuring a collection is of a specific type. Now the challenge comes from how the definition of generic is phrased in some dictionaries: "Relating to or descriptive of an entire group or class"

Notice that the preceding definition basically associates the definition of a generic with a class. Thus if you were searching the dictionary for a word that described a class - well there you have it. Unfortunately this use of the word "class" doesn't relate to the use of the word "class" in object oriented programming. In this use a class is more of a category of like items - not the definition of a single item.

Webster's Revised Unabridged Dictionary - Cite This Source - Share This

(http://dictionary.reference.com/help/web1913.html)

Generic

Ge*ner"ic\, Generical \Ge*ner"ic*al\, a. [L. genus, generis, race, kind: cf. F. g['e]n['e]rique. See Gender.]

1. (Biol.) Pertaining to a genus or kind; relating to a genus, as distinct from a species, or from another genus; as, a generic description; a generic difference; a generic name.

2. Very comprehensive; pertaining or appropriate to large classes or their characteristics; -- opposed to specific.

That's right the word I most frequently use to describe the feature Generic is the one which defines the opposite of the definition of the word generic....

I don't think Microsoft can really do much about this, it's just one of those things that make you wonder...

The Unofficial, still Plausably Deniable, Future Home of the "San Diego" Chargers

Bill Sheldon — Mon, 21 Apr 2008 14:05:00 GMT

So officially it's not yet an option, after all the San Diego Chargers are still working with the city (suburb) of Chula Vista to keep the Chargers football team in San Diego County. And of course the Chargers spokesman has officially denied it... http://www.sportsbusinessdaily.com/index.cfm?fuseaction=sbd.preview&articleID=120164 (account needed for full article - but the headline says it all)

However, if Chula Vista 'stumbles', one environmental suit or negative ruling in the next two years, and lets face it the Chargers are moving to Los Angeles and this brand new, very fancy stadium. Construction should be ready to begin in 4Q of this year and my guess is if it does and if the inevitable challenges to the Chula Vista site arise - "Los Angeles 'super' Chargers" will be the new theme song...

http://www.losangelesfootballstadium.com/

I easily could be wrong but let's face it if there wasn't already a sequence of events (or perhaps more than one) that would result in a team moving here, this idea would be crazy. Fact is, IMHO that's what you would have to be to think that this isn't the future home of the Chargers. BTW, check out the background color scheme - which NFL team has uniforms in Baby Blue? Heck another story even has Roski on the record as stating that the team moving could play in other LA venues for 2009, 2010 till this place opens in 2011.

A dark day in Title Town

Bill Sheldon — Wed, 05 Mar 2008 14:34:00 GMT

Brett Favre retired... sports pundits (who are of about the same value as political pundits) have spent tons of hot air on the subject and finally get what so many have asked for (a good football story after the Super Bowl and before March Madness) I have to admit I was hoping for something more along the lines of the day Cal Ripken Jr. took himself out of the Orioles starting line-up (and finished out the season). My personal hope was that Brett would 'retire' to the role of backup early in a future season - help the team and Aaron R. along for that year and fill in if needed - since most first year QB's need some help along the way...

So another streak ends, but as I listened to the clip I realized that Brett was in this voicemail also illustrating personal motivation and the role it plays for those at the top of their game. Often people who are put in charge of an organization forget that the best and only real motivator for your top performers are the expectations they set for themselves. Listen to the clip, it isn't that Brett couldn't or wouldn't like to play but that his expecation that anything less then a Super Bowl victory would be a disappointment. Brett recognized what his expectations for performance for the coming year were -which brought him to the conclusion that it was time to leave while he was (based on his performance last year) at the top of his game - plus a team that had a great year.

My remaining question - since Fox broke this story before literally anyone else including the Packers let it out - what is Brett's role when he comes to work for their network? Lets face it they were so sure of the story - it was like well if he hadn't already signed - they were deep enough in negotiations that the deal was considered done.

How about those new Tech money makers...

Bill Sheldon — Tue, 26 Feb 2008 23:17:00 GMT

This is a combination of humor and warning of lessons learned...

Don't Use the Original... Storing the Template in the 21st Century

Bill Sheldon — Thu, 20 Dec 2007 16:13:00 GMT

Many years ago there was a common pattern for Office Workers. Essentially before the true abundance of desktop systems and printers it was common to have a paper form. Copies of this form would be used for any number of tasks (fax cover sheets are a common example most people can relate to) and then when there weren't any copies left you would make a new set of copies. The cardinal sin for the admin staff was of course the person who took the original and used it instead of copying it. Want to really get on the Admin staff's bad side wipe out 3 or 4 originals and they will hunt you down...

At any rate now that we have PC's and easy access to printers the separate set of file folders containing originals hidden from non-admin eyes is pretty much a thing of the past. These documents are typically stored on a central Intranet server like SharePoint. However, in many cases a limited version of the same problem still exists. Now people will take the copy that is on the server and open it for customization. Then without thinking they save that copy and it goes right back to the server. In minor cases they've just poluted the baseline copy that's sitting on the server - but in extreme cases they could so modify the original that its almost useless as the original. The solution of course is to make such original copies read only, except now instead of having them under lock and key in a big old file cabinet - they sit online marked read-only or checked out to the one trusted individual who won't overright them... It's the same solution to the problem, just implemented with 21st century technology instead of physical copies.

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

Sorry for the long delay and somewhat sparse posts over the last few weeks (OK Months) but I've been a little busy with the latest version of the Professional Visual Basic book to go along with Visual Studio 2008 and VB 9. However, I reached a milestone last night - OK theoretically it was early this morning. I caught up with my publisher. I've turned in all my draft chapters and returned all of the edited chapters that were returned to me to date. I'm not yet done because there are more edits that need to be returned to me - of course the fact I turned in the draft late might be impacting that... but for tonight at least I don't have any authoring commitments... except I'm supposed to start that magazine article...

The State of Visual Basic

Bill Sheldon — Thu, 01 Nov 2007 02:06:00 GMT

Often as a new release of Visual Studio approaches there are posts regarding, where are the two primary languages in .NET going? In short as has been noted on one or two places around the net the VB MVPs posed the question of, what is the strategic long term expectation for VB and how is VB doing in the market? Which language should I learn, which will help me get a job? etc.

(The short answer regarding which language to learn is - if you are going to do just a little programming VB is easier to learn and maintain. If you intend to be a Professional Software Engineer and limiting your career to being a full time Cubicle Code Monkey you need to know both. Just knowing C# or VB isn’t enough, as a developer I’ve learned somewhere between one and two dozen programming languages, to be honest I lost track of them all and stopped counting long ago – although interestingly enough I still have my high school ‘Basic’ programming book...sentimental value only - the point being casual developers will be more comfortable in VB and professional developers learn languages and VB and C# are both necessary with .NET today.)

At any rate focusing on the core topic, depending upon where you ‘stand’ your view of VB or C# might be that it’s doing great or not so great. After all if you are working in a shop where your senior management likes C# it might seem like very few people are working with VB.

On the other hand this perception might be a self-fulfilling prophecy for your company. After all if every project uses a hammer then there must be a lot of nails (how’s that for twisting a proverb “if all you have is a hammer everything looks like a nail”) If your company “supports” both VB and C# languages but encourages that new projects use one language well then you begin to wonder. As I noted in the past I’d consider that pretty short-sighted for a consulting company. After all if your goal is to sell software as a service (which consulting companies do) you don’t want to lose a major portion of your market to language bias… so before I go further I want to clarify where I got some of the data I’m about to toss out.

I think it’s common knowledge that I’m an MVP (I can hear some of you: ‘could he mention it one more time…’) anyway I bring this up to note that it shouldn’t be a shock to realize that as an MVP I have a Non-Disclosure Agreement (NDA) with Microsoft. This comes up because as a group we MVP’s have some communication channels (formal and informal) with Microsoft. One of the formal ones revolves around my specialty area Visual Basic.

In this area the VB-MVPs have essentially an opportunity to truly speak freely to Microsoft on NDA topics. It’s where we can say we think that feature A is useless or that we think the VB team has dropped the ball by not having a given feature, or where we think they need to take the ball and really run with it. It also allows us to ask questions and get answers that might embarrass one or more people at Microsoft. In general it is a valuable tool. Every so often we get permission to post some information from that discussion to help frame discussions outside that group – things that aren’t too germane to actual company business, and that’s the case for the numbers I’m about to post.

There are way more people online downloading C# right? Wrong – At this point you aren’t going to be surprised when I say the VB Express is the top download of the Express editions. It probably also doesn’t surprise you if I say that it’s downloaded far more frequently then C++ Express. But does it surprise you when I note that C++ is the number 2 download behind Visual Basic. It surprised me, after all I expected Visual Web Developer to be in the top 2 (after all both VB and C# web developers would use that one tool).

That’s right Visual Basic alone is more popular by a margin of 20% over C++ <credit VB Team>. What I will say is that the other three express editions are all much closer in terms of downloads, and registrations. The point is that Visual Basic is noticeably more popular. Of course this is the Express Edition, that’s for students and hobbyists, they aren’t professional developers.

So how big is Visual Basic when someone reviews the market?

Well according to Forrester research Visual Basic is the #1 .NET language. <credit VB team> Note that’s not some legacy number based on COM developers, that’s just in terms of .NET developers. That’s right the majority of professional developers out there are using Visual Basic, and that even makes sense.

Think about it this way, prior to .NET the two primary development languages were C++ and VB. C++ was far more powerful, but it took longer and cost more to develop applications. Sure for someone developing tools or with a huge install base the disadvantages could be overcome for the power. VB on the other hand was much easier to learn and use, the code was easier to maintain and its performance while not equal to, was certainly comparable to C++.

Along comes C#, from the standpoint of C++ developers C# offers a familiar syntax and reduces the disadvantages of C++ - applications were easier to develop and accordingly cost less. C++ developers and Java developers have without a doubt flocked to C#. In fact if you are a Java developer and haven’t moved to C# boy are you missing out on the future. However, these were smaller developer communities to start with then Visual Basic which also released a .NET version.

Visual Basic also moved to .NET and its disadvantage – not having the same runtime environment and power as the other major language went away. Note the fact that VB is easier to learn, read and maintain is still true but now you also get all the power of C# and since .NET creates code on par with C++ it means you as a VB developer are creating first class applications.

Sure some people have jumped from VB to C# that is to be expected, and many companies which in the past would have C++ for some projects and VB for others are moving to use only 1 .NET language. However, as I’ve noted in the past most VB developers will find the transition to VB.NET fairly easy and natural. When I teach I find that the students with previous VB experience do very well, and in fact that once they get the key elements of Object Oriented Development are ready to become productive. More importantly the VB teams recent move from a migration wizard to the Interop toolkit (similar to WPF Interop) and the Power Packs make the transition from VB6 much easier.

What is interesting is how the VB team blog (http://blogs.msdn.com/vbteam/) ranks in the top 1% of all MSDN blogs and the fact that the VB Developer center on MSDN is one of the top trafficked sections of MSDN (http://msdn2.microsoft.com/vb). <credit VB Team> In other words VB is doing just fine and as I’m sure we would all agree so is C#. In the near term there is no reason to suspect anything about this equation will change – C++ and Java developers will tend to prefer C# and those who have mastered both VB and C# will prefer VB J

So what about the future?

Well for starters the Visual Basic team recently published the Beta version of the Visual Basic language specification. A great step for defining how the language works, and one I look forward to seeing become the basis for standardization. We also know Paul Vick is discussing VB X (aka VB 10) over at Panopticon Central (http://www.panopticoncentral.net/) and is very open to input on things to deprecate in the languages specification and new language features to add. I highly suggest going over to get in a good suggestion or two. As for Visual Basic – I’m confident that it’ll be around and diving into all corners of the Microsoft development tools.

Put the end of Daylight Savings Time Back!

Bill Sheldon — Wed, 31 Oct 2007 00:08:00 GMT

So this is a quick post to place my vote on the recent changes to daylight savings time. When it comes to movng it earlier in spring back toward Febuary, that works for me.

However, moving it from the last Saturday in October to the first Saturday in November messes with Halloween. Instead of it getting dark an hour earlier so that the Trick or Treaters get out earlier and finish earlier - everyone waits for dark to fall and the result is: Trick or Treaters are out for almost an hour later at night.

I know that some will say that having the sun out makes trick or treating safer but as was shown tonight - that is only true if people change the habit of waiting till dark. We didn't base our trick or treating when I was growing up on a time, we based it on sunlight -when it was gone we got to go out. So don't make up alot of claims about safety, the reality is this is one of the few nights (July 4th is another) when kids get to go out after dark. And as I recall we kids love that aspect of it. So instead of everyone being done by 7:30 or 8 they are finishing up around 9, meaning they are out later which is in my opinion a bigger risk.

So with all due respect, to everyone's claims of non-existant energy savings and safety, put daylight savings time back to ending at the end of October, Thanks

Estimation

Bill Sheldon — Sat, 27 Oct 2007 01:50:00 GMT

I actually a while back wrote a discussion on software estimation that someday I'll post. However, this evening I ran across another item that I felt it worth pointing out.

In general I consider software estimation to still be more art then engineering. I don't mean this as a complement, I mean that its predictability, which in engineering we strive to keep high, is in reality low (experience people operate closer to medium predictability...) Part of the problem of course is the ability to learn over time and effectively apply the lessons. The fact is an experience software lead has learned over time how to estimate and may come close but the learning is of a more intuitive nature. That's why someone will ask 'why did you estimate that X would take 3 days?' and the engineer's answer is the equivalent of 'because.'

So why am I bringing this up, well I'm going to reference one of those people who's blogs I follow in terms of the business of software. As I've said in the past - if you are working in this industry not only should you be keeping up with technology, but you need to take some time to learn about the business side - and estimation definitely falls into that category. Let's face it, from an engineering standpoint I wouldn't care if I finished in a week or a month, but from a business standpoint - well that is a huge difference.

With the release of their latest version of FogBugz, Fog Creek has introduced a new feature for software estimation. In short the idea is that over time as you define and estimate tasks the software tracks the accuracy of an individuals estimates over the course of a project. It then determines an accuracy factor. Over the course of several projects it refines this factor. It then applies this factor to an individuals estimates - for more information check at Joel on Software's blog at: http://www.joelonsoftware.com/items/2007/10/26.html

On the surface this is a great feature and I like it but a couple notes, not to bash but as a warning since even my first impulse is to say "I'll take 2". First the estimator (person creating the estimate) can't know what the tool's adjustment factor for their estimates is because they'll probably 'game' it. That is to say the estimator will consider their estimate and if they know that the tool will double it, well they'll reduce it by some percentage, because of their inate desire (and it may be totally unconscious) to hit some number (generally as low as possible). After all the estimator says (ex: "I know I was over by 50% last time over the project so I was going to double my initial gut estimates but the tool is going to do that so I'll need to reduce my estimates so that when the tool doubles my estimates they won't be too high.") The net is this can result in a reduction of the original estimate to account for the tool's automated increase.

The second thing to keep in mind is that the tool doesn't account for the fact that each project is truly different. If the developer were consistently estimating the same type of task then the 1 to 1 corrolation that the tool applies makes sense. But if project 1 is say a desktop application and the developer's UI estimates are 50% under and the next project or the third or fourth consectutive project is suddenly an web UI or a pure business interface and as such the developer's estimate is 90% correct - well suddenly the game has changed and in reality the previous estimates shouldn't be weighted as heavily - but how heavily is the question, that 50% and 90% could also be reversed. The tool isn't magic and it can't account for all of the variables.

Finally by its nature this tool will always penalize someone who's estimation skill is improving. The first set of estimates might be all over the map, the next set might be consistently 25% of actual and then if the estimator sees this and ups their estimates by 150% the correction factor of the tool will suddenly make the estimate way over the top. Something to keep in mind whether your tool is a fancy algorithm or a set of multipliers in an Excel Spreadsheet - the tool is only a tool - you will still need to carry out a reality and business cost review of the estimate.

Roots of MVC

Bill Sheldon — Mon, 15 Oct 2007 13:56:00 GMT

So the latest industry buzz-term (since it's not a word per say) is MVC. MVC is a description of a software pattern. The key to software patterns is being able to speak them and understand them. I'm sure you've read many articles that mention MVC and you sit there wondering: What is MVC?

So some 'jerk' (you know the type who provides your latitude and longitude when you ask where you are) says to you, "MVC stands for Model-View-Controller and it's the latest in architecture."

OK, What is a Model View Controller and what do I need to change in my architecture?

This is actually a pretty simple question and as I've said before, outside of major paradigm shifts - the more things 'change' in the technology world, the more they stay the same. Many years ago - probably before some of you reading this were born we had the concept of a 3-tier architecture. The idea, which followed on the heels of modular programming was that you should separate out your User Interface from your Business Logic from your Data Access. (UBD... or reordered DUB) Over time this was called n-Tier because you might have more then one 'tier'. The idea however was that you had components responsible for these elements.

Well in an MVC model the Model represents your data access, the View represents your User Interface and the Controller represents your Business Logic. So you have DUB -> MVC - but wait say the formallists, it isn't the same. So what's the difference?

Well under the n-tier model there were those who subscribed to the idea that all communication had to travel from the User interface to the Business Layer to the Data Tier, and in the reverse. In other words the User Interface wasn't allowed to directly communicate to the Data Tier. We tended to refer to people who tried to enforce this as 'jerks' (see above). Generally those of us developing applications spent hours justifying the fact that in the real world it made sense to have the User Interface directly access the Data tier to retrieve key data and in some cases even for certain key automated updates. That's essentially the gist of the difference.

So there you have it because people couldn't adapt to this one concept we have a new name - MVC to describe an old concept. So when someone suggests you re-architect your current n-Tier application to be MVC based and they want to charge you money to do so - well you know how much it should cost - nothing because even if you kept your UI from updating database directly, you still have an MVC architecture in place.... now you can just stop being so * retentive about which components in that architecture communicate.

Its funny we literally created a new name for an old concept, why? Well the 'jerks' will accept a concept with a new name that doesn't exactly match their understanding of an older concept. It's literally easier to reaname and remarket a concept then to for some people to update their knowledge.

The preceding is of course a brief comparison - to wit there are several other characteristics of the architecture models I've omitted (such as n-Tier) in order to quickly illustrate the key similarities between these models. I'm sure someone (see jerk above) will point out one or more such items in the comments...

UPDATE: I should also point out that yes the MVC pattern has probably existed for as long as the 3-tier architecture has. The point here is that it is the latest trend for architects and for many the new description seems like it is describing something... well.. new. In the past MVC was a common model for application logic but now that more "software architects" are actually learning about software best practices it has made the move to describing enterprise architecture. The concepts aren't new, just the name being used to describe what we've been trying to do.

So if VB -> C# then Java -> ?

Bill Sheldon — Mon, 27 Aug 2007 00:29:00 GMT

It's been a long weekend and I didn't get all the work I wanted done, but I thought it was time to capture a couple of the random thoughts that were ricocheting around...

1. There is a technical person with whom I have worked for many years. We have somewhat similar pre-.NET backgrounds although his primary background was more in Visual Basic under COM while mine was more a combination of C++ and VB. After .NET was released this individual quickly picked up C#. Becoming quite adept with C# this person was then heard to state publicly (paraphrasing in spite of quotes) "VB developers should focus on C# instead of VB, because they'll find it easier to learn {a complete new syntax, language and object oriented environment} then trying to understand the differences between VB 6 and VB.NET."

I'm actually not going to touch that statement however; I was wondering recently if then the reverse wouldn't also be true. Specifically, those developers familiar with C++ and Java should move to VB in .NET. The reasoning stands that "they'll find it easier for them to learn {a complete new syntax, language and object oriented environment} then trying to understand the differences between" C++/Java and C#? Seems like if A is true B should also be true and if B is false then perhaps A is...

2. This one is more a conversation quote -> let me set the stage. We work in small teams on most projects. Those teams have used (for years) a custom 'Agile-like' process. Not everyone has the same level of experience with this model and at some point in the past the following conversation (paraphrased) took place. I was the engineer involved and the other person - not being an engineer supposedly doesn't suffer from my "innate inability" to communicate. We join the conversation in progress; Eng. 1 has just told Eng 2 a few things they should coordinate for today and tomorrow:

Non-Eng - "So how will the two of you coordinate?"

End 1 - "We'll talk during the course of the day."

Non-Eng - "That needs to stop. We need to change that."