- It works.
- It is maintainable.
- It is reusable.
The developer that creates a data driven implementation that only he or she can understand is not gong to be maintainable by your low skilled, procedural developers. The implementation works, but it can not be considered maintainable and reusable if these activities are limited to one developer.
The development team that picks a language that has a passionate following and generally good library coverage for implementing the initial product release, but it does not have broad acceptance in the development organization. This implementation is not going to have staff readily available for maintenance. So the original staff become its maintainers and these are, very likely, the most expensive developers on your staff.
The development organization that eschews using anything but in-house developed tools and frameworks. No matter how well it is architected, systems designed, used in implementations, and available on-boarding training it is never going to be better than what is available outside. The longer your staff remain, the less employable they become, and so the more anxious they are to leave or, worse, hunker down into survival mode.
When you are creating a product for a one-time use then by all means use whatever it takes to get it working. Remember that these products are gadgets. Even if the gadget is critical to success of some other endeavor -- eg, it specializes in an island's one-time disaster response logistical problems -- it is still a gadget and so expendable. When you are creating an appliance then getting it to work is the least of your problems. Maintaining it and making its parts reusable are central to the development organization's success and repeatability. This requires that you be able to continually staff your organization with the range of developers with costs appropriate to the lifecycle stages of your products.
