The idea is that I am not actually aware of what the final product will look like, when I start, so I take a very careful approach. I spent 27 years, working for a "Waterfall-based" corporation, where the system had to be 100% designed up front, and the end result would "meet spec," while still sucking. I am not particularly thrilled with many agile approaches, either, as I see many of the same problems. It's really just shifting the tech debt around.
My approach actually results in my having to throw away a lot of really good, tested, code, but I still end up moving lightning fast, and coming out with good results. If you look at my portfolio, you will see a whole bunch of small, heavily-tested module projects. Many of these were things that I ripped out of other projects, but didn't want to throw away. Some of them are crazy useful, like the Persistent Prefs Utility[1], or the Generic Swift Toolbox utilities[2], which show up in most of my work. The fact that they are treated as independent projects, with heavy testing, means that I can reuse them with confidence.
The Spinner project[3] was an example of a UI I designed to be a central aspect of an app, then decided not to use it, as it deviated too much from the user workflow I had in mind. It will be back, but not until it's the best approach. Eye candy is nice, but it still needs to be usable.
That modular approach is not new at all. I think I may have been doing it since the early nineties.
True, there is flexibility, but that flexibility is implemented as a single-point hinge, not a bendable continuum. It's very clear where the flexibility goes, and that point is well-tested. I just got done refactoring the server, where I added a more flexible way of allowing users to implement security postures, and I'm really, really glad that I did things the way that I did. It was a pretty big job, adding personal tokens (the new functionality), but a lot of the work was making sure that I stuck with the "philosophical" domains of each layer, and testing the living bejeezus out of the code.
And each point of flexibility has a very clear domain. For example, the ANDISIOL layer is where the SQL turns into functions. You can rip out everything below that, and replace it with whatever you like, as long as the same functional API is presented to BASALT. That's a fairly classic pattern.
[0] https://littlegreenviper.com/miscellany/the-road-most-travel...
[1] https://riftvalleysoftware.com/work/open-source-projects/#RV...
[2] https://riftvalleysoftware.com/work/open-source-projects/#to...
[3] https://riftvalleysoftware.com/work/open-source-projects/#RV...
