Transactional Programming

This came to my attention when a group I was mentoring seemed to be having a little difficulty. I had helped them reach the point where they were in the home stretch -- design was framed up, database built, projects laid out, etc.

But there was still problems. People couldn't get things done, and one piece kept depending on another piece somewhere that was unfinished.

It took a little poking, but I finally figured out what was going on: work wasn't being done transactionally.

In a complicated environment, people expect things to remain mostly stable. In fact, this is the only way they can do their work. In programming, each little thing can impact the entire project however, so how does any work get done at all without messing up everything for everybody else? If you change the database, that's going to impact things in a lot of other places. If you change the CM system, the entire structure of work changes.

As it turns out, I forgot to teach something: you have to work in transactions. When you change the CM system, you have to immediately change everything "downstream" of that to make sure work is still possible on the project. Same goes for the directory structure, the database -- even the requirements. There are groups of things that you can't do "just one of" when you're in a team. You do one, you're in for the whole thing.

It's interesting that these are all structural in nature. When starting a project, we work on the behavior of the system (what's it doing?) and the structure (what's it look like?). The best way to do this is a little bit at a time, layer by layer. You don't do "one thing" and then hand it off, completed, to somebody else. It doesn't work that way -- all of the pieces are inter-related.

At the beginning we focus on the behavior, 'cause you got to find out what the users want the durn thing to do. It's okay to put in pieces of stuff here and there because it's all rather fuzzy. As time goes on, however, we start structuring our work a little more. In more mature use-cases, we make "passes" over the behavior and structure of the system, looking to accomplish certain tasks. Once we pass a certain point, however, the structure gets more of the focus. As we solidify that structure, when the pieces are in place to begin programming, the work has to become completely unit-based. You are doing certain discrete things to the structure, based on the requirements. These things have an order -- you check out a module, code it, unit test it, and check it back in. You cannot just stop in the middle, like you could at the beginning.

I guess it's rather obvious, but when you teach things a lot of times the obvious stuff gets overlooked. Who would have thought this deserved attention? But it does. It's also interesting to note how the nature of how you work changes from the beginning to the middle.