Monthly Archives: April 2012

State Machines and Business Users

I was at a workshop over the weekend talking about the use of Finite State Machines as coordination mechanisms for systems. These things might be called sagas, activities, workflows, process managers (my preferred term lately from PEI), orchestrations, choreographers, and I am sure I am leaving out a few.

One of the guys in the talk (quite knowledgable) brought up that they used to use petri nets for this as well as pure finite state machines and there had been a push to more procedural mechanisms as business users don’t think in terms of finite state machines. I noted that while we have been moving to more procedural methods, as most of these procedural methods are in their hearts asynchronous our procedural techniques tend to be domain specific languages that internally generate state machines anyways, often based in the join calculus (think futures or the async keyword in C# when joining).

However later in the day I had a realization connecting two things. We like to describe business situations in gherkin style (not strict) specifications.

Given: Some initial starting point
When: Something happens
Then: Something occurred

We as an industry have been very successful getting specifications written in this style. We regularly do analysis and write acceptance criteria using this style. Business users seem to have been fairly capable of understanding it.

This style is basically describing a state machine.

Given: some initial state
When: a stimulus
Then: Something occurred (message/transition depending on style of testing)

How can we be so successful with this style of specification and in the next breath say that business users can’t understand state machines? The trick is they don’t understand the actual machine but they understand (and can specify very well) the exterior behaviours of such a machine.

Try getting a business user to create for you the state machine to control a simple DVD player for you. Likely they will scratch their heads and politely become very busy so they won’t be able to attend the next meeting. Try getting them to specify

Given a video is playing
When fast forward is pressed
Then the play goes at double speed

Maybe the problem here that caused our move towards procedural style controllers was the goal all the middleware seems to push of having business users writing the activities as opposed to reading about/specifying/understanding them. I have yet to see in all the organizations I have been to a single one where the dream of having business users creating these types of long running procedures actually panned out. to be fair: I have seen it work but the business user had formerly been a developer and BA

Security Trends

When looking at systems and large scale preferences how much does malware, virus, and overall bad people trying to take advantage of others have to do with overall acceptance?

Yes I was going to write virii but after a quick search I found out that its actually wrong. Interesting

A friend of mine (non-technical) is getting rid of his mac. He is finding malware. One of the main benefits he found in having a mac was not getting a lot of malware where as windows was getting quite a bit.

Then I look at many windows users who are leaving Facebook because of all the malware problems. I think back to other social media and how people left because of spam/malware.

Is becoming popular basically the demise for these types of systems? Is there an overall acceptance/rejection curve? It takes a period of time for the attackers to target a given area (and they wait for critical mass). Once critical mass is attained they begin attacking and take a while to catch up. Once caught up though they will always stay ahead. Forcing constant trade offs between security and usability.

Oh well I will stay with linux.

Continuous Testing

On my build times post from “Don”

And you want to run your tests _every time_ you hit ctrl+s !?

Actually I have run into this viewpoint quite a bit. I see it most commonly from people who are not doing TDD. The reasoning seems to be that in the process of working on a feature they may save 20 times over a few hours then try to build. The “Save” mode is 100% for TDD workflows. If you are not doing TDD workflows then it probably is not for you. That said after having this discussion many times there are other options that better match non-TDD workflows. Let’s go through all four workflows.

Realtime / Saving modes

The realtime (as you type) and saving (when you save) modes are the default modes and are focused on people who are interested in very short TDD feedback cycles. Both automated both your build and will figure out which tests to run and run them after the build is completed. If you type (or save over the top) existing runs are fully or partially cancelled depending where they are in the run.


Auto will no longer automate your builds. Basically it waits for you to build in Visual Studio and when it succeeds will automate the finding and running of the necessary unit tests. This uses the build in VS as the “commit”, not the saving of file.


The last mode that is available is Manual mode. In this mode no automation will occur (except for us seeing your builds and keeping our graphs updated). The software will not automate any builds or tests.

Many people have asked “Why does manual mode exist?”.

Manual mode actually has a fairly powerful workflow associated with it that may be beneficial in some scenarios that are not good candidates for continuous testing. In this mode Mighty Moose works just like most manual test runners with a small twist there is a feature called “Run Related Tests” (ctrl+shift+y,r).

Run Related Tests is quite interesting for those who are not in a situation to benefit from continuous testing. Let’s try a quick walk through.


public void MyFirstTest() {

static class Foo {
public static int Bar(int x) { throw new UnimplementedException(); }

Now hit ctrl+shift+y,u with the cursor inside of the test. It will tell you that the test has run (failed).

With cursor on “Bar” f12 (goto definition)… replace code with

return 3;

from current cursor location ctrl+shift+y,r (run related tests). 1 test run one test passes. Imagining they are in different files now use ctrl+f6 and back in your tests. You can just keep flipping back and forth like this.

Tool users

This was sitting as a draft from 2009 so I figured what the hell why not publish it.

Just a quick passing thought. As I was reading this article on wired I started thinking about tool users in terms of software.

Many of us look down upon such users but is this a correct viewpoint?

As many who are close to me know I have in the last few years I have really moved away from the viewpoint that anything is “good”. Something can only be good or bad within a context.

One comment in particular struck me as particularly interesting in this article:

Burrowing owl bait. In order to attract its favorite beetle prey, burrowing owls collect mammal dung, then spread it around the entrance to their homes.
As with many animal tool behaviors, it’s not clear whether the owls are
acting out an instinctive sequence of actions, or consciously deciding
to collect the dung. Either way, though, those dung balls are tools.

Have you ever felt this way watching your nearest tool user? Are they instinctively going through a sequence of actions or are they consciously doing it? The other side of this would be the cargo cult. If the beetles were to go extinct would the owls still be putting dung balls outside?