You know what I mean ... every IT professional has been faced with this dilemma, and you have probably known radicals on either side of the argument.  I admit that I myself have swayed pretty wildly on this issue in the past, but after some serious thought and research I think I have boiled this debate down to its crucial elements.  I will refrain from the overused (but often true) adage of "it depends."  One article I found written by Bruce Lewis presents a good overview of the argument.  It was the primary basis of the drawback sections below, but I trimmed it down some and added parts I thought were missing.

Drawbacks of the Buy option

Companies pursue the buy option because it will be easier and faster than building custom software. Nevertheless, buying the right software is a project in itself.

• Evaluation: When buying software, it is often difficult to determine which packages you want to look at seriously. Marketing literature is often vague and unhelpful. If you're lucky, you can download an evaluation copy either by paying a nominal sum, or by providing personal information so that their marketing people can contact you. If you're unlucky, you'll have to negotiate with them to obtain an evaluation copy.
• License Hassles: Once you've settled on a particular product and installed it, the particulars of the licensing agreement begin to bite you. If you use a license server, will you be unable to use the software when that server is down? The last thing a serious operation needs is another point of failure. If you're licensing server-side software, do you need another license for a hot spare? What if you want to do testing on a separate server? What happens if the license is tied to some kind of hardware ID and a disaster forces you to restore from backup onto different hardware? A site license might be helpful, but what if you have users who may want to run licensed client software from home through their own ISP? Does the site license cover that case?
• Lack of Customizability: At best, buying off-the-shelf software gives you most of the functionality you want at relatively low cost, but there's always some functionality you wanted that isn't there. Often there are simple changes that could make the software much more suitable for your task. Measured over the lifetime of the software, such changes might save the users a lot of time (a.k.a. money), but you have no way of making those changes.
• Obsolescence: Ever been stuck with a piece of software you can't legally run anymore? Ever sink money into "the standard" only to have its support discontinued a few months later? People who buy software because they think it will protect them from obsolescence often get a rude surprise.  This happens because bought software, if it stops generating enough revenue to support marketing, legal and other departments necessary to run a software company, dies completely. It's unlikely that another company will pick it up.
• Urgent Bugs: Even the best-laid business plans can be waylaid by software bugs. What happens then? No amount of money can force a large software company to put your bug at the top of their list, no matter how urgent it is for you.
• Integration: It is often difficult to integrate off-the-shelf software with other business applications, and it is sometimes even necessary to create an additional software layer to help the two communicate.  And even if you can get it working with the rest of your stuff, several different pieces of software that have been patched together are typically complex and less stable.

Drawbacks of the Build option
To a developer, this almost always seems like the obvious choice ... because you design every detail, in the end you have exactly what you wanted (hopefully).  But this shouldn't be "the default" decision either, because there are significant cons we sometimes conveniently forget about.

• Lack of Maintainability: The biggest nightmare of software built in-house or by a contractor is that the author will leave, and nobody else will know how the code works, how to recompile it, or sometimes even where the code is. This situation means job security for the author, but insecurity for the organization.  Beyond that, after software has been built there is a “hidden” cost of the ongoing maintenance and support required that most people forget to weigh in the decision.
• Lack of Standardization: There's a training cost associated with software you build yourself. New employees need to be brought up to speed on your system, even if they've used software elsewhere that performs similar functions. This is one of the most common reasons why people choose to buy software even if it doesn't completely fit their needs.
• Obsolescence: You usually choose to build your own software when nothing else is available to fit your needs. But what happens if off-the-shelf or free software later becomes available that would fit those needs and do even more? You find yourself supporting an obsolete product.
• Urgent Bugs: Build-it-yourself software does have an advantage over bought software in that you can fix urgent bugs yourself. The down side is that you have to drop all the other important things you're doing to fix the bug, and usually only one person knows the code well enough to fix it.

What It All Boils Down To

“Buy rather than build where differentiation isn’t critical” - Joe Morgan

That is a quote that really sparked me to write this article.  I ran across it in the September 17, 2007 edition of Information Week, in their “CIO Values” column, which highlights a different CIO in every edition.  This is part of what Joe claimed as his guiding principles (the other part was to create services for reusable business components … also important).

I love that quote because it is so clear-cut and simple, but let me try to put some more flesh on the concept I am trying to drive home.  If the functionality you need is something that is unique to your business, core to your company’s strategies, and provides a significant competitive edge over competitors … then even a slight difference between the ideal software you could build and an off-the-shelf product is critical and might be enough to justify building a custom solution.  However, if the functionality you are trying to attain isn’t something unique to your business, and there is a product out there that may not be completely ideal, but includes most of the elements you are looking for … then “differentiation isn’t critical” and you should buy it.

I think of Joe’s quote almost every time I find myself questioning whether we should buy a particular software package, software components, or tools.  Of course we could probably build anything if we wanted to dedicate the time to it … but is that always the best long-term choice for the company?  Probably not.  There has to be a balance there.  Buy software when you can, and build it when you must.  Ask yourself "Is this something unique to my business, and is the differentiation critical?"

Back in March, I attended the spring DevConnections conference in Orlando (which was awesome).  I sat in one of Scott Guthrie's sessions named "ASP.NET 2.0, ASP.NET AJAX, and Visual Studio 2005 Tips and Tricks."  He showed a ton of cool stuff in that session, but one of the things that caught my eye was the new $get function available in ASP.NET AJAX.  It is really just an alias to the document.getElementById function in the DOM. 

However, I saw some potential in it that might solve one of the issues that constantly frustrated me when using master pages ... so I sent Scott and email to suggest some functionality that his team might consider building into future versions of the framework.  To my surprise Scott emailed me back the next day (which was a Sunday) with a really simple work-around that has really helped me out.  So I thought I would share it with the rest of the world.  Here is the guts of my original email followed by Scott's response:

It is my understanding that the $get command is simply a shorthand version of the document.getElementById() method.  One thing that has been frustrating since I switched over to the ASP.NET 2.0 way of doing things, is when you use MasterPages you have to account for how ASP.NET will rename your server-side elements when it renders them to the client.  Since I do find myself writing quite a bit of JavaScript, finding and accounting for these fully qualified names is probably more of a hassle than it should be.  Is there any way you guys could work into the .NET Framework v3.5 a way use the $get command to retrieve values without having to use their fully qualified name.  I realize one option is to render JavaScript from the server to dynamically insert the assigned ID, but that seems like quite a bit of overhead, and if it was built into the framework your team could also tune it for better performance as well.

It seems that MasterPages are so useful, but as JavaScript becomes more prevalent throughout web applications I am tempted to revert back to the “old school” approach of PageStart and PageEnd user controls to encapsulate a page instead of MasterPages.  I have put a lot of thought into this and realize it is a complicated problem to solve, but I just wanted to mention it because I think it is really important and will become more important with the rise of technologies like AJAX.

Hi Cal,

Right now $get() is indeed just a short-cut for document.getElementByID().  We are looking to improve the ID naming of elements over the next year to give you more control over how they are rendered.

In the meantime, you can use a technique where you render the client name into JavaScript using the Control.ClientID property:

   var myControl = <%= MyControl.ClientID %>;

You can then write this JavaScript code to dynamically load the control regardless of where it is used on the page:

   $get(myControl);

Hope this helps,
Scott

var txtName = $get('<%= txtName.ClientID %>');
txtName.value = "Lorem ipsum";

This article provides step-by-step instructions on how to add a network printer to a computer running Windows Vista.  This example uses "LPR" protocol (stands for Line Printer Daemon) to communicate with the printer.  It's fairly straight-forward, but I just wanted to write down the steps so I didn't have to "re-learn" it every time.

1. Click on the Windows Start Button and then "Printers" 

2. Click on the "Add a Printer" menu item

3. Click the "Add a network, wireless or Bluetooth printer" option

4. Your computer might be able to discover the printer automatically, but I never had any luck with that ... so I just clicked on "The printer that I want isn't listed" option.

5. Choose the "Add a printer using a TCP/IP address or hostname" option

6. Find the IP Address, TCP Port, and LPR Queue Name for the printer you want to install.  I am using D-Link's DPR-1260 RangeBooster G Multifunction Print Server to host the printers on my network.  However, these instructions aren't necessarily specific to this print server.  You should just find the screen on your print server that provides info like the stuff highlighted in the screenshot below.  These values will be used in the next few steps. 

NOTE: Although my extremely frustrating experience with D-Link's WBR-1310 Wireless G Router has completely shattered any confidence I had in D-Link, I have to admit I haven't had many problems at all with this wireless print server.  It hosts up to four USB printers, and even allows me to still use the scanner on my HP PSC 2100 All-In-One ... although since that particular printer isn't in the compatible multifunction printers list I could only get it to work using "Scan" tab in the D-Link interface shown below.

7. Type the IP Address and Port name in the wizard.

8. Choose the "Custom" option, and then click the "Settings" button.

9.  Set the protocol to be "LPR", and then enter the LPR Queue Name we found in Step 6.

10. Choose the appropriate printer driver.

11. Give the printer a friendly name.

12. Windows starts installing the printer on the machine.  Wait for it to finish and click Next.

13.  Choose whether you would like to share the printer with other computers or not.

14.  SUCCESS!!!

By Alexandru Serban
404 Pages
http://www.amazon.com/SourceSafe-Software-Configuration-Management-Practice/dp/1904811698/

Publisher’s Description: This book uses a real-world case-study project to teach you how to manage software configuration efficiently using Visual SourceSafe 2005, Microsoft's Software Configuration Management (SCM) solution for independent developers and for developers working in small- and medium-sized teams. It also provides a best-practices reference on using SourceSafe 2005 to manage the software development lifecycle.

My Thoughts: Why aren’t there more books on SourceSafe?  Moreover, why is SourceSafe so anti-intuitive?  I realize it has seamless integration with Visual Studio, but actually setting up projects in it is a painful process, and forking code and merging branches isn’t that easy either. 

This book does explain how to do these things, but it isn’t written very well.  There are a ton of screenshots that let you easily follow the author through some examples, but a lot of them could have been excluded.  With a good editor, this book could be trimmed down to about 100 pages of real meat.  The author goes into too much detail about the 43 different ways to do something, when really they are all extremely similar or he is going to introduce the way you should really do it at the last of the chapter.

One crucial topic the book left out was how to add stored procedures to SourceSafe.  That is one of the most attractive things about it, and it was left out completely.

But, there isn’t a better book out there that I know about … so what can you do?  It is better than the built-in help in SourceSafe, so it was probably worth the money for me and earned a spot on the bookshelf.  But it wouldn’t take much for someone to through together a better book, not to mention better software.

In fall 2006 we were looking for a way to equip our inspectors with an always on “high-speed” internet connection in the field.  We were planning on getting them setup on ruggedized tablets, so they could complete checklists about various construction tasks that were customized for each home.  This would be used to not only track the progress of homes, but fully automate the production process.  When one checklist was finished for a home, a checklist for the next construction task would be created and would show up on another inspector’s tablet.  We would also be able to tie email notifications to give our trade partners a heads up when it was almost time for them to be involved with a home, and use them to allow inspectors to approve payment for materials and labor out in the field.  So with all this, we really put a lot of effort trying to make it work.

During this time in Lubbock, the data service available from cell phone companies was extremely slow (around 56Kbps), which would was too slow for what we were hoping to do.  At first we were thinking about writing an application that could run online or offline, and when it came into a hot spot it would sync up with the live database.  The inspectors are away from the office all day, so we thought about creating a mesh wireless G network that completely covered some of our larger communities.  This turned out to be pretty expensive for outdoor equipment, and seriously sounded pretty hinky.  So when someone told us about a new company named Xanadoo that might be able to help us out, we were all about it.

I called Xanadoo, and they sent one of their top people in the area (I think he was also a stakeholder in the company) to the office to talk with me.  I explained what we were trying to do, pointed out the locations of our major communities, and they assured me they would be able to provide us with the service we were looking for.  They said their service should be able to provide our guys with a connection anywhere in Lubbock County, which seems more than adequate.  They could provide small wireless modems that received a signal from unidirectional antennas around town.  In fact, they were so confident they wanted to sale me a few of their modems right then.  I told them I would like to get a complementary modem to test with first, and it took them a couple weeks to get one to me. 

Since they were so confident this would work, I moved forward with developing this solution.  When I finally got the modem, our system admin and I hooked it up to a laptop and decided to drive around town and see what kind of connection we could get.  Needless to say we were a little surprised.  I had got them to point out a few places locations of their unidirectional antennas, and we drove near one and were able to get a connection.  However, if we were ½ a mile or more away from the tower (or directly below it) the connection was either unreliable or non-existent.  Their service didn’t even get close to covering the city of Lubbock, much less Lubbock County.  We thought we might have had a faulty unit or be trying to use it incorrectly, so we went to their offices on 82nd St and talked to an employee.  We told them we were having some trouble getting a signal, and we couldn’t even get one in their parking lot.  They acted surprised, and said of course we weren’t getting a signal there … there is never a signal out there.  What?

It turned out we were doing everything right, and their service simply didn’t match up with what they claimed.  We tried a few external antennas, but eventually abandoned the idea after we couldn’t get the Xanadoo office to return our phone calls. 

I can’t say how disappointed I am with Xanadoo.  A few friends have asked me if they should try Xanadoo, and I always give them an emphatic “NO.”  Not only do they have subpar service, but they also chose to flat-out lie about what their service could do even when they were fully aware they were not telling the truth.  Thinking back, on the original visit the rep claimed one of their current clients was using a modem in a vehicle all the way from Wolfforth.  That is physically impossible with unidirectional antennas at that distance, so that must have also been a lie.

I have heard some people say they had an decent experience with them, but people’s experience seem to vary wildly based on how close to the antenna they were and what obstacles there was between them.  If there was any other type of data service you could get, I would definitely try it … I might even opt for dial-up instead of the horrible service and experience I had with Xanadoo.