[drostie]

I am not sure if I am in the 1% or if you are wrong in a foundational sense of “you have the latitude if you'll use it.”

Like, in the past week I had to add a feature to a front end that is heavily based on jQuery and its ecosystem, so lots of variables that are module-local but otherwise global, and every modification to that globalish state needs to update all of it consistently. I introduced maybe 80 lines of code and comments to define a Model as an immutable value with a list of subscribers to notify when that value changes, a Set method to change the value and update the subscribers, methods to subscribe and unsubscribe easily, and another function which multiplexes a bunch of models into one model of the tuples of values.

The result plays nice with that jQuery globalish code but it's terser and more organized, “define the state, define how updates must covary in one place.” But I can also see that it is not quite structured enough: it lacks functional dependencies which would structure the state more, “you select a ClientCompany in this drop-down and that wants to update the ProductList because each ClientCompany owns its own ProductList,” not because there happens to be a subscriber which has that responsibility. Also means that there is a sort of eventual consistency in the UI which was always there but now I may have an approach to remove it.

So I think that I have a good deal of latitude to try new high-level structures for my code, but it's possible that I just happen to be in a lucky place where I have that freedom.

[dbt00]

I mean, that sounds very much like react + redux, which is where I’d recommend you start if you were building the thing you just described from scratch.

[drostie]

Right, I wouldn't dispute that. If I wanted to rewrite the 15k lines of code in this application (which is what, 500 pages printed? two books?) I would probably use react+redux and could maybe even eliminate half of the code when I was rewriting it.

The problem is that that still comes out to ~250 printed pages, so one book, so that's an investment of 2 months to create no obvious business value, and I think if I could take that I would actually be part of that 1%. But the point of my post was just to give an example of "we can make smaller architectural decisions all the time to clean out crap and make our lives easier," and nobody is going to look the ~2 hours you spend cleaning as wasted time since it causes them to get a more-correct product sooner.

Another example: I remember at IntegriShield we had an API written in PHP, and one of my favorite little things I had written was a data model. ORMs are not hard to find in PHP but because the data model we were using was JSON we could express inside of that data model a declarative security model for the data and it would get written into the SQL queries: you say "Give me all of the groups!" and it rewrites that to, "I will give you all of the groups that you can see." The logic for the group-editor does not need to explicitly handle the checks for "can this person really edit that group?" because the data model will check it for them, "UPDATE groups SET values WHERE id = (the group you are editing) AND (user can edit the group)."

Adding the first security type was maybe half a day's work threading stuff through the SQL generator? Adding subsequent new checks took more time but was incremental so each of them might have delayed their projects 1-2 hours. But the net result must have saved a tremendous amount of programming. I have always had that latitude to create structure, if I want it.

That said, I have been pretty lucky with the places I've been privileged to work, so maybe I'm already part of the 1% and this is not representative.

[thom]

Yes, and 'reactive programming' is the exact sort of architectural choice that is good to capture with a name and a clear context and motivation. The system works, folks.