The bits about code vs doodleware hit hard for me. With a certain proprietary database that I did customer support for, the encouraged development path was dood

The bits about code vs doodleware hit hard for me. With a certain proprietary database that I did customer support for, the encouraged development path was doodleware. It was genuinely very nice if you were doing some toy project, but it quickly became unmanageable. The vendor was on their 2nd of (currently 3?) iterations of doodleware for this database, so the tooling for it was crap and would never get better as they would soon abandon it. I have done in-depth analysis and refactors of dozens of these doodleware objects purely with vim macros. Portable gVim was literally the only thing I could get on the customer supplied Windows laptop to do this job. Export (through a semi-manual hack) dozens/hundreds of 10k line XML files, build a vim macro, cry, cross my fingers that the manual hack to replace the doodleware objects would work, cross them again that the objects weren't irreparably damaged. Now I'm seeing doodleware on the rise in cloud platforms, making business process flows "easy". Connecting different services "effortlessly".