Re-Blog : The cost of reinventing the wheel

Since my blog content at my old company’s site seems to be selectively disappearing, I’m grabbing the content that I can and re-publishing here, before it all goes away. This was originally published on June 1st, 2009.

The reason for this rant?  I see a shocking number of people objecting to buying off-the-shelf software because it is “cheaper” to build it themselves.  An argument that boils down to a simple ratio: the value of your time compared to the complexity of the problem.  Time is always money; “complexity” here includes both a fair assessment of the difficulties you’re likely to encounter, as well as whether or not the requirements are met by existing products.  Being a database dork, one business problem where this argument bubbles up a lot is when someone needs a database schema comparison tool (back when I was a web page guy, the most prominent argument surrounded file upload controls).  The question is typically along the lines of:

“Anybody have a script to compare two databases and synchronize them?  I know about the tools that are available, but my budget is $0.”

My predictable response includes the following:

  • If you’re going to spend time on it, your budget isn’t really $0.
    Your time is rarely free, and most likely never.  Confirm this with those that approve and/or sign your paycheck.  If that’s you, then I take this bullet point back.
     
  • You will be learning from scratch.
    You are going to painfully learn all of the nuances of the problem, which others before you have already encountered and (hopefully) solved.  This is not exactly productive if the problem is complex.  Sometimes this is the point, but that is far more common in academia than in business.
     
  • You will have little to no support.
    When you buy a product, your license almost always includes support from the vendor.  Even without direct support (which can be fee-based or just slow), when you hit a roadblock with off-the-shelf software, access to peer-to-peer forums or even twitter can fill the gap, as other people using the product have probably come across similar issues.  With your own code, who is going to help you work around bugs or figure out why it works a specific way?  In that case, your support pipeline is your mirror.

Of course, there are plausible benefits to building the code yourself, some of which I’ve already alluded to:

  • Your budget may really be $0.
    Or put another way, you may be choosing between buying existing software and buying dinner tonight.  If there is no approval for software expenditures, then that’s simply a reality.  More on that below.
     
  • Your requirements may not be met by existing products.
    Let’s face it, not every need has been satisfied in the marketplace, which is why we see new products (and new features for existing products) cropping up all the time.  I feel this way about bug/suggestion/issue tracking tools – I have not seen “the one” yet.  We have used several, and while they are all lacking something (or many things), they are “good enough” because we do not have the time to invest in making that aspect better.
     
  • You may really want to get your hands dirty.
    In some cases, you want to learn the internals and enjoy the experience of solving the problem.  This is okay if you are taking a computer class, or working on a leisurely project.  But if you have an employer, this isn’t necessarily the best use of your time and the company’s money.  (I can’t resist the temptation to ask, “Is it good for the company?“)

Except in the most extreme cases, if you have no budget because your employer says so, it should not be very difficult to justify the cost of the software to the bean-counters.  This is in lieu of spending all those hours of your time not just solving the original problem but also dealing with all of the unforeseen issues that are inevitable … this costs them money as well, and prevents you from working on real problems that vendors can’t generically solve.  In case you are having difficulties in this area, consider not demanding the most expensive version or even the big ticket vendors… there are other vendors out there that offer more affordable alternatives.  This may come at the expense of reliability or feature set, but in a lot of cases will still suit your needs, at least in the short term.

For the specific problem I am talking about, here is a small sampling of products available that may prevent you from reinventing the wheel (including the “big ticket” guys):

Red Gate SQL Compare | ApexSQL Diff | Kentico Compare SQL | xSQL Object
SQL Delta
 | SQL Examiner | AdeptSQL Diff | StarInix Database Compare | SQLDBDiff
Simego SQL Admin Studio | Visual Studio Team Edition for Database Professionals
SQL Accord Community Edition | DbDiff (CodePlex) | Open DBDiff (CodePlex)
Berryware SQLMatcher | Embarcadero Change Manager | dbMaestro | IndusSoft WinSQL
Quest Change Director | DB Ghost | SQL Server Comparison Tool | DB SynchroComp

And no, this isn’t an advertisement for any of these guys, just a demonstration that the market does not always consist of just the one or two big guys you’ve already heard or read about, and that there is a product for almost any budget (some of these would pay for themselves after I’ve spent 30 minutes trying to reproduce their solution).  There are “free” solutions also, such as manually generating the scripts from Management Studio and comparing them with a variety of file-comparison tools (including those that ship with products you might already have, like Visual Studio).  But again “free” comes down to the difference between performing all of that work and clicking a button, and evaluating whether a “free” or “cheap” solution really fulfills all of your requirements correctly.

Every situation is different.  You will have to weigh the pros and cons of writing your own code to solve a specific problem; just make sure you understand the domain and the range of alternatives, so you can determine how likely it is that “writing a quick app by Friday” won’t snowball into a 6-month project.

Re-Blog : Using a Mac in a Windows World

Since my blog content at my old company’s site seems to be selectively disappearing, I’m grabbing the content that I can and re-publishing here, before it all goes away. This was originally published on May 29th, 2009.

If you’ve read any of my material on sqlblog.com or follow me on twitter (@aaronbertrand), you have probably already painted a clear picture that I’m a Windows-based database guy; more recently, though, I have been (at least indirectly) branded a crazy Apple fanboy… and deservedly so.  Here’s my story…

A few short years ago, the only Mac experience I had was with a 17″ iMac G5 (the first pretty iMac, not the UFO or the fishbowl), which I bought for web design and compatibility testing in my own personal projects.  (I did have the fishbowl-based  MacAquarium fish tank at work for a while, until I dismantled it when a snively and overbearing co-worker complained that the filter made too much noise.  Yeah, exactly.)  We had some G4s in the office back when we were still in Newport (we’re talking late 90′s, early 2000′s here, I can’t even remember if they were OS8 or OS9), but I had played with them barely enough to know that I preferred Windows.  At least at the time.

About two years ago, I realized that if I wanted to seriously start speaking out in the community, I would need to learn how to use a laptop.  Not that I expected such a transition to be difficult, but I was convinced that a small screen would annoy the crap out of me.  I shopped around, and while I could have gone with a piece of junk from Dell or HP (which probably wouldn’t even still be working as I write this), I decided to go all out and procured a 17″ MacBook Pro with 4GB of RAM.  I have to say that I fell in love with OS X almost immediately, and man, what a beautiful screen.  There were some little learning curve issues, like the location of the applications’ minimize/close buttons top left, the way the dock differs from the taskbar, and how closing a window doesn’t really close the application.  But these were easy to overcome, and I continued to use the laptop for web, e-mail, presentations, blogging… you know, not work stuff, but the reasons your mom needs a computer.

Then my company was bought and we were assimilated into a Boston office – translating to the fact that I would be working from home quite a bit, and would be expected to punch the clock during my commute (mobile broadband is great for checking in, getting a head start on diagnosing problems, and so on).  For starters, I needed to get my aging Dell Precision in my home office up to speed (or replace it), and find a way to do work from my laptop while on the commuter rail.  Remember, I am a Windows / database guy, so most of my work is done in Visual Studio and/or Management Studio – neither of which, of course, are available for Mac OS, one of the reasons not many of my colleagues have a Mac at all.  I was surprised at the media table at PASS last year, when I sat down next to Brent Ozar, who was sporting a MacBook Pro not unlike the one I had just pulled out of my ultra-rare SQL Server 2008 computer bag.  We didn’t really think much of it at the time (and I’m sure we both get our share of ribbing at such events), but it has been a running topic on twitter whenever anything Mac comes up within our collective circles.

Back to my work problem.  As it turned out, I found that I was most productive if I did not maintain a working environment at home, but rather kept all my critical files and projects in a single location on my workstation in the office.  This was partly because I got sick of transferring files between machines on flash drives, and partly because SourceSafe and other important shared resources could, at certain times, be excruciatingly slow and painful over the VPN – making it frustrating, if not impossible, to perform several tasks remotely.  So all I really needed was a Remote Desktop session on my workstation at work, which meant my machine at home simply became a dumb terminal.  In turn this meant that it didn’t matter what kind of machine it was, as long as it could connect to the VPN and support RDC.  For a while I tried to stick with a Windows machine (and used RDC on the Mac if I needed to be away from the desk), but as you might imagine from the tone of this post, I became increasingly more frustrated with Windows (and PC hardware in general) as time went on. 

Right now I have 4 Dells (3 Precisions and 1 OptiPlex)… the Precisions were $3,000 or more (one was nearly $5,000 at the time of purchase), and the OptiPlex was $600 (+ an inexpensive upgrade earlier this year – a better video card which doesn’t fit in the case, and 8GB RAM).  The OptiPlex is the only machine that is usable, and barely so; it is running the release candidate of Windows Server 2008 R2 (which you can download, however note that it is x64 only!).  Ironically that was by far the cheapest machine I have ever been involved in purchasing; the other three, while much more expensive, are either dead, gutted or both.  (And that iMac I mentioned above?  I donated that to work as a test machine, and it is still running stronger than many PCs purchased more recently have bitten the dust!)  Between crappy motherboards, bad power supplies and an utterly horrible experience with Windows Update/Microsoft Update, I had just had enough with Windows, and felt much more confident in Mac hardware.  I started to use only my laptop at home and on the train, and contemplated what I would do about having a workstation in my home office that might display a little bit of longevity for a change.

I had no interest in getting another machine that would run an x86 version of Windows… the Windows world is definitely moving toward 64-bit, and I am fine with this.  The trouble is, many vendors are not, and do not update their software and/or drivers to work on x64.  (So while you would have a hard time buying a machine that didn’t support x64, you would be wasting your money on RAM above 3GB if you couldn’t actually run x64.)  For most of my hardware this hasn’t been an issue, and by the time Windows 7 and Windows Server 2008 R2 hit the streets, I think the hardware and drivers situation will be well under control.  However, my main problem has been trying to connect to work from a Windows x64 box at home – and I did try for a while, believe me.  Cisco has furiously refused to provide a 64-bit VPN client for their older gear; and even if you wanted to try installing the 32-bit client, installation is blocked.  You can use AnyConnect if you have newer stuff (which we don’t), or you can pay for a 3rd party product like NCP’s SecureEntry Client (the demo of which I couldn’t get to work), but otherwise you are out of luck.

With all of these things in mind, when it finally came time to face the fact that I needed more than a 17″ screen to be productive at home, I opted for a Mac.  “You’re crazy!” was the most common response, when talking about it with friends and colleagues.  “How could a SQL Server dork use a Mac as their workstation?”  In reality, it would not be that much different than what I was already doing with my MacBook Pro.  I could establish a VPN connection (oh and Cisco *is* maintaining a VPN client for the Mac, which continues to work with their old gear), then start a Remote Desktop Connection to my workstation at work, and voila, except for the fact that I am limited to one screen, it is just like I am at work. 

So, I went ahead and bought myself the ultimate Christmas present:  A Mac Pro with two quad core processors.  I filled the three empty hard drive bays with three Western Digital 1TB drives, then added 16GB of RAM from OWC.  Shortly after that I filled up the rest of the memory slots with another 16GB of RAM from MemoryToGo (if you are buying a Mac, and Steve Jobs may have me killed for saying this, but I strongly urge you to buy it configured with the least amount of RAM possible, and add it after market, even if it means you have two or more sets of warranties to deal with … this RAM upgrade would have been over $9,000 had I purchased the machine that way through Apple, but only drained me of a bit over $1,000).  I’m not going to tell you about my displays, because I’d like to help you avoid getting drool on your keyboard.  If you haven’t already.  My motto is, why get something that is adequate, when you can spend a little more on something that will last longer and keep you happier in the meantime?  I’m not talking about a computer for a hobbyist, or your mom, but rather for those of you who spend many hours in front of one both at work and at play.

A few things are a little slower when I VPN and work remotely, of course; but this has more to do with the VPN and the network traffic in and out of the office, than the fact that I am using a Mac.  One common symptom is typing a query within Management Studio, inside the RDC window, and then watching the cursor slowly catch up.  But there are other options.  To summarize, if you are considering using a Mac even if everyone around you thinks you need Windows, you can:

  1. Do what I do most of the time: run a Remote Desktop Connection session against the workstation at the office, and work inside of it.  Several tasks I do in the host rather than within the RDC; for example, Word for Mac is just as capable as the Windows version on my office PC, and Entourage works just great for e-mail (just make sure you buy the right version of Office for the Mac; the home and student edition, for example, does not have Exchange support).  For Excel I still find the Windows-based version easier to use, but your mileage may vary. 
  2. Use development tools inside of a local Windows virtual machine.  You see, as long as I have a VPN up and running on the Mac (the host), I can set up any virtual machine to just piggyback on the host’s connection, and then work from there.  I shift the slowness factor from typing and display issues (which can be annoying) to pulling results over the VPN and local host (which can be a different kind of annoying).  Some people swear by VMWare Fusion, some use Parallels, and still others use the free VirtualBox (though I don’t know if it supports x64 guests).  You should try all three and see what works best for you… for me it is VMWare Fusion.  Also, I install Windows within Boot Camp, so if I really, really, really need to boot into Windows (e.g. to test Hyper-V stuff), I can.  Of course as long as I continue to be stubborn, and insist on running an x64 OS, in that case I won’t be able to connect to work. 
  3. Run a Management Studio-like tool within Mac OS, in many scenarios obliterating the need for a VM or a Remote Desktop Connection.  I started using Aqua Data Studio 7.0 last year, and initially was very impressed, but ran into some stability issues – one where I actually lost work (I want to stress that these were related to Apple’s Java VM and were not the fault of the vendor).  I just installed version 7.5 today, and am giving it a whirl again.  There are other tools you might try, such as RazorSQL.  If you have experience with these or other tools, connecting to SQL Server databases from Mac OS, I’d love to hear about them so I can continue to spread the word.

My single biggest problem with using both platforms: I use the same slim Apple keyboard both at work (with a PC) and at home (with a Mac), which for most typing is fantastic, as there is no shift in finger movements depending on where I am… with one exception.  The CMD key at home becomes the CTRL key at work for operations I perform A LOT: copy & paste.  This is extremely frustrating, and while I have found several key re-mappers that claim they can help fix this problem, none of them work for these specific keys, since both are essential for core functionality (primarily re-assigning Ctrl+Alt+Del on Windows is the fix that I haven’t yet managed to get working).  After a few miscues I end up right-clicking and using the context menu.  So, watch out for that one, and if I get around to dealing with it in a satisfactory way, I’ll try to get the word out.

The only other compatibility problem I’ve had (which @mike_walsh was quick to remind me of, thanks Mike!) was the last time I spoke at the New England SQL Server User Group, we had a real problem convincing the projector to correctly display the virtual machine, making my demos horrible.  The next time I speak (June 13th at CTDOTNET) I will bring both the MBP and a 15″ MacBook unibody, running the virtual machine demos off the latter.  I am banking on the fact that switching between Mac and Windows mid-stream caused the problem, but hopefully their projector can handle multiple inputs.

Next on my shopping list is the new 17″ MacBook Pro with its awesome alleged 8-hour battery life.  I will probably splurge on the SSD if, for no other reason, than to lessen the effects of hot laptop meeting white, computer-dork thighs.  But first, I need a good excuse to replace my “aging” MBP.  It just doesn’t need replacing; for the most part, it is still operating as it did on day one.  (With the notable exception of a video card problem last year, which was common across the entire line, and which was fixed quickly and happily out of warranty.)  Maybe I can push it down the stairs or “forget” it somewhere.  Anybody in the market for one? Bueller?

Anyway, after all of that verbal diarrhea, I hope I have illuminated some of the reasons I have chosen to use a Mac where I can, and how I have worked around some minor issues that have come up.  If you have any questions I haven’t covered, please feel free to comment below, or contact me directly (via twitter: @aaronbertrand or e-mail: aaron.bertrand@gmail.com).

And when people call you crazy, ignore them.  Even though they’re probably right.