[analog31]

That was me. I wrote what I affectionately call "crapware," which are small apps that solve a problem but are not intended for use at scale. There was a lot of this stuff, such as little database queries, or hacking together a few industrial sensors with a crude display. Businesses ran on crapware. Maybe they still do. A few thousand lines of code that I wrote for a manufacturing fixture ran bug-free for more than a decade.

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.

[ta1243]

I've written a lot of crapware, still keeps my employer working 15+ years on. Meanwhile "replacement" systems have come and gone, but the users still keep using the crapware.

1) See a business problem

2) Put something together to solve the problem

3) Move On

[MichaelZuo]

I was going to say, a few thousands lines of code that reliably solves a real business problem for over a decade is pretty much the exact opposite of 'crapware'...

[emodendroket]

As long as you don’t care about stuff like maintainability or logging sure. The issue is that a lot of times businesses outgrow their bespoke Access app or whatever and then it’s a huge headache to untangle the reliance on it and go more robust. Of course if that never happens it’s great and frees up developers’ time for higher-value work.

[jopsen]

> The issue is that a lot of times businesses outgrow their bespoke Access app or whatever... > Of course if that never happens it’s great..

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.

[Spooky23]

The issue is there’s no engineering process around it, even in a shitty organization where the “engineering” is garbage.

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.

[Khartoum]

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

[MichaelZuo]

I don't get the relation here?, most businesses care somewhat, and certainly the better run businesses do quite a bit, so they'll make sure to record down everything important about the software.

[emodendroket]

So when it goes wrong in many predictable ways it’s a nightmare. All the stuff software engineers put around software to make it reliable, fault tolerant, and generally having the expected behavior is not just for laughs but the result of hard-won experience.

[MichaelZuo]

Why would it be a 'nightmare' if they recorded everything down and understand their software, what it does, what it doesn't do, how it operates, etc.?

[analog31]

I'm sure this happens all the time. The term is technical debt.

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.

[jacquesm]

I came across such a project recently built using FileMaker in 2001 or so. On the original hardware, no less.

[ralphc]

Please encourage them to make a backup and get it into a VM. You should be able to find Windows 2000 if it will run on that.

[jacquesm]

I actually did just that. But I can't enforce things, only recommend.

[sn_master]

Also, most machines did not have the .Net framework installed, and back then it was 20 MB download which was gonna take ~2 hours on dial up back in the day vs MSVMVM6.dll which was on all Windows versions from 98 until 7 at least.

[deaddodo]

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

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.

[nextaccountic]

what you called crapware is just scripting, but with a gui rather than running in terminal

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