3 ms·

I think the key is, small acts of sabotage that could never be considered sabotage, so there isn't any chance of getting caught. Using a hammer that is to small

I think the key is, small acts of sabotage that could never be considered sabotage, so there isn't any chance of getting caught. Using a hammer that is to small or adding another technology to an already complex technology stack would never be considered sabotage. They likely wouldn't even be considered incompetence, especially in the 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. Instead that person is a hero, and the costs associated with the decision are initially small and don't show up until that person is long gone. Repeated a few times the small hits to productivity/quality/etc will result significant lost ground. This is probably even more important long term in the technology industry than it is to a war effort. The sides would have to be close to evenly matched and the war would have to go on a long time for all the little bits of sabotage to add up.

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 ago
  I 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.

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 ago
I 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.