A lot of my work - both system consulting and software architecture/development - relies upon Microsoft technologies: Whether it's re-engineering a legacy system to take advantage of new SQL Server features for performance or functionality, overhauling a network infrastructure to leverage ActiveDirectory and the extensive platform security functionality, or developing a performant and scalable time-tracking application for an enterprise client, Microsoft is often a very important part of the equation.
Partly due to specialization (it's the tools we target), coupled with simply being the best choice in a lot of scenarios in our target market, we heavily rely on the Microsoft platform for ourselves and our customers. As a professional I can say with confidence that the platform is a secure, high performance, extremely scalable, robust one that compares very favourably against all competitors.
That wasn't always an accurate statement, though. Indeed, it is remarkable looking at the history of Microsoft and learning from their success: On paper it really is hard to believe that Microsoft maintained the market dominance that they did, and it's amazing that competitors couldn't capitalize on Microsoft's late entrance into a lot of markets, and their missteps in others.
Was Microsoft a master of timing, holding off on technologies and advances until the perfect time, or were they simply the beneficiary of a captive audience that was willing to wait however long Microsoft took, blind to the available alternatives?
I'll provide a couple of examples that I recall marvelling at as they occurred- these are hardly exhaustive, however I think it's a nice sampling.
I recall during my early courtship with the PC simply marvelling at how incredibly obsolete the platform seemed to be compared to competitors like the Amiga and the Mac introduced years earlier - from graphics capabilities to software to hardware: Everything about it seemed so backwards in comparison to the superior alternatives, yet customers stuck with it. This was the platform that Microsoft wed themselves to, so surely they would suffer as well, right?
Microsoft's insistence on legacy compatibility led to a platform that moved much slower than competitors - Competitors that had the liberty of just tossing it all out and starting from scratch with whatever whizz-bang feature the newest chips offered. Maybe they could run super-stable and super-fast, and offer the developers an elegant platform upon which to perform their magic...but could it run Commander Keen 1 through 3? Could it run that ancient text database app?
Of course it's easy to focus on the deficiencies and imagine that they wrote the whole story, but in reality the situation was much more complex. Windows, for instance, pioneered widely-used video card acceleration (I still remember that shiny new Diamond Speedstar 24x. 24-bit graphics, coupled with hardware acceleration of 3D primitives. It was good times running those benchmarks. Of course the Amiga fanatics will point out that it supported hardware acceleration, just as the STe featured a hardware blitter chip, but the interaction between acceleration and the GDI in Windows really set the bar), and Microsoft's push greatly accelerated the adoption of optical media. Windows For Workgroups brought inexpensive networking to a lot of shops (NetBEUI was imperfect, but it was an easy transition to TCP/IP), and Windows in general represented a "good enough" platform for a lot of users. Internet Explorer, for all of its ActiveX "holes" and CSS quirks introduced the rich web model that we rely upon today.
This all comes to mind as the x86-64 transition accelerates: More and more users are starting to switch to 64-bit capable systems, and the 2/4GB limits of our machines is actually becoming a rational limit among desktop users: Everyday users are shouldered against a limit that seemed almost theoretically large just a few short years ago.
Of course Microsoft has been releasing incomplete 64-bit options for years (for instance you could get a 64-bit version of SQL Server 2000 for the Itanium platform, barring a laundry list of exclusions and limitations, and way back with NT 3.1 Microsoft supported 64-bit processors, albeit in 32-bit mode). Now that 64-bit support is finally becoming a critical factor, Microsoft has a wide gauntlet of support ready, and is finally ready to deliver.
Once again when the market really cares, Microsoft is ready. For years some have been talking about the advantage of various operating systems, such as Linux, being availabile on cutting edge processors and 64-bit platforms. For years that has been paraded as an advantage to customers who continued to run their platform on a standard old x86-32 foundation. Yet now that those limits are being reached, and the platform needs to accommodate new levels of capability and performance, Microsoft is ready. Another deficiency overcome.
Looking at the platform now - the stability, security, and feature set of Windows 2003, a lot of it already existing in XP - it really does seem like a tremendous window of opportunity for the competition has passed: What used to be a crop full of delectable low hanging fruit is now a well protected enclave featuring armed guards.
If competitors couldn't make inroads before, how do they have a chance now? If Linux couldn't capture the desktop market against a monstrosity like Windows Me!, what chance does it really have against XP?
The most obvious answer is web applications - render the operating system irrelevant and you don't really have to compete.
Tagged: [Software Development], [Programming], [Software-Development]
How often did you use the scheduling functionality of your VCR to record your favourite television shows, decoupling yourself from the rigorous schedule imposed by the television networks?
The common answer, overwhelmingly, is never. Few bothered using the scheduling functionality, even when it would be beneficial to their quality of life.
This inspired endless jokes about the complexity of "programming the VCR". Even the few brave "wizards" who did bother scheduling recordings generally did so rarely: The hassle of managing tapes, manually setting schedule times, and then having the uncertain-quality result unavailable until completion simply wasn't worthwhile to most people. Many times it didn't work out, and they discovered that they actually recorded 8am instead of 8pm. Whoops!
Even the introduction of Guide+ - a system that allowed you to record a program by punching in a short code - changed the situation little: To many it still wasn't worth the marginal hassle.
The functionality to time shift was there, but few leveraged it.
This topic came up after becoming engaged in an interesting discussion about PVRs versus VCRs, and why the former is inspiring panic and behaviour changes among the television networks, while the latter was largely ignored. Consider that virtually every household in the West had one or more VCRs, yet only a very small percentage have a PVR today (though obviously it's a much greater percentage among the net savvy). Why the concern about functionality we've had for well over a decade?
The reason for the panic, of course, is that the seemingly minor usability and functional improvements of the PVR dramatically increased the usage and utility of the technology: Instead of rummaging for Guide+ numbers in the back of the newspaper, or worse - configuring start and end times manually - one simply pulls up an online listing, selects the programs they want, and selects to record them. The quality is superlative, it takes just a few moments, and they gain the added ability to quickly skip past commercials. Many choose to automatically record every new episode, saving even more time. To put the icing on the cake, there's no hassle dealing with the tapes.
simply reducing the complexity or number of steps marginally can lead to market dominance
There is a valuable lesson to be learned from this: Seemingly minor advances in usability can tremendously alter marketplace success (the VCR was, of course, a great success in marketplace saturation, but that was almost entirely on the merit of playback of pre-recorded content. Few used it to actually record content). Even when it seems like a marketplace need has been functionally satisfied, simply reducing the complexity or number of steps marginally - or reducing the barriers to entry - can lead to market dominance (or market creation). A PVR isn't just a VCR with a hard drive - It completely changed the equation.
Consider the software market: By all appearances it looks to be a saturated market - with a solution for every need - but the remarkable thing is that much of it remains completely unused and unadopted. There are countless domains where solutions sit collecting binary dust because the complexity or barrier to entry is too high.
Skype, in contrast, blazed a path of glory and achieved virtual overnight success, yet really it's just yet-another IP voice technology (like we've had since the mid-90s. Sure it added the distributed net, but that's a feature that is a marginal improvement at best). It offered a clear, usable interface, firewall avoidance, and a simple directory for finding the other person, and bam it is getting bought out for $2.6 billion - for doing what had been done by countless competitors in a seemingly commodity market for years before.
FogCreek software has had success simply taking some open source software and putting a pretty face on it, offering a small value-add (avoiding configuring your firewalls) - Making money charging money in a market that people thought was saturated with free alternatives. The web could really be considered a Gopher 2.0, but improved usability enough to be embraced by the everydayman. Bam, the webolution. HTML is absurdly trivial, yet the marginal usability advance of blogs are what made everyone a writer. CSS and JavaScript are both highly accessible technologies, and you can get started quickly by viewing the source of sites you like, again vastly accelerating the transition from initial exposure to actually doing something with it.
Even when targetting highly-trained professionals, immediate "usability" remains critical. Remarkably many of the successful back-end technologies are those that were easy to get started with.
Extraordinary to think that multi-year projects and massive web applications of tremendous scale were built on chosen technologies because they offered a painless, 10-minute getting started setup and tutorial - letting someone start pushing out code immediately - yet in talks with peers I've found that this is frequently the case. Indeed, I will admit to this irrational behaviour myself - several times I considered implementing a project in J2ME (targeting cell phones), but the hassle of setting up a J2ME development platform, and then the pertinent modules for the various phones, served as such a discouragement that I abandoned the project rather than wasting 4 hours dealing with that. In the longer term of a project it's completely irrational, yet it happens.
Of course much of the ASP development community evolved not because ASP was the best platform that was being chosen on merit, but rather because a lot of shops had a Windows NT box sitting there with IIS on it, and they started dropping ASP scripts on it (other languages, like PHP, required additional installations = more trouble). Soon enough these were ASP shops, even though it was almost accidental. Few of them really seriously evaluated the various alternatives.
Of course this was by design: Microsoft, who I spoke about earlier, understands this resistance to learning well. They have entered countless markets with seemingly inferior offerings (at least at first), but because it's there (Microsoft used to rely upon "everything on" by default) and it's easy to use, the marketplace adopts it. SQL Server is a fantastic database system (I personally believe it was one of the best, and is now the best with SQL Server 2005), but a lot of its growth came about largely because it was a trivial install with a simple, ultra-low barrier to entry GUI: Joe Developer installs it from the MSDN discs, prods it for a while, and soon enough he's building the enterprise data system on it. All because it was so accessible and easy to use [Of course many of those database don't use transactions (or they don't properly), and they host terrible schemas, but it got it used]. On the Windows platform a lot of admins did the "install everything" technique, and slowly they sorted it all out and utilized it. This was the way that Microsoft entrenched itself into corporate networks.
Contrast this with other areas where Microsoft hasn't followed this philosophy, and where the results have been much less positive - Even for critical back-end technologies like Biztalk and Sharepoint (both of which yafla provides solutions and consulting for), where you would think it would be soberly analyzed by experts over months of analysis before deployment (and thus requiring significant upfront configuration should be a non-issue), they often see little adoption simply because the install or initial configuration discourages fly-by investigation. Without the initial investigation there is no one to champion it, so it goes unused (despite being fantastic products).
There are countless examples of products whithering because the first install required 40 steps, and then doing the first "hello world" type of project was an enormous hassle. On the flip side a lot of questionable technologies and solutions have permeated largely because it was usable immediately, with little up-front investment.
If you make software products, ensure that Getting Started is as painless as possible, and advanced customization options are saved until the user has some experience with the product (literally it should install and configure everything, and start the user off with a Hello World template solution): Even if your customers will need to spend hundreds of man hours specializing it for their needs, they need to see something they can poke at and interact with almost immediately, giving them a sense of accomplishment to motivate them to continue on.
Once you've gotten the initial time investment, it's much, much easier to require a more involved understanding, and to demand that the user commit themselves to some educational time by the fireplace with the documentation.
We're a very impatient bunch these days, and this is critical if you want success.
If, on the other hand, you're looking at potential markets for software products, examine the usage patterns of PVRs versus VCRs - While the software world might seem full of existing solutions, really the field is wide open for usable solutions. Make an easier to use mousetrap and much of the world will beat a path to your door.
Tagged: [Software Development], [Programming], [Software-Development], [Usability]
In many ways the rampant podcasting enthusiasm reminds me of the big "push" furor back in the mid-90s, with everyone racing to incorporate the quickly abandoned channel technology (though it re-emerged as the influential and prolific, simplified RSS years later), all desperately trying to get a piece of the short-lived PointCast-style action.
The essence of podcasting - the most important benefit to many users - is really nothing more than the so-called Long Tail of audio files: Anyone can create an audio file (usually an MP3). From a listener perspective, no longer do you have to sit by the radio at a set time to listen to the talk show produced and distributed by the few elite with the money and the power to run a radio station. Instead, you can now subscribe to a wide array of content from around the world, created by both the aforementioned mega-media firms, but also by a guy in his basement talking into his microphone.
Technically podcasting is the inclusion of file references into the so-called "push" technology RSS, which usability-wise means that instead of endlessly searching around websites looking for audio files, manually downloading and then transferring files to your player, your podcast client software automatically detects when new audio files are available for the feeds you've subscribed to, it usually automatically downloads it (alternately it may provide you with a synopsis of each show, letting you manually select which ones you're interested in), and often even transfers it to your audio player (e.g. mp3 player, iPod) the next time you sync. The definition of podcasting has been expanded to include virtually any sort of media (or even non-media) attachment, expanding the scope to an unusably vague level, so I'm just going to focus on the audio aspect because that's the prevalent context.
As mentioned before regarding usability, small usability improvements can dramatically change the usage of a technology. In the case of podcasting, the theory is that while there have been audio programs available online for years, "push" enabling it would dramatically increase consumption.
Personally I don't think usability has ever been the limiting factor for audio files - It's more efficient for me to browse IT Conversations on occasion than it is for me to find a selection of good feeds to subscribe to, and then spend all of that bandwidth and memory space on a bunch of podcasts of uncertain quality and topic (even if I like a particular podcast feed in general, the likelihood that a particular episode is going to interest me is actually low). I don't even subscribe to IT Conversations' feeds - despite it having one of the best content records in the business - because the majority of the interviews aren't of interest to me: For every interview that intrigues me, many more are in a domain or with a personality that I can't allocate the time to focus upon.
I'm not going to eat the gruel just because it's what they happen to be serving today.
Is the content and distribution problem really the reason you don't have more talk radio in your life?
At a more fundamental level, though, podcasting is primarily a creation and distribution expansion of the previously mentioned talk radio. Is the content and distribution problem really the reason you don't have more talk radio in your life? Do you even know what talk radio programs exist in your area, available 24 hours a day from any tuner available?
Probably not.
Talk radio is something that most people aren't interested in. Talk is something that is difficult to consume without a good amount of your attention (I've found it close to useless - and destructively distracting - playing audio interviews in the background while working), it's difficult to efficiently vet (e.g. I can jump to a blog - or scan a newspaper - and know what interests me or not in seconds. A podcast requires some time to gauge its usefulness in your life), and it's often far less efficient than the alternatives. I can absorb someone's point from their writings enormously more efficiently than I can listening to them ramble on about this and that. It's generally difficult with audio files to jump to the pertinent parts that interest you (there are seldom even indexes or transcripts), so you have to take the chaff with the wheat. It's like that guy who leaves the long, rambling voicemail messages, in which are hidden a tiny nugget of useful info, instead of just sending a concise email.
If it's slow to parse, difficult to scan, and requires a fair degree of one's attention, the reasonable expectation nowadays is that it should have useful, informative video going along with it to increase the utility and value. The .NET Show is a pretty good video feed - with a great transcript that lets me jump where I want with ease to avoid the filler - though of course it's infrequent enough, and covering such a variety of topics, that any sort of automation is useless for it: I just visit the site every month or so and see if the latest outing interests me. While one month might be great, the next might be 90 minutes of someone pushing some questionable vapourware with a delivery promised in 2 years.
Of course sometimes rambling in audio interviews - the filler - is extremely valuable, and people betray information and convey knowledge that they would never have put into words - some of the conversations with industry veterans and superstars on IT Conversations are brilliant for this - but in general talk is not an efficient information medium in an information domain. Highly technical audio podcasts are truly absurd.
Remember the excitement about webcams a few years back? Several sites made it easy to find people's webcams, so the presumption was that we would all start consuming. For a short while it was true, and people entertained themselves looking at downtown webcams, goofy people with webcams, and so on. Then the interest faded, and we realized that it really wasn't that interesting.
This has repeated in a variety of technology spheres, where a simple repackaging of content that otherwise had little interest earned short-term euphoria and early adopters, but quickly fizzled out as the buzz and the eliteness subsided.
The novelty quickly wore off, and the utility of the underlying content failed to maintain any level of continuing support.
Tagged: [podcasting], [podcast]
I've come across this question quite a few times.
I have rows with lots of columns, and would like to split it out so that each column is a row
Imagine a scenario where you have a wide table that you'd like to normalize, at least in view or faรงade (or perhaps in a data transformation layer) - You'd like to un-pivot it, rotating columns into rows.
For a sample, I'll use the questioner's scenario of a Person table with a variety of attributes. Don't get hung-up on the table or whether it's already normalized (the sample came directly from a user who had a rather unique need), the point is simply rotating columns into rows.
| ID | FirstName | LastName | Age |
|---|---|---|---|
| 1 | Bob | Jones | 32 |
| 2 | Jeremy | Jones | 2 |
| 3 | Laura | Croft | 26 |
| 4 | John | Dingbat | 22 |
You'd like to return a set like the following:
| ID | Property | Value |
|---|---|---|
| 1 | FirstName | Bob |
| 1 | LastName | Jones |
| 1 | Age | 32 |
| 2 | FirstName | Jeremy |
| 2 | LastName | Jones |
| 2 | Age | 2 |
(rows truncated for some brevity)
SQL Server 2005 offers the UNPIVOT operator of the FROM clause, which can made quick (albeit unintuitively and inflexibly) work of this specific need.
SELECT
ID, tblPivot.Property, tblPivot.Value
FROM
(SELECT ID,
CONVERT(sql_variant,FirstName) AS FirstName,
CONVERT(sql_variant,LastName) AS LastName,
CONVERT(sql_variant,Age) AS Age
FROM Person) Person
UNPIVOT (Value For Property In (FirstName, LastName, Age)) as tblPivot
The use of the derived table in the FROM clause is
purely to cast the columns to a common data type, as this is a
requirement of the UNPIVOT operator. Otherwise all of the source
columns would need to have the same type (precisely the same
type).
Note that the IN list has to be a literal, concrete list - you
can't pass a table variable or subquery. Always perplexing when
they limit these sorts of operators in this way.
With SQL Server 2000 you can do this via simple unions or temporary tables
SELECT
ID, 'FirstName' AS [Property], CONVERT(sql_variant, FirstName) AS [Value]
FROM
Person
WHERE
FirstName IS NOT NULL
UNION ALL
SELECT
ID, 'LastName', CONVERT(sql_variant, LastName)
FROM
Person
WHERE
LastName IS NOT NULL
UNION ALL
SELECT
ID, 'Age', CONVERT(sql_variant, Age)
FROM
Person
WHERE
Age IS NOT NULL
In this case we've made the common type sql_variant, though obviously you should alter according to your data. We've also decided to eliminate null values (so there aren't null property rows), though that depends upon the need.
Another option is to make a programmatically
flexible alternative that automatically adapts to the schema of the
table (within constraints). For instance consider the following
script.
SET NOCOUNT ON
DECLARE @table sysname
SET @table = 'Person'
DECLARE @id_field sysname
SET @id_field = 'ID'
DECLARE @sql varchar(8000)
-- create the schema of the resulting table
SET @sql = 'SELECT TOP 0 CONVERT(int,0) AS [ID], '
+'CAST(0 AS nvarchar(4000)) AS [Property],'
+' CONVERT(sql_variant,N'''') AS [Value] WHERE 1=0 '+CHAR(10)
SELECT @sql = @sql + 'UNION ALL SELECT '+@id_field+', N'''
+COLUMN_NAME+''',CONVERT(sql_variant, '
+'['+COLUMN_NAME+']) FROM ['+@table+'] WHERE ['+COLUMN_NAME+'] IS NOT NULL '
+CHAR(10)
FROM
INFORMATION_SCHEMA.COLUMNS
WHERE
TABLE_NAME = @table
AND COLUMN_NAME <> @id_field
ORDER BY COLUMN_NAME
IF (LEN(@sql) >0)
BEGIN
EXEC(@sql)
END
In this case it uses the object schema, though you could alter it to go against a property table or the like.
Standard disclaimers about injection attacks and all of that apply (presumably you won't be calling this with untrusted input), and of course it won't work if you have composite keys, or if you have so many columns that the resulting SQL exceeds 8000 characters. Adapt accordingly. It also does no sorting, so add as you need it.
Tagged: [SQL Server], [SQL-Server]
I've been noticing something interesting with Google lately - While the rankings of this site have been increasing, the number of search engine hits against blog entries has actually been dropping: A week ago several entries in this blog were among the first page results for a number of terms (albeit less common terms), whereas now they've virtually disappeared. Given that other parts of the site are still seeing significant search engine directed traffic (in fact more than ever), it clearly isn't anything site-wide.
What I suspect is that Google has started identifying content as blog/not blog, as has long been anticipated, and if it's perceived to be the former then it is de-valued a degree. Identification could be as simple as checking for a synchronized RSS, or elements like calendar controls and the like. If it looks like a blog, reads like a blog...
There is a legitimate reason for that sort of segregation: The promiscuous linking of bloggers has drowned out `traditional' content, so much so that many searches were going to blog entries that happened to mention something in passing, even in a content-free, largely useless manner, making the use of search engines a frustrating, less-effective exercise. Discussion groups have been flooded with commentary about evil bloggers polluting the Google rankings (blaming bloggers for what is, in essence, a search engine problem).
Naturally Google's first step was to give bloggers a `home' (the Google blog search), and step two, I suspect, is to start cleaning up the search results.
If this is true, on the one hand I'm happy about it - it means that every search result isn't going to return every random MSDN blogger that's highly ranked just for being a part of the conblogation, but on the other hand it punishes those who use a blog format as a content management system of sorts.
Anyways, because I like appearing in the search results, I've created a new category and have started checking off "best of" posts. Through the magic of two XSLT transforms against the RSS of that category, and a bit of customization, it's now being replicated in non-blog-form over at http://www.yafla.com/dennisforbes/index.html. I've SEO'd the path and file names, and of course set appropriate titles on the documents (given that it's a single item per file I can do this), so content will definitely see more seach love over there. The layout is a bit ugly right now, but given that it's just a templated, dynamic transform I'll clean that up when I get the time.
One of the huge stars of the early Internet was e-cards - static, animated-GIF, or Flash alternatives to a standard ink and paper Hallmark card, not to mention that you could save yourself a couple of bucks and the hassle of going out and buying and mailing a traditional card (the biggest boon to men like myself was that you could quickly send one off on the day in question - no event pre-planning necessary).
One of the biggest successes of the e-card phenomena was Blue Mountain. My first experience with Blue Mountain was actually by mistake - I was looking for some ski conditions, and instead of http://www.bluemountain.ca/ I entered http://www.bluemountain.com. Of course I capitalized on my mistake, immediately sending some goofy e-cards to friends and relatives. Of course many of the recipients started using the service as well. I suspect that the tipping point for that company - the contagious source vector - came when winter rolled around in Ontario and the powder was just right, and lots of misdirected Ontarians figured they might as well use the service since they were there.
During those early days e-cards were sent in bulk. It was good times in the e-card business, and marketing was easy: Every recipient was encouraged to send their own e-cards, so growth was exponential.
Excite @ Home bought Blue Mountain for a blistering $780 million dollars in 1999.
Of course, as with most quick-ascent fads, people started to question e-cards: It the sentiment was so cheap, and required so little personal effort, was it really a substitute for a real card? Was it just a thoughtless form of spam, quickly discarded and ignored? It didn't take long for that sort of feeling to pervade the marketplace.
If this were an episode of Behind the Music, dark and disturbing music would be playing. The Dire Straights of e-cards were upon the industry.
Excite @ Home unloaded Blue Mountain for $35 million in 2001. If the business were individually valuated today, I highly doubt it would come anywhere close to even that number.
This thought came to mind given the almost-absence of e-cards I've seen this holiday season. Perhaps it's just me, and my network of contacts is unique in its reliance upon traditional cards, but it is a remarkable contrast. I did receive one e-card - from a web host - and quite honestly it bordered on a bit offensive getting a holiday greetings card that I know was spun off from a mass mailing script.
You just finished a gruelling six-month project to create the Greatest Software Widget Ever Made. Your blood, sweat and tears have been invested into what you believe is a first-rate solution, whether solving a corporate need, or building a better mousetrap to bring untold riches to your ISV.
You email news of your accomplishment to peers and/or clients, proudly sitting back to await the certain accolades.
Amidst the expected congratulations, one reply makes you uneasy. "So it basically does what Project X does?" it asks.
Surely they must be mistaken, you think.
You fumble through the feature sheets for Project X to discover that, sure enough, on paper it does everything that your solution does, and in some ways it is arguably superior: Maybe it supports a richer set of features, is cross platform where yours isn't, or it's a component of a more-complete integrated solution where the whole is greater than the parts.
On paper, at least, it is a better solution.
If you're an ISV, you've just discovered that you have more competition than you thought you did. This could impact your market in a wide range of ways.
If you're a corporate developer, it could simply be a demotivating signal of time wasted (developers are heavily motivated by seeing their solutions doing "good" in the world. Dumping code they invested time and passion into is heart-wrenchingly demotivating. "What have you been working on?" "Well, I spent the last year working on a project that was dumped for Microsoft BizPoint 2009 before delivery"); it could just be ammo for the office Machiavellian (I've was criticized in the past by just such a coworker for not leveraging a "possible solution" that wasn't even invented until two years after my project was deployed, so such Machiavellian Jr's aren't even bound by the constraints of time); or it could be a career killer.
In the corporate space things can get even uglier, as products from the big names like Microsoft will be preferred, however ill-equipped for the task they actually are: If they marginally seem to apply to the problem, there will be those who push for it. Sometimes this strategically makes sense (e.g. if you adopt a new product early, it'll likely evolve quickly if it's developed by a company with the resources that Microsoft has, for instance), but often it's just corporate hubris. Some organizations have a love-hate (mostly hate) relationship with their IT department, so any opportunity to undermine and reduce the dependency on them, even if it involves a more expensive, less-flexible, less-empowering solution, will be pursued. I worked at one shop where a large team of developers worked for years perfecting and expanding in-house solutions, while at the same time the organization continually and openly quested to replace everything they did and were doing with externally sourced solutions. The effect on motivation was profoundly negative, but it was the result of a Better Not Be Invented Here mentality, coupled with a negativity opinion of IT.
Of course such an overlap of functionality or use isn't limited to whole products. It applies to even the smallest component of our projects.
Developers face this sort of issue regularly: From cryptography libraries to database abstraction tools to MVC frameworks to simple coding standards - For virtually every single need, there are solutions that purport to solve all ills and fulfill all needs. Somewhere amidst the 100,000+ version 0.1 projects on sourceforge, the huge catalog of software and feature lists provided by organizations like Microsoft and Oracle, or the millions of projects on the web, and even amongst the libraries and frameworks already included with our platform, there are possible competitors.
From a more optimistic perspective, they are possible allies - code and existing research and knowledge that you can leverage to make your solution better. Why waste time building a dubious non-core cryptography function just to enable security, if you can just use the System.Security.Cryptography collection of classes? Why re-invent the wheel when a lot of standard solutions are crystallized in industry patterns?
The problem is that you have to know about the knowledge, competitors and/or allies that you can leverage.
Several months back I wrote that internal code reuse can be dangerous, the premise being that most teams don't spend enough time investigating what is already available (often available in a superior, more widely-known fashion) - be it coding standards, frameworks, or whole projects, a lot of the code base in many organizations is completely redundant, inferior duplications of what already exists, created purely out of lack of awareness. Even when resources are within grasp they're often ignored - A huge number of in-house .NET "utility libraries" duplicate what exists in the .NET Framework. All because no one bothered looking through the admittingly-massive MSDN Library before undertaking a task themselves.
While sometimes this occurs because of the Not Invented Here syndrome, more frequently it's simply ignorance - Either intentional ignorance (such as not bothering doing proper competitor/options research before getting started), or unintentional ignorance (there is such a huge number of projects out there, often with convoluted explanations of what they do, and difficult and time consuming setups to test it out yourself, that it can be impossible to know what already exists. For some small components and projects it can literally be faster to just do it than it is to investigate the alternatives).
Huge code repositories grow larger with second-rate solutions, products are developed that enter the market dead-on-arrival, and developers have the passion beaten out of them.
As bad as all of this sounds - making solutions to discover that they're second rate or obsolete, or huge internal code repositories filled with duplications of better alternatives - the problem exists even where these problems aren't evident (in fact a secondary-effect occurs because of the prevention of these issues): Many software developers are simply decision-paralyzed. They're unable to proceed with any project because the number of possible standards, components, and frameworks that they need to consider is unending.
This is made worse by the fact that there are tens of thousands of software products and components making claims that they can't back up (especially in realm of nebulous, all-empassing applications. These high level applications often require tremendous configuration and programming to be usable, but the appearance is that they're a drop-in-place solution). Sourceforge, for instance, is full of tens of thousands of version 0.1 applications, where the purported feature list could be be described as a wish list. Other products entail tremendous expense, or bring along undesired dependencies or complexity.
Researching, and then understanding every caveat and issue with every potential solution is a huge undertaking.
If only it were so easy to simply rattle off a solution.
Nonetheless, a huge step in the right direction would be simpy allocating adequate time upfront for "competitor research" before committing to a project, or even before undertaking a component. This is a tremendous undertaking these days, yet in timelines it's often forgotten or considered satisfied by a quick 5 minute Google search.
If you're developing a web application to store documents, could it be satisfied by Sharepoint? Community Server? Zope? A derivative of Media Wiki? If you've committed to one of those projects, but you just need to extend some of the functionality (say you want to display the EXIF data of photos), have you committed the time to investigate the alternatives?
For virtually every need, there are a slew of theoretical solutions. The truth, however, is that many of those solutions aren't a good fit - many of them are simply terrible - but you need to be informed and prepared when peers, coworkers and clients ask about them in comparison.
Even if you don't find an appropriate solution already available (in most cases you won't), document all of your findings: If Biztalk looks superficially like it's the right solution, but for some reason it isn't appropriate, be prepared for the inevitable grilling you'll get every single time someone who knows about Biztalk and then hears about your project gets within earshot.
Be prepared!
Tagged: [Software Development], [Programming], [Software-Development]
