Yes, writing code can add debt, but not all code is debt. "Debty" code is code that can be better, but was needed in order to take shortcuts temporarily, probably in order to trade moving faster now against moving faster in the future. If you're taking shortcuts you're gonna have to fix it in the future, or deal with having to move slower/more careful because of it.

And yes, the solution to code debt is to go back and fix it properly. When it comes to UI programming, I'd argue that doing implicit state machines with conditionals scattered all over the place (which is the de facto standard today everywhere I look), is code debt, which can be fixed by REPLACING it with explicit Statecharts. It can also be fixed in other ways obviously, but besides the point here.

The developers would obviously be responsible for the code they write and the Statecharts are all handled in the same source control system your developers already use (typically Git today), so nothing really changes here.

And yes, when you figure out that you have to change the code to do something different, you're gonna have to ask developer to change the code. The same goes for updating Statecharts (that also exist in the code). If you have to change the states/transitions, you're gonna have to update the code that handles the states/transitions. This is the same no matter if you use Statecharts or not.

In the end, Statecharts is not a programming language itself, it's just a way of doing programming. Basically like how functional programming is a way of programming, or object oriented programming is one way, Statecharts is a different way where you're upfront with what states exist in the application.

Developers, probably. But generally, whoever your team/company assigns this task to.

> When product asks engineering to change code => you now also update state charts. Added technical debt.

So is documentation. I would hope a team handles this somehow.

But if you approach it as a problem you actually want to solve, here's an idea: have the canonical statechart in code, and have the visual statechart be generated from that code. Benefits include: your visual/documentation charts are always synchronized with actual code; if somebody starts playing fast and loose with statecharts in code, the picture generator will break - if you treat this as a build error, you've just removed one common source of project rot.