I saw Todd Gardner of TrackJS speak on the build versus buy dilemma at AngularMN on Wednesday night.

There were some dinosaurs in this talk! One guy in the audience mentioned the old Classic ASP app being run at his work and without knowing anything about it Todd asserted that the app must be very successful as otherwise the organization would have gotten away from Classic ASP a long time ago. He also mentioned that Joel Spolsky, who gave use FogBugz and StackOverflow, has a "don't rebuild systems" quote (see this) bearing in mind that a mature, utilized, important system will have grown beyond what is in any documentation there may be taking on numerous esoteric quirks that will be hard to rediscover in the name of a recreation leading the recreation to be a big waste of time. Todd went on the assert that he has seen scenarios in which the recreation gets to a point where it covers a chunk of the first system and people start using it before the first system is turned off, but then it never fully replaces the first system and soon both systems are running while a third system is created to reconcile the two, share data, etc. Todd also offered that as good as your architecture standards may be, everything eventually becomes a "Big Ball of Mud" which is one of the antipatterns mentioned here and regarding which Todd pointed us to this blog posting by Brian Foote and Joseph Yoder. Another dinosaur mentioned by another audience member was IBM AS/400, an old green screen app. This was offered as an example of abandoned tech that there was nonetheless no getting off of in that scenario. Todd suggested that Sybase, a forerunner of SQL Server that is decades old and has no new adopters, ups its licensing cost by thirty percent every year to milk the base it has left which at this point in history is comprised exclusively of individuals who are trapped with Sybase, unable to wiggle free. This is vendor lock-in. In a scenario in which a company leans towards buy in the buy versus build decision making, IT becomes just vendor contract management. The opposite approach, leaning towards build, is called "not invented here syndrome" (NIHS) and in this model an organization rebuilds everything that could be purposed from elsewhere. There are reasons not externalize. Per Eric Ries, ninety-nine percent of companies that take outside money (venture capitalism) are going to die within five years and certainly there are examples of bad vendors to use, however, Todd suggested that Best Buy rewrote their own in-house versions of the DigitalOcean cloud platform and the Cisco Jabber chat client which are really pretty established and too generic to be business-specific. You can take the carpe diem thing too far cowboy. It is probably better to use Angular than to roll your own JavaScript framework. Google and Microsoft probably won't throw Angular away anytime soon. Where is the porridge that goldilocks should pick then? Todd recommends posing these five questions in decision making:

1. What is the impact of failure of the system? (This affects the amount of time you put in.)
2. Do you need this for competitive advantage? (begging the question "Could you sell it?" as if it is not interesting enough for someone outside of your organization to want maybe it's a solved-problem not cornerstone to your niche)
3. What is our bias?
4. What could we do instead?
5. Is it sustainable?

Fifty-five percent of software implementations fail. In the buy approach you may have to pick between industry standards and something highly-configurable. Jira is an example of something so highly configurable that it empowers you to accentuate your bad workflows and that also makes it hard to escape. This is known as "being sticky" and cloud vendors are kind of sticky in another manner by way of making you learn so many processes that are specific to their platform. In contrast, when you roll your own, how many people need to be hit by a bus before you are in trouble? How many fiefdoms of knowledge (UI, DBAs, etc.) share ownership? What are your ownership policies, change approval processes, and time-to-death sunset policy? What does the upgrade horizon look like? These are all things to think about. Also pay attention to size of scope. Todd thought that the famous "I think there is a world market for maybe five computers." quote by the original CEO of IBM, Thomas Watson, could in modern times become "There should only be seven companies using Kubernetes." Don't compare your company's needs to those of Netflix which has to stream content to millions of people at once. Time to wrap up. Red Hat Ansible is for provisioning, deployment, and configuration of home spun stuff. Octave Klaba's OVH (On Vous Héberge which is French for "we host you") is a datacenter management company that you may engage with to keep your apps afloat. I think Box was namedropped as another cloud thingy that Best Buy rewrote in-house. Daniel Pink was definitely namedropped. He has written of levels of mastery. DR is data recovery. left-pad is the npm package that when removed as suggested here, broke so many other things. All it did was pad a string on the left side and yet it set a precedent wherein npm now no longer allows you to just turn stuff off at a whim. Todd Gardner runs TrackJS, and TrackJS does error monitoring. The intro here has a bit about it.