| Agreed. I posted this comment a few years ago, but it looks like it's relevant as here as well: A potential acquisition came our way that seemed to be exactly what we were looking for. Customer traction and revenues, the features exactly what we were looking to overhaul. There was very high internal interest in acquiring the technology and the company. The need for this set of features was so high and the internal development estimated to be so costly (in developer time and delays in other projects) we were willing to overlook that this app was not built on our primary stack and only a few of our developers were familiar with. The language choice made by the company didn’t cool our appetite. However, technological choices made us pass on the acquisition. They didn’t use a framework. This means that our developers would have a very long learning curve. We also saw a lot of code that did what a framework would have taken care off and this means that we would have had to learn, maintain and expand that code instead of working on the revenue generating features. We found close coupling of code all over the place. This meant we couldn’t quickly extend and modify the features as we wanted without first paying back the technical debt accumulated by the developers. It wouldn’t have mattered which framework they would have chosen as most of them have good documentation and force some sort of standard development practices. However, we couldn’t take a chance that all the behind the scenes stuff would need a rewrite if we wanted to expand and scale the platform. We passed. |