1) See a business problem
2) Put something together to solve the problem
3) Move On
e.g. 'inability to account for new desired behaviors' for presumably a core business system, that the business relies on, would almost certainly imply that.
As to your question, it doesn't really matter what my background is, I could be a ballet dancer and would still be able to reason out how businesses operate and how software historically has integrated. It's not some big secret.
It could also be argued that outgrowing your initial business app is good thing.
Lots of business don't outgrow it, because they don't grow :)
Indeed, it might be reasonable not to invest too much upfront, before you have scale and can afford to build stuff you won't outgrow.
One place I helped out at had a pretty awesome access app for doing some business functions. Way better than the Oracle whatever they failed to replace it with.
The problem was, nobody was willing to claim ownership. The business guy who wrote it was long gone, and IT would not accept an Access app.
If the business relies upon that Access app, and IT refuses to accept it, then it's a failure of IT to accept it and then replace it.
IT exists to serve the business.
Many, if not most, professions are not nearly as well organized and optimized as IT, so we don't have things like silos and ticketing systems to regularize our work. I can imagine an IT worker who has never experienced a nonstandard request, but I can't imagine it in my own occupation.
I think there's a kind of no-mans-land, where programs get too big for an individual hacker to manage, but too small to muster the programming department. Getting small tasks done on any kind of timeline is usually just a no-go.
VS6 was still the majority IDE well into the mid-00s, at least in an academic setting. I still remember getting handed an academic license DVD to use for my C++ courses in University around that time.
The disconnect between "classic" and ".NET" VS took a long time to break, I would say until about VS2008/2010.
it's like a quick and dirty shell script or what once could be a tcl or perl script, but today would most probably be a python script
I remember that just downloading and installing VB.NET was burdensome, especially in the plant where many of the computers were not networked.
When VB.NET came out, programmers hung on to their VB6 disks, and kept using it for easily another decade. By the time VB6 really reached the end of the road, its replacements (e.g., Python for me) were up to speed, and free.