APPLICATION STATE:
Leslie Lamport is the creator of TLA+ and Paxos. Lamport suggests that an application is as a series of states. He suggests viewing your apps as state machines. He argues that we need to create better specifications for our apps. We can do exactly that by using TLA+ to specify the states and behaviors an applications. I’ve been trying to do that with my apps and it’s been interesting.
Like coding, part of the problem with TLA+ is that it’s hard to write TLA+ until you know what it is you want. The best way to know what you want is to figure out a solution to the problem. One of the best ways to do figure out a solution is to write some code and test the solution.
Developers have been having this struggle since computing began. When developers write the second version of an app it’s usually to to fix the problems with v1. After writing v1 the developers understand the problem. In The Method Juval codifies this in the service development lifecycle. He has a box labeled “some coding.” What he’s saying is that it’s normal to need to do “some coding”to understand how to build software. It adds clarity.
My message board has been the same. I took several stabs at the app before I understood what I was doing. It took experimentation and learning to create a version that would be stable and run for days at a time. What emerged during that process was an understanding of the application and it’s states. It also required an understanding of the code for the transitions from one state to another. When I first started developing the code I was not working on states and transitions. I was trying to make the thing work.
As I solved the technical problems I began to be able to see the states and the transitions. I morphed my code to group these things together and to give them structure.
The third version of the message board took about 3 weeks to get to. In version 3, I created an actual state machine. It may be the simplest state machine every written, but it’s a state machine. Each of my states has only OnEntry(), OnExit(), and Activate(). Like I said, simple. In this case simple is good enough.
The state machine helped me focus at a higher level, above the logic. I was focused at the level of states and transitions. I had been focusing on methods and functions. When I focused on the higher level an interesting thing happened. I kept finding bugs and oversights. It was as if focusing on the states allowed my brain to see the flaws. But it was more than that. The structure itself revealed the bugs. The bugs jumped out because they did not support the structure. Let me give a simple example.
Early versions of the apps had flags all over the place. I used the flags to reflect application state. Flags are (essentially) global variables. It’s very hard to get their management correct. Flag values were being set all over the place in v1 of the code.
In the state machine version the flags disappeared. Rather than trying to track the state with flags, the code relevant to state lived in the state machine. The question was no longer whether to modify a flag. The question became whether a state needed to be activated. On activation of a state the state machine calls OnExit() of the previous state then OnEntry of the new state. There is no need to coordinate flags.
I was no longer worrying about setting a flag in 15 different places. I was asking “What do I need to do when the app enters this state?” “What does it need to do when it exits this state?” These questions have such clarity and focus that bugs started jumping out of the code.
This is what happens when you use TLA+ to write better specs to go with your code. It’s worth our time to get better at doing this.
I’m also suggesting that it’s okay to write some code first.
The challenge for the business/team is how to do “some coding” with minimum effort and minimum waste/rework. The Method suggests you do this by creating a project plan based to keep focused. The project plan is based on the architecture. The architecture is created around areas of volatilities. Basing the project plan on the architecture is taught as part of “The Method.”
We haven’t said anything about that yet. So let’s jump in.
[part 4]
