By Jim Collins

300 pages

http://www.amazon.com/Good-Great-Companies-Leap-Others/dp/0066620996

The content in this book is based on a five year research project in which Jim Collins and his 21 person team looked at over 1,400 companies, read 6,000 articles, and conducted an absurd amount of interviews.  Unlike other books of this type, the team didn’t go into it with preconceived ideas or theories about business they were looking to prove.  Instead they tried to simply conduct the research with clear minds and then make “empirical deductions directly from the data.”  This fresh approach yielded some surprising results.

Collins and his team combed through every company that ever made the Fortune 500, looking for those who had made a “good-to-great transition.”  They clearly defined that transition as a companies’ having “fifteen-year cumulative stock returns at or below the general market, punctuated by a transition point, then cumulative returns at least three times the market over the next fifteen years.  We picked fifteen years because it would transcend one-hit wonders and lucky breaks (you just can’t be lucky for fifteen years) and would exceed the average tenure of most chief executive officers (helping us separate great companies from companies that just happened to have a single great leader).  We picked three times the market because it exceeds the performance of most widely acknowledged great companies.  For perspective a mutual fund of the following ‘marquis set’ of companies beat the market by only 2.5 times over the years 1985 to 2000: 3M, Boeing, Coca-Cola, GE, Hewlett-Packard, Intel, Johnson & Johnson, Merck, Motorola, Pepsi, Procter & Gamble, Wal-Mart, and Walt Disney.”

The research team found 11 companies who made this transition, and picked them apart to find the comment elements.  I won’t give away the ending, but trust me … this one is worth the time.  No wonder Collins has sold a gazillion copies.

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.