This isn't a fair analogy. There's a cost to adding new tools to a software environment, and an ongoing cost to maintaining that tool. Closer, IMO, is you're speccing out a new house with a builder and ask for a swimming pool, a hot tub, jacuzzi tubs, and body sprayers in the showers. Getting all of those installed and running to spec is going to be much more expensive than getting one or two of them. If your builder says "You really need the pool. I'll see if I can get that dug in my free time, don't worry about it." you are probably going to worry about what you're actually getting. If you do have the budget to do everything properly, you also need to have the ongoing budget for cleaning and maintenance. Pools and tubs have very different maintenance profiles. The same is true for software.Which is to say, using the "right" tool is nice, but not always in the budget. R or Julia may be a better language for data science than Python, but if you're the only one using them, you're just making things harder for the rest of your team. A Python shop has probably invested in coding standards, linters, test infrastructure, common libraries, and has expectations for how code runs "in production". Expect that you'll need to clear at least some of that bar for a new tool you introduce. Expanding towards tools that better fit problems is good, but unless you're doing 100% green field development it needs to be intentional and measured.
No comments yet.