> Why take something out of your toolbox? The problem isn't my toolbox. The problem is someone elses toolbox, who often isn't an engineer, when that someone h

> Why take something out of your toolbox? The problem isn't my toolbox. The problem is someone elses toolbox, who often isn't an engineer, when that someone hits the limits of that shiny, sparkly tool he put in his box. Because at that point, software engineers have to figure out how to interface some extension with that thing. Which may be easy. Or it may be next to impossible, because the tool usually doesn't have things like version control, standard interfaces other than outgoing HTTP (if it even has that), compatibility with common IDEs or the ability to unit test. Bonus points if it doesn't even store the box-and-line-diagrams in something vaguely grep-able like XML, but uses a proprietary binary format...or stores them on the vendors servers making them completely inaccessible other than through the vendors interface. Right tool for the right job? No problem with that. If it "empowers" someone to do something he couldn't do otherwise...great, full support. But as soon as someone wants me to interface my toolbox with it, I will demand that it offers the same qualities that I expect from every other tool that I use. Because these qualities aren't arbitrary, they evolved over decades of hard earned lessons in software engineering.