Building Software - No Easy Options
Our leadership has talked about build vs. buy in software development, and I'm sure they mean more than they say, but I felt that was too simple. I think you have the following options for building software functionality. Notice that there are no easy options here and it all depends on the tactical data of your situation (so leadership really needs to be actively listening).
- Build (Custom)
- In-house
- Up-side is that there are no barriers to fixing the issues, assuming you can retain your employees that built it.
- Danger is all the risks of ownership (and finding and keeping good developers)
- Off-shore / contractors
- Up-side is that the contractor might have skills you don’t have in-house
- Danger is that once the contractors leave, you are stuck with the worst part of In-house scenario above, but all the employees left, and its built by contractors that don’t know your business…
- Buy/Acquire (Third-party)
- Adapt – Change our code to fit the third-party library, because the third-party library is solid/tested and our code is not
- Up-side is that you are working with a known good (assuming you chose the right library – otherwise you are actually stuck in the Adopt option)
- Dangers here are bad fit (when the adaptation/glue code is longer than the library code) or bad fit (when the library can’t do what you need, and you need to improve/change it, so you are stuck with the Adopt option)
- Adopt - Start from existing (proprietary IP or open source project) and fork
- Up-side is you’ve got a head-start on the In-house
- Danger is that it might take as long to adopt the third-party library that you don’t really know to your needs as it would have taken to build the sub-set you actually need yourself using the In-house option above (This really depends on how far off the library was).
- Adapt – Change our code to fit the third-party library, because the third-party library is solid/tested and our code is not
- In-house
Aron, from what I've seen it only comes down to money. Offshoring always "seems" to be cheaper, but really that just means that the "soft" costs get hidden in the weeds: language difficulties, constant turnover with the offshore company, redesign of the same product because something was misunderstood, loads of administration tasks to get the contractor up-to-speed, and other items that tend to waste the onshore resource's entire day taking care of but have nothing to do with writing code. I firmly believe that it comes down to who is in power, what they believe is the direction of the company, and with public companies, what the stock holders want to see happen.