Good point, I hadn't thought about the fact they might be polling for changes. Might be better if livecoding used an event based model to check for updates...
What I'm saying is that you could just integrate some tooling which would detect when changes are or are not made in a compatible way, instead of relying on the human making a correct annotation.
True. I would consider a continuous stream like that to not be helpful change management. But if you have to have continuous breaking changes like that, you would want clean cuts. My point is, find ways to evolve your API without breaking things.
Collaborative live programming is a pretty bad idea in the first place. There is one thing that's very important that you're missing in your analysis of "the past". All DVCS system allow the programmer to group a set of changes by commits, which constitute a consistent block of changes.
Remove that ability by constantly recording changes, and you can no longer control your code: no code review, no feature merging. Everything just becomes a giant mess. A mess that's auditable, but a mess nontheless
That would also reinforce the importance of checking things work first time. With the rapid feedback we get now, the temptation to hack away gets in the way of properly understanding and predicting what the effect of the changes will be.
Right, but how is that new code rolled out to live systems with zero downtime? They said they try not to update more than a few hundred lines of code, and only on individual objects. What process are they using to roll that out to start the writing?
That’s a fair point, although given how “high level” this is supposed to be, I’d imagine that needing to update it a lot might actually be a canary that the project in question is in a lot of flux.
To deal with dependency churn, CVEs etc people have started setting up automatons to generate PRs. Those can generate a ton of them with minimal information about their real impact(unlike human PRs) and so going through them is not only a lot of work but the volume can be much greater. I'm certain people will begin adding LLM based automatons soon too.
Because of that I think the next big deal will be creating a separate class of changesets for machine suggested changes.
I think this class of app really depends on a good workflow for updating the expected results so people don't fall out of the habit of testing because most of the changes are intentional.
This is actually rather easy to solve without ML/AI. They need to track the change delta (ex: with jsondiffpatch) and weight each part, presumably using levenshtein or text mining with weighted dictionary, and limit changes to 2 or 4 in 24 hours period. Then weekly compare those changes and treat the highest one as need to be reviewed by customer.
Additionally, each customer review should tied to specific change version, that they can easily compare with current one.
WRT large PRs, it doesn't sound like they expect all the improvements to be from small changes. I think the point is the code will be changed in increments so that even large changes (overall) will be easier to review and offer feedback.
I thought change logs served this purpose quite nicely. Every time there is a breaking change, the user needs to check the change log anyway. If there are only some small breaking changes, they are only pleasantly surprised.
Any blog post that explains this a but further? It should be an interesting read, given that I assume you track changes and update programatically (to a degree).
I believe that tracking the number of potentially-changed direct inputs per node would be sufficient, would have better performance and would require fewer workarounds like durabilities. Further, it wouldn't turn O(N) updates into O(MN) ones (where M is the total size of your computation and N is the nodes affected by an update).
However, it would require dependencies to be tracked in both directions, so it's probably not possible to engineer it into Salsa, which seems to only track dependencies from consumer to producer.
I was going to blog about this design in detail, but never got around to it.
reply