Curiosity, mostly. I have no plans on doing anything major (let alone released to an end user) in Smalltalk, but it's a very different mode of programming than most of what I've done in my professional life (largely dominated by work in the embedded systems space and a lot of tooling around that). On the desktop side, by fiat, I've spent a lot of time with C# for new development, and a bit with some older C++ and Java systems (with the current job, more those two).
Because of the way that embedded systems work, you can't easily escape the standard build, load, test cycle (at best, on some projects, you get simulators to help speed up test), and deployment is often delayed for, sometimes, good reasons around coordination with a fleet of systems.
On the desktop software side, because I haven't convinced my employer to go with smaller batch sizes for releases, we still have big-bang releases every 3-6 months (and the first year with COVID we didn't even hit that pace with remote work growing pains). When an end user comes across a non-critical issue, this means they will be waiting months to have it addressed (if it gets put into the next release, it could be years in a worst case).
This leads to end user empowerment, at least in principle. One of the current systems I'm working on has a pretty comprehensive scripting language (a bespoke DSL) that lets end users (not formally trained as programmers, and their job isn't to work as programmers) extend the system to meet their needs without calling for help most of the time. None of the other systems do that, but most could without hitting any corporate IP issues (the customer, in our case, owns most of the source code anyways, but they aren't a software company and outsourced the development and maintenance work). Smalltalk (the system) is an extreme case of end user empowerment and I wanted to explore that concept.
Because of the way that embedded systems work, you can't easily escape the standard build, load, test cycle (at best, on some projects, you get simulators to help speed up test), and deployment is often delayed for, sometimes, good reasons around coordination with a fleet of systems.
On the desktop software side, because I haven't convinced my employer to go with smaller batch sizes for releases, we still have big-bang releases every 3-6 months (and the first year with COVID we didn't even hit that pace with remote work growing pains). When an end user comes across a non-critical issue, this means they will be waiting months to have it addressed (if it gets put into the next release, it could be years in a worst case).
This leads to end user empowerment, at least in principle. One of the current systems I'm working on has a pretty comprehensive scripting language (a bespoke DSL) that lets end users (not formally trained as programmers, and their job isn't to work as programmers) extend the system to meet their needs without calling for help most of the time. None of the other systems do that, but most could without hitting any corporate IP issues (the customer, in our case, owns most of the source code anyways, but they aren't a software company and outsourced the development and maintenance work). Smalltalk (the system) is an extreme case of end user empowerment and I wanted to explore that concept.