While it's evident that Microsoft is staffed with a lot of top-notch people, history has empirically demonstrated that they have quite a few dregs as well: Just recall how disastrously the whole .NET thing was handled circa-2000.
For those who forgot, suddenly every product (including those finished or on the verge of being finished) became a part of the .NET vision, even if they had absolutely no interaction with the .NET technology stack: Windows Server.NET, Exchange.NET, Messenger.NET, SQL Server -- all a part of the .NET generation -- just as Microsoft declared everything in the generation before a part of the DNA vision (I still hear developers talking about "Microsoft DNA", not really sure what they're talking about).
As a developer who was heavily involved with the betas of what we call .NET today - a runtime and a framework, and the associated tools, for building next generation solutions - I really had no idea what .NET was in Microsoft parlance. Just as ActiveX got muddled into a meaningless term, .NET was being hijacked to basically mean "buy whatever is new or coming out soon".
Eventually that insanity stopped, and .NET collapsed down to a sortof virtual-machine runtime, a framework, and a set of tools. .NET 1.0 was one runtime, one framework, and Visual Studio.NET 2002. .NET 1.1 was a new runtime, a new framework, and Visual Studio.NET 2003. .NET 2.0 was a new runtime, an expanded framework, and Visual Studio 2005 (note the dropping of .NET on the naming, given that Visual Studio, as always, also makes non-.NET applications). There are countless assemblies and extension libraries available targeting each of them, and of course I can make libraries tomorrow that target .NET 1.0, .NET 1.1, or .NET 2.0, and it doesn't magically evolve them into .NET 3.0.
Well it looks like Microsoft is at it again. They've decided that Vista's technology platform, WinFX (which will be partially backported), is so great that it can't be just a set of assemblies or systems that the .NET runtime interacts with. No, it must be .NET 3.0! So now if you have the .NET 2.0 runtime, the .NET 2.0 Framework, targeting it with Visual Studio 2005, and you add in the WinFX framework...voila, you have .NET 3.0.
Insanity. Absolute, unbelievable insanity. Perhaps there's some amazing explanation -- for instance that their April Fools project ran a little long, and they just got the output out -- but I suspect it is just more of the same that we saw circa-2000. Some short-term euphoria over a gonna-be-released-soon project has them screwing with the terminology yet again.
Already the boards are full of "So....does this mean WinFX comes with LINQ?" (LINQ is one of the technologies promised for the next real wave of .NET)
To avoid entries becoming a "wall of text" -- especially the lengthy outings -- I've long borrowed from the Philip Greenspun school of online articles and intermixed irrelevant, largely random photographs.
Generally I finish the entry, and then quickly select one, two, or three recently taken shots -- shots with zero correlation to the story in question -- and stick them in. It adds a bit of color, and I've gotten some comments that people enjoy the diversion. As a side-effect, it's a great example of subjective interpretation, because some readers build their own explanation for how each picture fits with the story (I've gotten a few emails describing these interpretations, and it is truly fascinating. A few had me convinced that I must have subconsciously thought that the picture represented X, the explanation was so compelling).
A small amount of extra bandwidth for a little extra color and diversity in the entries.
I recently got an excellent bit of feedback from a longtime friend and associate: They enjoyed the pictures, but found that they made visiting the site during work hours an almost covert activity. Pictures of my daughter playing in a stream, night falling on a drive-in, or some orangutans at the zoo, they felt, would give a passerby or suspicious boss the feeling that they were slacking away reading kidsplayinginstreams.com, or driveinenthusiast.com, or zoopics.com. Knowing how entirely unenlightened many workplaces are, I immediately appreciated exactly what they were saying.
As such, from here on in I'll avoid unrelated pictures, perhaps sticking to pictures of circuit boards and control flows.
Completely Offtopic - Several days back I was stuck driving behind a huge late-model Chevy Suburban in an industrial park. What struck me as absurd wasn't the vehicle -- some people actually need a vehicle of such size, even if most don't -- but the way they carefully swerved to avoid every single manhole cover on the street: Undulations in the road of less than a CM, which are filtered out in the shocks of even the smallest of econoboxes, had this person doing panic avoidance maneuvers.
Irony in vehicle choices.
[The static location of this piece can be found at this address]
For the past while I've been using Visual Studio Team Edition for Software Developers, one of its benefits over the Professional Edition being the inclusion of static code analysis functionality right in the IDE.
This functionality comes via the FxCop codeset, which is an excellent -- albeit unpolished -- freely available tool for analyzing the probable code quality of Intermediate Language assemblies, testing code to ensure compliance with naming standards, best practices, and highlighting areas of code that are suspect. While it's less than pleasant starting FxCop analysis from scratch on long existing project -- to be met with hundreds upon hundreds of error messages -- it's a painless process if you add it to your quality checks early on.
The standalone FxCop is largely the same as the VSTE version, and in some ways is superior. For instance that it retains the ability to actually pass configuration settings to rules, rather than accepting whatever the defaults for the rule are.
One of the few differences between the standalone application and the VSTE-included version are the addition of several new maintenance checks in the Team Edition code, one of the most useful being the cyclomatic complexity checks. Cyclomatic complexity, for those who haven't come across it before, is often used to roughly gauge the complexity of a piece of code, to determine likely candidates for refactoring, and to identify what will likely become a maintenance problem in the future. Finding the most complex pieces of code often brings you to the buggiest code as well.
Given that I still use FxCop, both the .NET 1.1 and .NET 2.0 versions (not least because the integrated version offers no ability to configure settings for rules, instead only allowing you to wholesale enable or disable. This eliminates the ability to set thresholds for tests such as the cyclomatic complexity rules), the lack of consistency between the two versions was an annoying gap.
So I implemented a simple cyclomatic counting rule for the standalone FxCop. While in there, I added checks for statement count (the number of intermediate language "statements", which can be indicative of overly complex methods), and callout count (e.g. callouts to other methods, again which can be an indicator of overly complex/convoluted methods).
As one added benefit, I added the ability to log all of these metrics to an SQL-capable OleDB destination (e.g. SQL Server, Access, etc). If you configured an OLEDB connection string, as detailed below, you can do data analysis after a run to create pretty reports of the complexity distributions of your projects, and so on.
yafla FxCop
Rules for .NET 1.1 (e.g. FxCop 1.32)
yafla FxCop
Rules for .NET 2.0 (e.g. FxCop 1.35)
Like any tool of this type, there is only a moderate correlation between the metrics measured and actual code quality or maintainability: It is entirely possible that the optimal implementation is a highly-complex, lengthy method. This tool only provides guidance, helping to determine which code should get a complexity analysis, however from there experience and good judgement have to be applied to determine if it's really a fault. If you're using the .NET 2.0 version of FxCop, make use of the SuppressMessage attribute on methods that are necessarily highly complex.
Drop yaflaRules.dll in your FxCop Rules subdirectory (e.g. C:\\program files\\Microsoft FxCop 1.32\\Rules).
If you want more advanced settings, configure FxCop with your targets and selected rules and then save the project file. Open the newly created .FxCop file in an editor (for instance notepad) and find the <Settings /> element. Expand it to an opening and closing tag (e.g. <Settings></Settings>), and between it add
<Rule TypeName="MethodComplexity"></Rule>
Between the Rule element add any of the following entries as Name attributes of an Entry element (as exampled following) -
Connection String - an OleDb connection string
determining where it will log metrics. e.g.
Provider=SQLNCLI;Server=(local);Database=Analysis;Trusted_Connection=yes;
Target Table - The target table for metric
logging. Default -
MethodComplexity
Cyclomatic Critical
Error - Level at which a critical error is
triggered. Default - 60
Cyclomatic Error - Level at which an error is
triggered. Default - 50
Cyclomatic Critical Warning - Level at which a
critical warning is triggered. Default - 45
Cyclomatic Warning - Level at which a warning is
triggered. Default - 40
Cyclomatic Information - Level at which an
infromation event is triggered. Default - 20
Cyclomatic Recommended - Recommended level.
Default - 20
Statements Critical Error - Statement count at
which a critical error is triggered. Default - 500
Statements Error - Statement count at which an
error is triggered. Default - 350
Statements Critical Warning - Statement count at
which a critical warning is triggered. Default - 250
Statements Warning - Statement count at which a
warning is triggered. Default - 200
Statements Information - Statement count at which
an information event is triggered. Default - 150
Statements Recommended - Recommended maximum
statement count per method. Default - 100
Callouts Critical Error - Callout count at which a
critical error is triggered. Default - 100
Callouts Error - Callout count at which an error
is triggered. Default - 75
Callouts Critical Warning - Callout count at which
a critical warning is triggered. Default - 50
Callouts Warning - Callout count at which a
warning is triggered. Default - 40
Callouts Information - Callout count at which an
information event is triggered. Default - 30
Callouts Recommended - Recommended maximum callout
count per method. Default - 30
For instance, you might end up with a <Settings> element that looks like the following:
<Settings><Rule TypeName="MethodComplexity"><Entry Name="Connection String">Provider=SQLNCLI;Server=(local);Database=Analysis;Trusted_Connection=yes;</Entry><Entry Name="Callouts Warning">100</Entry><Entry Name="Cyclomatic Critical Warning">500</Entry></Rule></Settings>
If you opt to take advantage of metrics logging, the destination table (which will be default will be MethodComplexity, unless overridden with the Target Table name entry) requires the following columns:
ContainingType - text (e.g.
nvarchar(255))
MethodName - text (e.g. nvarchar(255))
Cyclomatic - int
Statements - int
Callouts - int
e.g.
CREATE TABLE [dbo].[MethodComplexity](
[ContainingType] [nvarchar](255) COLLATE
SQL_Latin1_General_CP1_CI_AS NOT NULL,
[MethodName] [nvarchar](255) COLLATE
SQL_Latin1_General_CP1_CI_AS NOT NULL,
[Cyclomatic] [int] NOT NULL,
[Statements] [int] NOT NULL,
[Callouts] [int] NOT NULL
) ON [PRIMARY]
Hopefully someone finds this interesting. It scratched my itch.
These practices primarily
benefit the recipients of your missives, however they do benefit
you as well. You'll have better organization of your sent items,
for instance, not to mention that in the future you will go through your emails, amazed
that you were the author, trying to quickly figure out what each of
them was about in the search for something in particular.Like most professionals in the technology field, I jump to Google and other search engines fairly frequently, in pursuit of hints and documentation to help with various technology dilemmas. A quick search on the web and the archives of newsgroups usually saves a tremendous amount of documentation diving and experimentation.
In return for the huge benefit that other people's documented successes, failures, and experiences bring, it has long motivated me to "pay it forward" by posting technology information online myself, hoping to help some future information seekers (on a similar vein, whenever I get a worthwhile answer on the newsgroups, I usually make it a habit of hanging around and answering several questions myself, returning the favour to the community). If the search logs are to be believed, over the years quite a few people have found pertinent information here regarding their software development problems or questions.
Lately I've been noticing a decreasing utility-versus-search time ratio, however, with quality declining largely as a result of a growing number of high-pagerank sites feeding cloaked/phantom pages to the Google search engine. Google sees a question/response that correlates closely with what the information seeker is asking, yet a visit by a real user (rather than a search engine spider) quickly finds only the question, with the answer suppressed until the user a) goes through an irritating, arduous process to sign up as a member on yet another infrequently visited edge site that'll likely sell their email address and bombard them with endless ads, b) signs up for some sort of pay membership. Given that many of these sites are simply siphoning their content from the Usenet or other forums, I'm never going to bother with either option, instead hitting back and following the next link, often to find the same sort of nonsense.
Somehow a small number of these phantom page sites, most of them seemingly linked to by no one legitimate, have taken over the top rankings on Google for a huge range of technical searches. Somehow they haven't been banned by Google yet, despite the fact that cloaked pages are expressly forbidden (if the search engine sees the answer, then any random visitor should immediately see the answer by following the search link, as the search engine hint implies that the immediate page contains the result).
If they feel justified in forcing registration to read often coopted content, or the right to charge a membership, I have absolutely no problem with that -- in fact I think the net would be a better place if there were more commercial opportunities encouraging even more intellectual investments. However they shouldn't fraudulently mislead search engines, and search users, and instead should rely upon normal advertising and word-of-excellence for their great utility. Otherwise they should fold, joining the heap of useless websites that could only fool users into visiting.
Don't waste our bloody time! Google shouldn't be acting by implicit complicity in these irritating schemes.
Speaking of the problem of apparent phantom pages, today I happened to be looking for CodeSmith, a free (albeit crippleware for as long as I can remember, and not freeware as the author continually claims) code generation tool that I had fond memories of several years back. Naturally I begin the search with codesmith freeware.

Great, so the page in question apparently talks about the freeware version of CodeSmith. Only it doesn't, and the text in question doesn't appear anywhere on the linked page. Go ahead -- look at that page and search the source for freeware.
In reality the obsolete and deprecated freeware/crippleware version exists on a totally different page (one which doesn't seem to be referenced anywhere else on the CodeSmith page). So why is my time being wasted with the first, desperate-to-turn-a-sale page? Why is Google entirely misleading me about the contents of said page? This sort of bait-and-switch has to stop.
Completely offtopic, but forcing people to register and anxiously wait for a download key to download a crippled, time-limited version is enormously irritating. It really pushes my patience when I just want to validate a product, almost certain of it turning to a multi-license sale, and finding that I'm forced to go through some B.S. that will inevitably yield annoying sales emails and followups.
Just let me download the demo, and if it's good I'll buy. If it isn't, you don't deserve the right to harrass me with promotions and petitions.
I've been playing with Team Foundation Server, Whidbey (Visual Studio 2005), and Yukon (SQL Server 2005) since early in the beta cycles. All three of them are remarkable products, with enormous advances over their predecessors (in the case of TFS, I'm spuriously considering Visual SourceSafe the predecessor, although TFS is a elephant compared to the mouse of VSS), and all of them should be critical components for anyone developing in the Microsoft camp.
All three of them also happen to be a little unpolished, with odd little quirks and errata, hilariously incomplete documentation, and a tendency towards resource hoggishness.
One thing I've found remarkable, however, given that the three of them have been in final form for anywhere from two months to over half a year, is how little real information and first-hand accounts are available online. I'm continually hitting roadblocks where there are marginal functions or incomplete documentation, and it's surprizing to find zero references to the same problems or questions on any of the normal forums (e.g. Google Groups, online searches, etc). Among the development community, outside of the desperate-to-get-anointed-free-support-MVP crowd, they just don't have the aura of excitement they probably deserve.
Given that there are literally millions of developers and technology hobbyists out there, it's usually the case that any problems one faces are well trodden, and a quick search on the newsgroup usually yields exactly the answer one needs, so this dearth of time-travel support really is disconcerting.
The only conclusion I can draw is that there simply aren't that many developers seriously using these technologies. Visual Studio 2005 is of course seeing some use, but there are still huge armies of developers sticking with 2003 (given the break between .NET 1.1 and 2.0). A lot of SQL shops are still taking a wait-and-see approach with 2005. Team Foundation Server, primarily because of the cost of the Team editions, and the cost of a TFS Server license if you grow past a 5-user team, seems to be fairly rare.
Some educational shows for development shops and development managers can be found, surprizingly, on the Food Network (US, Canada, not to mention that many are played on, and often originate from, various other "lifestyle" type channels).
Some of these shows are homegrown, such as Restaurant Makeover and Opening Soon, while others are imports, like the excellent Ramsay's Kitchen Nightmares, Jamie Oliver's School Dinners, and Jamie's Great Escape.
You've probably gained the impression that I'm an epicurean, interested in the operations of the restaurants, and probably dreaming of the day when I can open my own ("We'll make the best French onion soup ever!"). While I do like well-prepared menu delights, the food is the least interesting part of these shows, in my opinion. And I have zero interest in opening a restaurant (the dream-crushed rate among restaruranteurs has to rank among the worst for passion pursuits), and like small-talk as much as I like getting a tax bill.
Instead the real message of these shows boil down to -
Situations analogous to the software development process endlessly play out between chefs and his staff (team managers/leads and their team members), the chef and the front-room staff (team managers/leads and business partners), and the restaurant and customers (the organization and end users). Many times the solutions parallel how the similar situation would be solved in the software development field.
If you relax to television on occasion, and mourn the summertime (speaking to the Northern hemisphere in that statement) dearth of original programming, check out some of these shows for an informative eye-opener.
We're the chefs and menu planners and sous chefs and pastry chefs of the digital world.