Stitch And Use Approach To Developing Intellectual Property Is Highly Overrated.

Years ago at Multiplitaxion Inc, I witnessed a project which was a collection of multiple source frameworks out there; that were somehow held together with band-aids. When the final product evolved by the virtue of hooking up random open source frameworks; we called it our 'Intellectual Property'.

Soon the band-aid wore off and our product crumbled to pieces before moving to a stable production environment.

Any engineer with an eye and taste for genuine software would clearly seen the different components oddly stitched together by interns fresh out of college and laughed at the idea of calling it our Intellectual Property.

Here is the tragic truth however; we were neither able to sense the oddness in the whole design nor question how you can create intellectual property by hooking up five open source components out there together with weak a band-aid. Anyone who was intelligent enough to understand the oddness of the design decided to keep their gob-shut and tactfully disassociated themselves with the project. 

After multiple man-months of efforts; a huge team slogging away trying to contain and control components which were like beasts running in different direction; started facing and ignoring small broken windows which soon snowballed into an explosion that destroyed the project.

The stitch-and-go approach to intellectual property destroyed the project.

Years later; at work; in my current organization; I was asked to build a system which would allow us to build applications for our clients who had a lot of long-running workflows and wanted to take these workflows online. That is when Crux was born.

Even today; I am viewed with paranoid eyes of capable programmers when I tell them that Crux includes a custom-made application framework along with a light-weight, open source workflow engine that I wrote using new language features of C#.

'But Pops, why didn't you just use windows workflow foundation' --- is one of the most common question that comes up during training session for Crux.

A part of me; which is a pragmatic programmer answers this question with logic and reason --- we have used Windows Workflow Foundation for months; found it to be a decently good workflow engine but it is way too complicated for the kind of long running workflow requirements most of our clients were are going to have. Besides the learning curve associated with it is steep and the benefits gained out of using it for what we were trying to do; aren't high enough.

The real answer however is deeper than that. The real reason for not using Windows-Workflow-Foundation in Crux was the fact; that Windows-Workflow-Foundation in it's current version needs 'stitches' and 'compromises' all over the place to be hooked on to anything.

Put simply; Windows Workflow Foundation; in it's current version; is a beast in itself which requires feeding or caring and that feeding or caring; dear reader; was too much of a price to pay for the simple web based long running workflow systems we were trying to build.

This post dear reader; is not about me trying to illustrate how a product that tried to hook on multiple components out there failed and how me deciding to not use Windows-Workflow-Foundation in Crux ultimately gave us multiple successful client implementations.

This post; dear reader; on the other hand addresses an aspect of software development that is much larger than the two examples I talked about.

Talk to most CTOs, Vice Presidents and even consultants around the world and it is not un-common to come across words like 'leverage and re-use of components out there'. Talk about building something which sounds a little off-track; in-house and it is not un-common to hear the sound of fifty thousand heads of programmers exploding all at once.

While I am all for the idea that we as developers are code addicts who are constantly wanting to bull-doze what exist and start from scratch; it is also important to realize and stop; particularly when your desire to 'leverage' the components starts taking you down the slippery slope of creating Software that can be best described as Frankenstein's monster. A monster that will eventually chase it's developer and make his life miserable.

As a general rule; if you are trying to roll out something that is going to be your core-intellectual-property you are better off building the stuff yourself; or at-least working at a level of abstraction where you can control and tweak every minor detail; rather than trying to hook up multiple ready made components out there in to get something out quick and dirty.

The Stitch And Use approach to building intellectual property is highly overrated.

On the other hand if you are just trying to get a processes automated or get a solution implemented that does not involve your core intellectual property you might be better off buying the stuff that's already out there. When it comes to tools; which allow you sufficient level of abstraction that you need; again; you are better of buying than building.

Either way; always remember - if buying is an option; building is an option too --- even if your Vice President looks at you like you just dropped a filthy rat on his table when you utter the words 'build'.

The next time you are faced with the question of building vs buying or using something already available; keep your biases aside and take a pragmatic decision based on your past experience; logic and your very own gut-feeling.

I wish you good luck.