Engineers without borders, silos, and vendor walls

Even though I&#x27;m strongly biased towards agreeing with Rachel here, I&#x27;m going to throw this out here anyway: in case of 3), you could technically always fire the three subpar vendors and replace them with their better competitors (assuming there are any). Replacing a vendor <i>may</i> be easier than replacing an in-house team, but then again, it may not.<p>But with vendors come different issues. They can go out of business, or get acquihired. If their product is in any way not aligned to your business needs - and it almost never is - then you have to either throw a lot of money at them so they customize their service for you, or you can alter <i>your</i> business to fit the vendor&#x27;s offerings (and keep altering it as they iterate on their product). Both options are terribly inefficient compared to just asking your engineers to tweak something in your own codebase.<p>(And then your country&#x27;s government and the US government decide to unfriend each other, and suddenly 95% of services you depend on <i>and their competitors</i> can&#x27;t service you anymore. There&#x27;s that risk too. See e.g. Venezuela.)<p>I viscerally hate the idea of a business being assembled purely from third-party services, reducing itself into a pile of contracts. I really dislike the way how our economies start turning into NPM. But everyone keeps saying there are good business reasons for that. So maybe they are. I don&#x27;t have a formed rational opinion on which way is better yet.

This could at least in part explain some common patterns:<p>- Non-IT companies overall have terrible IT systems because as soon as they have two systems they need some sort of integration which the vendors are likely to botch and the resident &quot;IT person&quot; isn&#x27;t qualified to build and maintain.<p>- &quot;Nobody was ever fired for choosing $vendor&quot; actually makes sense when integration is a black hole for time and money. At least a single vendor is likely to have already taken care of integrating with their own products.<p>- When people start looking at which parts of an IT infrastructure to improve it&#x27;s usually the oldest and most botched-together piece. But it is nearly impossible to replace because of all the botched-together custom <i>integration code</i> which was cobbled together by half a dozen barely-qualified staff.

Multi vendor is even worse than described. I worked for one of the vendors. The incentives make you fight tooth and nail for suboptimal technical decisions that direct money to you rather than the other vendors.<p>We won the internal bid for a functionality module that ended up being a standalone service called by system X. Vendor X had lost that bid. They convinced the bank that it is absolutely necessary for us to expose a JDBC driver as an interface.<p>Their engineers were actually pretty cool and we agreed to implement something which made more sense. Unfortunately this decision was blocked. We ended up exposing a simple RPC API via a JDBC driver. I think it had over a thousand methods, almost all of them empty.

I was following it up until the vendor FUD. For most of the code your part of the orgs wants to run, chances are, you aren&#x27;t hiring the world&#x27;s best dev&#x2F;prod&#x2F;designers to dedicate their lives to say your website&#x27;s anti-spam comment forms -- they&#x27;re going on the differentiating stuff! For the boring whizbuzz widget, the top vendors in the field will already have centuries&#x2F;millennia worth of worker hours &amp; experience behind it. And, even if you picked a wrong vendor, should be waaay less political to replace them.<p>One phrase that I&#x27;ve increasingly come to love is &quot;torpedo in the hull&quot; (<a href="https:&#x2F;&#x2F;allaboutstevejobs.com&#x2F;blog&#x2F;category&#x2F;steve-jobs-history&#x2F;" rel="nofollow">https:&#x2F;&#x2F;allaboutstevejobs.com&#x2F;blog&#x2F;category&#x2F;steve-jobs-histo...</a>). It&#x27;s tough seeing senior folks tolerate vendor-outsourcable projects going to weird internal special projects &amp; artisinaly-managed OSS. We know most folks switch jobs every couple of years now, including those behind that fancy internal project, and inheriting unnecessary code &amp; ops is such a drain. Why encourage planting timebombs?

A different perspective from a dev shop owner.<p>Our clients do outsource custom development primarily due to cost-saving reasons. Being non-tech companies it is very difficult to justify high IT project costs. Competing for qualified talent is no fun as well which leaves them with internal IT whose primary job is to keep existing things running and that&#x27;s it.<p>For them, it is a choice of:<p>A) Outsource development of the 3 projects and actually have the 3 projects completed and bring business value<p>B) Hire 3 teams of engineers, managers, UX, whatever, and keep them salaried<p>C) Do not have the 3 projects at all<p>The budget often allows for initial development only, making option B non-viable.

This is a good example of Coase&#x27;s &quot;The Nature of the Firm&quot; [1] as applied to services.<p>(The question, though, is why the three badly-performing services aren&#x27;t replaced.)<p>[1] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;The_Nature_of_the_Firm" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;The_Nature_of_the_Firm</a>