3 ms·
> latter case if the person who added another database/programming language/web toolkit/etc managed to achieve something with in in a short period of time. Thi
by sten 10y ago
> latter case if the person who added another database/programming language/web toolkit/etc managed to achieve something with in in a short period of time.
This one bothers me. It's brought up all the time. And I completely agree that adding a new tool or feature adds risk and technical debt. But if there's no other way to do it... I work in a corporate VBA shop. 90 percent of our work in the last year was in VBA. But next year is looking like python, R and JS. How? Requirements changed. We got handed some projects in machine learning and we delivered, crudely but still. While in the technical sense we 'could' have coded it all in VBA it's not practical in the slightest to do so.
- StillBored 10y agoI don't think that is an argument against having a handful of technologies in any given stack. I think its more an argument against having a lot of similar technologies. For example, I wouldn't dream of trying to write a device driver in anything other than C, but I wouldn't try writing a web back-end in C either. OTOH, I promptly ripped out ~100 lines of perl one of our developers insisted on dropping into a bash script a month before he left. Turned out the bash equivalent was actually more concise and didn't require yet another dependency on top of the 4 major programming languages (not including bash) already contained in the project.