I'm not sure if you're a developer or not, I'm just gonna assume you're not in order to hopefully be able to describe things better.
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.
Again you’ve described a paradigm like functional programming but failed to address my original question.
I’ve been programming for over a decade now, and have seen this symptom over and over again. Someone sees shiny new paradigm => realizes is holy grail => fails to see how it fits into _actual_ working teams.
My problem is that you are going to have a hard time selling this academic approach to _PRACTICAL_ teams doing every day work with every day deadlines and bottom line business dollars.
Until you make this seamless and easy the extra work is just going to be _extra_ work which will be ignored.
I say this as a FAN of Statecharts and functional programming. I myself love this idea. I am looking and prodding people like you for SOLUTIONS to make teams adopt this.
So far you’ve failed to convince me on how to sell this to teams or make it easy to integrate.
> So far you’ve failed to convince me on how to sell this to teams or make it easy to integrate.
Yeah, because I'm not trying to convince you of anything. It's a tool in your toolbox, use it when you think it's advantageous, otherwise use your other tools. I couldn't care less of what you chose to do or how you "sell this to teams". I'm a developer who simply chooses the best tool for the job, sometimes that's Statecharts and sometimes it's something else. Also don't have any idea about what ideas are circling around in "Academia" as I'm far away from that ecosystem and only focus on shipping working products.
If you're looking for something "easy" in particular, then whatever you don't know is gonna be hard. Such is the life of a developer, where sometimes the simpler way is harder but worth it in the end. React was hard for people to grok in the beginning as well, but that doesn't mean it's bad, it just means people are not familiar with it. If you're just looking for easy solutions then yeah, feel free to stop improving and continue use the stuff you already know or is familiar to you.
So in the end, do what you will with the knowledge and experience I've shared with you, I have zero interest in selling you anything and I'm simply discussing stuff here on HN as I'm curious about things and want to have discussions with people who are also curious about things, but this discussion stopped being productive a long time ago.
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.