From Scratch

This is something that's been bothering me for a long time: the debate over custom development verses out-of-the-box / third party solutions. I flirt with this in a majority of my posts, but have never really focused on it as my main topic. And it keeps popping up in conversations with clients, colleagues, and the community. Should you build or should you buy?

I am an architect, and I see poetry and precision, beauty and brains in my code. I will always be on the side of custom building...ehhh...almost always. I find myself surprised when developers are okay with implementing something someone else wrote. It just feels like legalized plagiarism. I want to figure it out. I want to solve the problem. So many developers' work is comparable to double malt scotch. Blending together other people's ideas just isn't as smooth as the code you brew from scratch.

The only time I will consider building a Frankenstein's monster of a system is when the third party controls or underlying platform ONE HUNDREN AND NINETY SEVEN BILLION PERCENT nail a requirement without any intervention from me. I install it and I'm donezo. If I can sew arms and legs to my monster and don't have to worry about browser support, edit any CSS, XML, or XLST files, don't have to break open or reflect the code, and don't have to write any hackball jQuery to make it work on a phone or on a Mac or with a custom master page or in a different language or on leap day or with anonymous access then that's fine.

But the second, the very second my client utters the phrase "...but what about..." I'm opening Visual Studio and building it myself. The economics are simple: to get it to spec, I can build it from scratch faster than I can hack it, despite the head start a third party control provides. And building it myself gives me the intimacy I need with the code to be able to quickly kill bugs. And building it myself allows me to integrate client-specific edge case functionality that they'd have to add into a purchased control anyway. And building it myself allows for the most seamless transition possible into future versions.

And building it myself is more fun.

Of course, there are times when it is indeed faster to hack and duct tape, like if you're Superman-ing a failing project dumped in your lap or the legacy system is so convoluted and rusted out that your only choice is to band aid; it couldn't survive a surgery. Or if a third party control has some proprietary arrangement with a vendor and therefore has access to non-public bits of an API. Or maybe some control just nails it; it does what I need without any additional...anything. Remember the phrase "Plug and Play?" That's what I want out of any piece of a system that I didn't write.

Maybe I'm a sadist. Maybe I'm a narcissist. Maybe I'm just a big fat nerdouche. But I just want my work out there to be as close to purely mine as possible. That's not so-and-so client's intranet; that's an implementation of my caching algorithm. That's not XYZ company's web site; that's my best-ever Silverlight animation. I want to solve the problem. I want to make people's lives more efficient. I want to save companies money.

But damnit, I want to do it elegantly. I want my code to sound like an opera as it churns through IIS, not like a garage band someone through together via Craig's List searches for musicians. There's a level of sophistication that only "pure" software can achieve: a level of scalability, maintainability, robustness, and adoption to where I just don't trust third parties to get me.

I do admit, humbly, that this is an idyllic state. Something that purists like me probably find a bit nauseating is the tradeoff triangle. I saw it described best on a piece of paper taped to the door of someone's office at my last client: three giant checkboxes labeled "Good," "Cheap," and "Fast." Then underneath, it said "Pick two."

Everything I've been talking about falls under the "good" category. That said, building something from scratch of course doesn't guarantee that it'll be good! Rather, it gives you the opportunity to make it as "good" as possible. Let's say you find an inexpensive a control out there that does what you need, but perhaps runs slowly. It's quick to implement. It's cheap. But it's not good: performance is so critical in today's systems that if something's slow, adoption will tank. So when you build something, you can not only make it right; you must also make it well.

Your control can gather all the same data as its third party equivalent, but it'll load in one second instead of four! Why? Because you built it yp to your standards, not to some vendor's standards. Why? Because you gathered the performance requirements directly from your client instead of going off of industry-wide data. Why? Because you tested it on their hardware, not some test server. Why? Because you talked to your users instead of skimming through surveys.

But to most, I assume, quality is not in contention; I can't image anyone who skimped out on something ever got too upset when it broke after the first week. Rather, back to the triangle, it's the "fast" and the "cheap" edges that translate into custom tasks slowly gradienting from green to yellow to red on project status reports. I've observed much more drama over something being late or expensive than I have about it not being good.

The one edge of the triangle where I struggle to pimp custom over shelf is the "fast" one. I stand by my argument that it's potentially faster to deliver a client's wish list of requirements via building from scratch. But considering the 80/20 thing, it's tough to reason out how buying something that's already built, tested, and packaged couldn't be the fastest possible way to get a minimally viable product shipped.

And especially since gold plating is a tough sell these days, getting an intranet or app to eighty percent completion in less than a week is terribly attractive; there's just no way building can complete with buying in that timeframe. And it goes without saying that if your client has a specific target date driven by an event or a marketing campaign or a promise to a stakeholder, then you better believe that making it "fast" will quickly become the driving force behind your architectural decisions.

I advise caution in this scenario because if a client wants to buy something and then tweak it to fit their specific business processes, you really need to figure out what that last twenty percent of the project will look like. And it won't be pretty; you can't turn a Buick into a Bentley with a can of paint and some decals. So while it's indeed fastest to simply detail the Buick, my point is that is it's quicker to build a Bentley by hand (which I believe they actually are) starting from scratch than it would be starting from a Buick.

So custom is good, and off the shelf is fast. What about cheap? This is where I get fired up. No one wants to buy anything for more money than necessary to get something that fulfills a desire. No one wants to sell anything at a price below which they wouldn't hit their profit margins. Throw some negations at this cross roads and it works itself out. But, when it comes to building software, there's not a single price tag.

And this is a concept that makes our industry (which is still just a toddler) unique. I get a lot of mileage out of comparing software development to the automotive world. Weather a consumer walks onto a storeroom floor of a dealership or a stakeholder walks into a conference room for a sales meeting with a vendor, the same question will be asked: "How much is this going to cost me?"

The car salesman can simply motion to the gigantic yellow price tag adhered to the windshield and not much else, pending negotiations. However, back in the conference room, this is a much more difficult question to answer. This salesman has to go back to his architects and get an estimate. An estimate. If you're buying an brand new 2012 Honda Civic, it's easy to get a price, because Honda knows exactly how much it costs to build a 2012 Civic, because they've done it hundreds of thousands of times following precisely the same procedure. But the dev shop has never built this particular web site before, and neither has anyone else, so it's impossible to know exactly what the effort will be. So we estimate.

This is what's unique about us: we have no clue how much our services cost. Well, I take that back. We do have some clue: consulting old estimates, discussing implementation details with colleagues who've built something similar, choosing fixed-bid verses time and materials, adjusting hourly rates, etc. are all controlled variables in this equation.

And so like I just said: we estimate. And if it's too expensive, then we negotiate. Like producers on a live broadcast, we can cut segments if the show's running too long. Or we can anticipate write offs if someone on the team doesn't come through with their tasks. And there's always version two. I totally understand the massive importance of the bottom line. While I'm happy to build inexpensive software, I refuse to build it cheaply.

The biggest frustration I face in my career is trying to convey this crucial difference. I had a client once who passed down an interesting directive: "Custom code is expensive and invasive. Where possible, implement requirements in HTML, CSS, JavaScript, and XSLT so that the files can be copied to the server on the fly instead of having to be compiled and deployed."

I think this is terribly myopic. Now it is indeed more expensive and invasive to not only build a proper deployment package, but also to schedule maintenance windows to execute it. It's more money upfront. However, it doesn't take into account that it takes longer to develop in JavaScript than in C#. It ignores the incalculable extra costs of fixing issues caused by the human error aspect of manual deployments or online file edits. It obscures the cost-saving benefits custom code enjoys from tools like debuggers, automated unit tests, and code generators (such as service references in Visual Studio). It introduces the ongoing maintenance of having to update hard-coded strings, settings, and logic that would otherwise be dynamic in code.

My point is that cheap software can very easily be much more expensive in the long run than expensive software. My point is also that this isn't always the case; very talented people can do very impressive things with out-of-the-box, third party, and client-side software. Therefore, my point really is that the determination of how expensive software is needs to go beyond how much it costs to go live. It needs to consider what it will cost to get to versions two, three, four, and so on. It needs to consider how easily it will be to pivot the direction of the development effort as one or more of a million factors that could potentially change inevitably does.

It needs to consider everything.

So when thinking about the tradeoff triangle and weighing good against fast against cheap, the thought needs be broad enough to cover all these things. At the end of the day, custom code simply might not be plausible because the client doesn't have the in house skillset to maintain it. Or a firm might have to pass on an inexpensive, off-the-shelf product that comes tantalizingly close to doing it all simply because it doesn't support localization.

Like I said at the beginning, I always want to build it first. And like I've hopefully explained, I have to maturity to know when building isn't the right call. But a much larger problem than my fragile ego is when custom development is seen a scary, overly expensive, or a last resort. I really think this myopic thinking is leading to a lot of software out there that simply isn't very good.