I've been discouraged from putting code in reusable modules because it would mean one central location for everything to break. The rationale was that if every

I've been discouraged from putting code in reusable modules because it would mean one central location for everything to break. The rationale was that if every routine was copied and pasted where it was needed then introducing an error in one place would not affect other places. I am leaving a company that uses a certain lightweight language to build web apps using CGI. There is no way to load libraries except by recompiling the runtime, and we do not have the C source code for that runtime in our possession. This means every library out there (even for the particular language we use, thanks to the fact that we're using a 9-year-old version of the language, and the inability to load binary libraries) is NIH'ed out from the start! Interfacing with external tools is broken because the function that runs system commands has been changed to be async with no access to the standard streams of the process it creates. The product that is built on top of this is designed to let people build applications using flowcharts with a visual editor... but the "programming" that is the result of this system is essentially spaghetti code with GOTO, numbered labels, and a single global scope. Nodes in these flowcharts are labelled with 100, 110, 200, etc. by default and are laid out automatically, so there's no way to understand a routine at a glance. Variables in a flowchart get clobbered by other "subroutines" when they are called. Everything is indirections on indirections on indirections. I could go on... but you can get the idea by looking at this: http://imgur.com/ZKCU.png http://imgur.com/ZKCU.png This is all seen as advanced next-generation modeling that provides massive productivity gains over standard programming practices. At one job I introduced SVN and Tortoise to try to bring version control to the project. A few weeks later we were using Visual Source Safe because the contractor goons couldn't grasp anything but VSS's Visual Studio integration. They also moved to doing development on one shared drive so that updating the whole tree could clobber someone's changes that weren't checked in. I was also instructed to not use document.getElementById(), since the IE de-facto "standard" was to just refer to the element by its name (or whatever was going on back then).