Thoughts in the Wilderness

One of the foundations of all Agile techniques is that of frequent iterations developing working software. I think maybe this is a developer-centric view of a deeper concept.

When we talk about iterations, what we are really trying to do is to work with a client to break down their “big goals” into smaller ones. We ask them to call these mini-goals “stories” or “backlog items”. Perhaps “goal” is a better word. Why…?

For one thing, it is less feature-attached. A backlog item or story usually translates to a feature. Maybe thats not the intention,but that is how it works out.

I’m digressing though. The main thought is that one or more iterations fulfill some client goal. This goal often corresponds with a release. That is a very concrete view of reality. Anything smaller is not meaningful to a client.

We ask them to shuffle backlog items around in order to decide which features make it into a release. What we should be asking them to do is to decide on the minimal set of functionality that meets their goal. Anything after that is meeting some other goal.

On another tangent…

When we ask developers to think in terms of backlog items and stories, we are making it too easy for them. They need to be made aware that the code they write has to work towards the client’s goals. If a “feature” can be avoided or changed by meeting the goal in another way, then the developer needs to realize that.

For example? …. The client proposes a feature. Under certain circumstances, when the user clicks the Save button, we should pop up a dialog asking them if they are sure they want to do this. They must click “Yes” to continue.

Seems like a pretty normal feature. It will make a fine backlog item. But what is the goal of the client? In this example (based on real-life), the answer was that we needed users to manually assert their intentions.

The implementation of a dialog box is a poor solution (as it almost always is). A better one was to supply a checkbox that became enabled (and required) when the right conditions occurred. Thus, the user had to pro-actively assert that they were sure this is what they wanted.

The point is this – when we tell developers to think in terms of backlog items, we are really saying “think in terms of features”. Experienced developers will intuitively sidestep this and get to the real goal. Less experienced developers will do exactly what the backlog item suggests.

If we had stated the requirement as a goal instead of a feature, then the less experienced developer would have had to suggest the details of the feature. This implies design, and thought. Exactly what we want in an Agile environment.

At my current (soon to be gone) workplace, we have a unique style of doing our UI….

I think I’ll call what we have Presenter-Model View with Controllers. (There is a View and there is a very rich Presenter Model. There are Controllers too).

We mostly drop generic container controls onto forms with zero or minimal code. We have extended properties to be able to bind those controls at design-time. (The appearance is determined at run-time). We have bi-directional deep (multiple dots) data binding, which allows the view to be completely driven by the Presenter Model.

The Presenter Model is more than simply a device for binding a form. It is a first class object in the system, used by security. It also supplies Validation.

Underlying that, we have a custom O/R Mapper with integrated support for database structure evolution.

It took a long time to set that all up, and it saddens me that the product will die soon

I just read Jeremy Miller’s ideas on creating a testable UI, so I thought I’d respond with my own. Mine has the distinction of being used successfully in a working product. That said, we are still aggressively developing the product, so it has not been proven to everyone’s satisfaction at this point.

Let me restate the problem first. It is very hard to test the logic behind a Windows application. Some techniques exist, but they all suck in their own special way. My technique also sucks in some ways, but it addresses the following design goals with varying degrees of success:

• must be able to test the interactions between controls on a form (one value changes, then another must update or become enabled etc.)
• must be able to test the processes that involve multiple forms
• there should be zero user-code behind forms. Thus, the forms can be worked on independently of the business logic, and all business logic can be tested without instantiating forms. Business logic can also be reused by imports into the system
• it should be easy for designers to build a form.
• component responsibilities should be well-defined so that it is easy for programmers to know where business logic should be coded (and thus to find it later when they need to change it)
• it should be easy to code, test and understand a previously coded sequence of actions (no confusing event-driven processes).
• it should handle the OO conflict of business logic that fits badly within traditional entity objects, mostly because they need to behave differently in different business processes.

Here are some of the main components:

The UI Interface is an interface definitions containing a method for each dialog that the user may see. It is defined at the business layer, but implemented in the GUI. This allows the business logic to be tested with a mock GUI.

The Context is a holder of state data containing everything in the user’s view. Everything you could want is in the context. Having a context keeps APIs simpler, and prevents the Wormhole Anti-pattern. It is also one of the main weaknesses of testing the system, because it is not obvious what the context needs to contain in a particular scenario.

The RichScreen is a model of a real screen . It is a class defined at the business layer, but with a rich event-driven interface to be able to handle changes to fields. It is bound directly to one or more forms (the view), and can be directly persisted. Like Windows Forms, RichScreens have a lot of generated or inherited plumbing code. An instance of a rich screen may be thought of as a Business Entity.

The Commands are executable actions. They are sequential controllers (my own term) – this means that they strongly resist using events, thus ensuring readability. They have a single “Execute” method, and are often constructed with a reference to the context. Commands often make use of the UI interface. They are usually constructed by ExecutableMenus, which are rendered as menus or buttons in the user interface.

To bring it all together, a simple scenario:

1. User chooses an “Add Order” menu item
2. The ExecutableMenu attached to the real menu creates an Add Order command with a simple context. The Add Order command is executed.
3. The Add Order command creates an empty order, initializes the order date to today, creates a RichScreen instance, and instructs the UI implementation to display the order.
4. The UI implementation displays the order form. Data binding to the RichScreen is automatic.
5. User enters some data and presses “Confirm Order” button.
6. The context validate method is called, and uses metadata defined in the RichScreen to validate the data. Problems are discovered, and automatically highlighted on the form. The UI implementation is told to display the validation message, which it does with a message-box.
7. The user corrects the data and re-presses “Confirm Order”.
8. This time the validate completes and the context Save method is called. The order is persisted to the database
9. The Add Order command continues, and sends a message to the order-system queue.