Before the internet, well-stocked public libraries, and other venues of information dissemination, institutions of higher learning (e.g. university) held more importance. Their influence was earned by having the best people -- most research and innovation happened at universities -- along with all of the important information (great university libraries, which could be visited by only the few), and the resources (chemicals, scientific equipment, medical equipment, telescopes, the Abacus.NET 1922 Pro Edition) necessary to learn and master a profession.
In those days it was close to impossible for someone to gain knowledge in a field -- much less become an expert (recognized or not) -- without overcoming significant barriers to entry and becoming one of the few to partake of these fine institutions.
For most fields there simply was no other way of getting "in".
For the few who did have the pedigree and financial means, and managed to get in, there was the job security of the simple fact that the number of new entrants was artificially limited, and could be modulated with ease when the need arose.
In recent history, however, much of this information, and many of the tools -- both practical and research/training -- have been liberated ("democratized") for some professions, most especially software development. Many of the barriers to entry have fallen.
We now live in an era where it's entirely possible for a grade school dropout to learn from the best minds in the industry, to freely use some of the best tools and innovations available (when I started in software development, the costs for even the basic tools were substantial, and of course piracy options for those so inclined were much less accessible: Your peers could get you a copy of Wing Commander or Mule, but not Visual C++ 1.0. Now anyone can get incredibly rich development platforms and tools for nothing, even for the Microsoft platform), and to build class-leading solutions using the best industry patterns and practices.
All without getting their break via the traditional route.
Even for those with their computer science degree -- university is vastly more accessible, both from availability and financial perspectives -- often they'll tell you that what they're applying today is a combination of what they knew before they went, what they learned during intern/co-op placements, and what they learned after getting out.
Graduates of the University of Waterloo CS program, for instance, are in heavy demand largely based upon its excellent and comprehensive co-op placements. In essence employers like it most for the time the students spent out of the classroom -- time where they often acted as extremely junior development partners, many times relegated to mindless grunt work. [Another reason for the University of Waterloo's excellent reputation is a bit recursive: Given its reputation, there's the presumption that the best of the best apply, and only the best of the best of the best get in. It's a bit of a self-sustaining loop, so a Waterloo degree is often used as a sort of crude filter, in the same way that Ivy league degrees have influence]
So why bother with the whole going-to-class-for-four-years supposedly to learn CS thing? It almost seems more effective for everyone to compete to get on an artificially short list, after which they can go on Manpower assignments for several years.
Really that's sort of where the field seems to be going.
Many software development employers ask only for a University degree nowadays -- regardless of the lack of relevance of the major -- using it only as a resume deflection shield, presuming (often incorrectly) that it'll yield them candidates meeting a minimum level of intelligence and commitment. Past whatever largely arbitrary minimum requirements are mandated, relevant experience is often considered far more important than educational accomplishments.
This is an acknowledgement that this profession is at a point where anyone can have the best tools in the industry with just a couple of downloads (those expensive tools that many large shops still like to embrace are more frequently a hindrance than a help, and offer few advantages), and they can leverage and learn from the solutions and experience of the best the industry has to offer. There are remarkably few barriers to entry, outside of a couple of niche areas where experience on uncommon platforms (e.g. SAP) or hardware (e.g. mainframes) is required.
Oh, except skill. There's still that barrier to entry. It tends to be a pretty big barrier to entry.
In many ways software development is mirroring the literary or culinary worlds, where higher learning is pursued for the skills gained rather than the credentials, and competition is open for anyone with just a pen and a pad of paper (or better yet a typewriter and a stack of 8 1/2 x 11), or a couple of pans and a stove.
We can all cheaply talk about how we'd like to write the next Great [Insert Nationality Here] Novel, but really it's nothing more than cheap talk if we aren't well on our way to actually doing it. There's nothing externally stopping us, yet remarkably few of us ever will.
Remarkably few of us really have the innate skill, regardless of the seeming ease of taking the first steps. We could all be great chefs (great chefs aren't just people who have been anointed by a group or individual -- they're actually capable of extraordinary things, and earn respect for what they can do) with a couple of pans and ingredients at the grocery store, but most of us never will be.
You can buy yourself the most expensive pens, or the most incredible pans on the most expensive Viking stove, using the rarest and most exclusive ingredients you can find, but it still won't automatically make you any good.
This all came to mind after hearing yet another comment that my photographs of my children were "professional quality". While my photos are half decent, it's more indicative that people need to modify what they consider "professional" in the field of photography, because the bar has substantially raised. A quick browse through the endless extraordinary photos on flickr makes that quickly evident.
There was a time, in the era before digital cameras, and perhaps moreso before accessible 35mm cameras, where one became a "professional" photographer largely by putting out a significant chunk of capital and buying some expensive equipment. Put out the cash and buy a nice medium-format camera and all of the accessories (the more lenses, flashes and cool looking gizmos, the more professional one was), and one was 80% of the way towards being considered a pro. Everyone else was stuck using garbage little cameras that were basically incapable of taking good pictures.
Hang your sign and start photographing weddings.
With the dropping price of 35mm cameras, things improved somewhat, but even then there was the substantial barrier to entry in the form of learning through experience: Going through rolls and rolls and rolls of film, and the corresponding development, was a very expensive way to learn through mistakes. I remember the serious contemplation that preceded every single shot with my 5xi 35mm, because it would end up costing me over $1 a shot after adding in processing.
Taking multiple shots with differing exposures or focuses or depths of field simply wasn't an economic possibility, so many scenarios where I might have gotten a great shot were limited by my fiscal constraints.
Now with digital cameras, especially some of the nicer offerings, learning through experience is inexpensive and provides immediate feedback, and there are controls for virtually everything. While there are still the diehards who'll go to the ends of the Earth defending 35mm film (which itself was considered laughably inferior to medium format at the time), the results of my Canon Digital Rebel XT are far beyond anything I ever achieved before. Couple this with the fact that I can take thousands upon thousands of amazing pictures, experimenting with exposure and focus and depths of field and motion blur and shutter speeds.
Invariably some of them turn out pretty good. I've actually read the manual to my camera, and have long understood the basics of photography, but I am hardly a professional in this field.
The barrier to entry to take some great photos has substantially fallen, and I'm sure it's put tremendous pressure on a lot of hack photographers. Many of them are loading up on as many expensive lenses they can buy, even where they don't use them, and as extravagant of hardware as they can find, all to try to differentiate themselves from the commoners, yet ultimately the only thing that matters is results.
I've seen some pictures taken using low-end consumer cameras -- quality has risen so much, even at the lowest levels -- that are breathtaking. These are taken by people who would have never ventured into photography at all before.
Of course being able to luck into, or at least hack into, some good results doesn't make me a great photographer. I wouldn't hire me as a wedding photographer, where you can't luck into a couple of good photos, but rather have to capture fleeting moments with quality and consistency.
So while the barriers for neat or beautiful or staged photos have dissolved, for critical fleeting-moment types of needs there still remain some barriers to entry, in that few will trust someone with their event just because they took some good photos of livestock. In those niches you need proven experience before people will give you the opportunity to gain experience.
Years back -- in the ancient Web 1.0 world of 1997, when Slashdot was just beginning to enter the geek consciousness -- I became embroiled in an impassioned debate with a peer, arguing the relative merits of open/free software versus commercial/pay software.
Flurries of emails rained over our respective groups, as we fought to evangelize and fortify our positions, building bunkers of suppositions and hyperbole.
At the time I was a fervent admirer of Microsoft and their Ways -- a position that lead to endless accusations that I was a covertly paid astroturfer for the so-called Evil Empire -- not to mention that I was, and remain, a true believer in the capacity for financial incentive to encourage innovation and product excellence.
I also rather enjoy the software development profession, and it wouldn't be untrue to say that my position was partly driven by defensiveness, motivated by a fear that open-source software, and the accompanying ideology and fanatical advocacy, undermined my professional existence.
My opponent, in contrast, was a GPL-embracing, Linux-advocating, Microsoft-hating, Stallmanesque sort. He'd finger through his unkempt beard (where one would expect to find stray noodles from a prior meal), and after trying to convince anyone listening that recompiling one's kernel with drivers specific for the target environment was an ideal arrangement, he'd tear into the evils of closed source commercial software, passionately arguing that closed source, along with intellectual property hoarding, was a moral sin.
We debated the merits of "free as in beer" and "free as in speech" software, with him arguing that many software solutions were so ubiquitous and prevalent, and so easily replicated, that they no longer merited payment or intellectual protection: Innovation in that realm was no longer driven by capitalist forces, but instead arose from scratch-an-itch needs.
Everyone would benefit, he advocated, if we all contributed to the global software pool, and we could all pull out what we need, receiving "payment in kind" by way of other people's contributions. If we found an edge/exception condition that the software couldn't handle, or a missing feature that would solve our need, we could code it in and contribute back.
In essence a sort of software socialism.
The particular example we continually debated concerned basic system functionality, specifically that kernel services had been so thoroughly fleshed out, and were so similar across vendors, that we'd reached the point where the foundational operating system should be free as in beer, and more importantly free as in speech. With the basic infrastructure accounted for and implemented well (albeit constantly evolving as people scratch their itches, and hardware vendors implemented enhancement to leverage new products), organizations across the land could focus their financial and human resource efforts higher in the software ecosystem.
This was just one example, and he held the same opinion for a wide range of system services and development libraries.
All of the big retailers, for instance, could leach off of an open source point of sale system, running on an open source platform, hiring help to customize it to their needs, and then contributing their changes back to benefit others.
Win/win for everyone: Retailers got a customized POS system for "nothing" (presuming that evaluations, implementation, and maintenance were free, but ignore those silly nuances) -- to most retailers there is no strategic advantage to using a different POS system than competitors -- which they could customize limitlessly; Customers win because of reduced overhead in the infrastructure, theoretically leading to lower prices; Developers/IT-types win because they get hired on for customization and support, and they have the ability to have as much "inside knowledge" of the product as anyone else (versus a product like SAP, where only those inside SAP have the ability to have complete knowledge of the product, leaving everyone perpetually a step behind), not to mention that a shop will be more open with their wallet, presumably, when they don't have to pay several million dollars to a software vendor.
We'd save the carrot of wealth -- the argument went -- to entice those developers truly pushing boundaries, or gain from the development of large corporations with specific needs ("itches") that would also benefit the overall community, rather than paying tithe to yet another Lempel-Ziv implementation or scorecard system or multitasking kernel, or for yet another reworking of the system services to benefit some up-and-coming new product from the same organization.
And anyways, those people who did contribute to the free-software ecosystem were rewarded in kind by improvements and extensions of what they have done, along with all of the other software they could utilize and leverage.
At the time I thought he was nuts, or at least irrationally idealistic.
Not only is it a grossly unbalanced system, where there are magnitudes more consumers than there are creators, but more importantly it seemed to de-professionalize software development: Under the universal implementation of this sort of system, developing software, with software as the product, wouldn't be something that could put food on the table and a roof over one's head, not to mention pay the car loan, put the kids through university, and fund a retirement.
Software development would be limited to hobbyists, parental
basement dwellers, and professors attached to the
academic teat, disconnected from financial reality. The
guy with calloused fingers and tired brain, exhausted after
months creating the next open source wonder, barely has a leg
up on every johnny-come-lately that appears and offers support and
consulting on their creation.
It didn't seem tenable, or sustainable.
To be honest, I was sure that the whole open source thing would fizzle out, apart from a couple of large corporate projects run in a traditional manner, releasing source purely as a PR move.
As the years have passed, and my knowledge and the market itself have matured, however, I've been moved more and more to the point of finding myself agreeing with parts of his argument.
Not all of it, though.
I still think the GPL is a wolf in sheep's clothing. I still think the "support" financing angle is laughable for all but the largest, most enterprise-friendly of vendors. I still think the Cathedral and the Bazaar paper is wishful thinking, and is a model that is largely unseen in most open source projects. I still think the overwhelming majority of open source software -- following the whole power law distribution thing -- see little source code attention beyond that given by the direct developer(s), with many projects abandoned after the initiator fails to see the Linux-like attention she expected. I still think that "it's secure because the source is available!" is ridiculously naïve, hinting at a bit of hopeful denial. I still think the simplistic idea that having the source code (such as to the Linux kernel) automatically correlates with being able to actually effectively do something with it hints at a complete lack of experience in software development, where people underestimate the project and domain knowledge required to effectively make use of source beyond changing some label constants. I still think many of the large corporate cheerleaders of open source are exploiting the movement, getting software for their expensive, overpriced, proprietary and patent protected hardware on the backs of a bunch of hobbyists, while offering remarkably little in return. I still think many successful open source projects are largely just traditional software products, with a core group of paid individuals who are responsible for the vast bulk of the implementation, and the project just happens to have source code available.
I still think that "proprietary" closed source systems have a significant role to play, and that a lot of the innovation in the market happens because someone is chasing a dollar, and then everyone falls in line behind.
Even in open source, capitalism motivates a large number of projects as developers imagine great support and consulting contracts just around the bend, or the increased ability to monetize their reputation.
Yet frequently I'm finding myself asking "you actually want money for this simple hackjob?"
This is especially true in the Microsoft-ecosystem development market: Where the PHP, Perl and Python worlds have powerful, complex, free (both in terms of availability of source code and monetary cost) components and modules covering virtually every need, one often finds that even the most trivial .NET component include demands for often significant sums of money, not to mention arduous and annoying licensing and compliance requirements, often bundled in a warm nest of layers of IP protections and redistribution requirements.
Which brings up a critical point -- Even ignoring the upfront cost, software licensing is a major PITA. Add in some hack-job activation scheme or machine lockdown, and you've made me paranoid that a simple hard drive failure or system migration is going to cause major hiccups of administration. Suddenly I have to worry about endless dependencies and additional costs for every developer added on the team, with even casual consultants suddenly needing multiple licenses -- and related activations -- to compile with the tab component or the grid component or the POP3 component.
What a nuisance. Sadly this sort of commercial software overhead is only getting worse as time passes.
So even where I don't care for the source code or its availability, and I don't care about the upfront costs, I'm being drawn to free-gratis software where the need in question is relatively trivial or long proven. It's not that I'm adverse to commercial software -- I most certainly am not -- but there is a limit to its exploitation.
From FreeBSD appliances to 7-zip to the GIMP to JAlbum to JDiskReport to the many free online services. Access to the sourcecode is a nicety, and in some cases is critical, and I always demand trustworthiness of the software in question anyways, however it really is the gratis element that's most important to me (as it is for many people, though they mask that simple reality under a cloak of open-source camouflage), because it often comes with extremely liberal usage requirements.
Naturally many developers will gasp in horror at the idea of replacing commercial software with free software. Their natural opposition --and this was the root of my original defensiveness -- is the idea that such an action leads to a contraction of the software development field, basically putting ourselves out of business as more and more of our bread and butter disappears.
"If you aren't paying the Microsoft tax", they argue, "you're dooming us all!".
Nothing could be further from the truth. The Microsoft tax could be what's dooming us all.
Again sticking with Microsoft as an example, given their size and importance, every developer not working at Microsoft -- whether they work for a competitor or for a small IT shop -- needs to remember that Microsoft's eventual goal is to put every one of them out of work. If Microsoft could convince every organization to pay them $10,000 per head per year, and they'd get magically adapting and accomodating, infinitely flexible systems runnable by a minimum-wage temp, they would.
Microsoft is endlessly putting out feelers to determine what shops are paying developers to make, and then they're trying to build wizard-filled, manager-friendly solutions to accommodate that need (for a small fee...). The sales pitch, of course, is a barely concealed statement that you can dump that developer, or at least replace them with someone much less skilled, therefore less expensive.
You know that clever Microsoft ad where the IT department is learning line dancing, given how much easier the new server version is to administer, thus giving them lots of free time? Really it was a not-so-subtle message directed at Vice Presidents -- Here's a way to chop the headcount, putting some people out of work. Just pay Microsoft the not insubstantial cost of $X across your enterprise, and you can save $Y. Even if $Y is lower than $X, capital costs always look "cheaper" on the financials than human resources costs.
How about the Total Cost of Ownership comparisons, where Microsoft proudly shows that the TCO of Windows is comparable, or slightly lower than, Linux for certain needs. They do this by minimizing manpower needs and skill requirements, meaning that you pay more to Microsoft for all of those server licenses and client access licenses, and then you can pay a little less to employees.
It doesn't sound quite as inspiring from such a perspective. When you really step back and look at it, and realize that Microsoft -- or any one software vendor for that matter, and I'm not intending to pick on Microsoft but to use them as an example -- doesn't have interests that are necessarily aligned with yours, Mr. uISV or corporate IT worker bee or consultant, it starts to seem more and more bizarre how defensive many professional software developers are about Microsoft relative to open source source. How bitterly they complain about open source, feeling that every win for Linux or Apache of Firefox threatens their own future.
None of this is to say that efficiency isn't important -- it's critically important: When I buy a loaf of bread, or shop at a grocery store, or buy a car, it's to my benefit for those organizations to do everything they can to minimize costs, even if that means leveraging systems that make some of their workforce unnecessary. So if Microsoft can throw together a cost effective Biztalk Infopath Sharepoint Portal.NET Server 2007 that eliminates the need for a signficiant percentage of custom development across the land, then that benefits everyone (well...apart from those directly affected -- the people directly losing the jobs).
We all get a little bit more for a little bit less.
The critical point I'm trying to make, however, is that from a personal perspective the argument is not, and has never been, free software -or- commercial software. In fact many commercial software ventures can be helped by the cost savings of free software (presuming that there aren't license conflicts). Your solution looks a lot more palatable when it leverages a stack of free, well-known software, versus requiring a complex mix of server systems and expensive third-party software (we once considered a solution that would have sold for less than $500, yet would have necessitated about $4000 of Microsoft software). Your IT team looks a lot more cost effective when the shop isn't spending millions of dollars a year maintaining various Software Assurance plans, spending tens of thousands on various marginally useful software products per developer head.
It's hardly surprizing that many of the "Web 2.0" success stories started out on, and then scaled up with, open source platforms: Their beginnings weren't hobbled by software fees that exceeded the yearly take of the founders, and they could scale out cost effectively given they didn't require endless CPU licenses, client access licenses, and component fees.
From a personal perspective, I still build solutions largely for the Windows platform, often using integrated technologies such as .NET, ActiveDirectory, and IIS, while leveraging servers such as SQL Server and Biztalk. Yet I do so from a very pragmatic, looking-out-for-#1 perspective -- If I could reasonably justify switching to a free platform, I would. I owe no duty to Microsoft to keep their revenue stream padded.
Recently I had the need to receive some PGP encrypted files on a server, which necessitated the ability to decrypt them from a script. Seemed pretty straightforward, especially given that I was doing something very similar with PGP freeware over a decade ago.
"Uh oh," I though. "here comes the ubiquitous server tax." (the server tax is the fact that commercial software, no matter how trivial, have a propensity to bizarrely cost much if it runs on a "server"). I headed over to PGP and took a look at the command line version.
This is, in essence, just a slightly updated version of the freeware PGP circa 1995, so I was a little surprized by the price (not to mention the nonsensical sales criteria -- you can buy send only, received only, or the super-deluxe send and receive. You can also choose to use only 1 key, or many keys. All ridiculous separations that just lead to implementation nonsense and complexity). At the time of writing, the component in question costs a staggering $3,170.
Maybe it's "chump change" for a large enterprise, where such costs get buried under thousands of similar purchases, but these sorts of licenses -- not to mention the administration and hassle of them -- add up. They come out of the general IT pot, meaning less hires, less bonuses, more cost-efficiency pressure, and so on.
I went and grabbed a copy of GNUPG, and found that it immediately fit the need perfectly. The code is modern, and it is fully compatible with OpenPGP implementations. I can use 1, 10, or 100 keys with no additional costs. I can run 1 instance or 100 instances if I want. I can send and receive. I never have to hassle with licensing issues, beyond of course ensuring that code changes (given that I legally and immediately get the source code) that are distributed conform with GPL requirements.
The total implementation cost, especially after considering purchasing and licensing issues (e.g. none), was dramatically less than the commerical offering, offering every bit of functionality we needed (and then some), leaving that money in the pot for other needs. We have the added comfort of being about to plan massive scale-outs with minimal additional cost, increasing the project's versatility and flexibility.
Win/win.
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.
Went to the Toronto Zoo yesterday, despite the "terrible weather" (light to medium rain all day, with temperatures around 19C).
As we've discovered many times in the past, it turned out being the perfect day to go to the Zoo.
No lines. Exhibits to ourselves. No scorching sun ruining our mood. Perfect. Pavillians empty, and time to sit and contemplate what exactly one wants to order at fine food establishments such as Harvey's or Pizza Pizza.
As long as you're prepared, including umbrellas and ponchos, a little rain can be a great thing. We found the same thing at Disney's Animal Kingdom, where again a presumedly crummy day turned out being extraordinary.
(As a sidenote, yesterday was "Daniel Cook Day" at the zoo. Daniel Cook is a smart young boy who has a series on Treehouse TV, among others, basically where he learns about people's professions. As a promotion at the zoo, any kids wearing "Daniel Cook Orange" automatically got 1/2 off admission. Cute event, even though the turnout was terrible, but the idea of getting all of the kids at a strange place to dress alike seems like a very poorly thought out idea. "Come to the zoo! It's Daniel Cook/Lose Your Kid Day!")