Well normally I don’t have time during work to write these little posts but today our Teamworks Development server has been down for 3 hours and I’ve run out of other things to do while waiting for it to come up.

So I’d like to take a moment to highlight that over the course of 8 months, the pain involved in debugging a failed Process Instances has reduced significantly.

Then: Extremely Difficult and Painful
Now: Slightly Difficult and Painful

By my definition, there are 2 category of Teamworks errors that can kill a Process Instance:
 - GOOD (those that provide an error message)
 - BAD (those that do not -  i.e. "No error information available.");
 

By this definition, most of the errors I get are GOOD errors but I still get 1 BAD error every week or so.

When I started out, it usually took me an hour to resolve a GOOD error and days to resolve a BAD one.  Now, I can resolve the GOOD errors in a couple of minutes and the BAD ones only take a couple of hours.

And by "resolve" I mean the error message goes away and the process instance doesn’t go into a failed state.  It does NOT mean I know what caused the problem nor know what I did to make it go away.

With experience it does get easier so I’m glad that has improved. 

But I’m still disappointed I have to waste hours on Teamworks error with no error information.  I’m baffled that Teamworks can have an error and not be able to tell me where or why it occurred.

:-(

 

After doing a major deployment and thinking about how to manage later deployments of bug fixes it really hit me just how poor change tracking is in Teamworks. Specifically, there is basically none. Change tracking consists entirely of an audit trail that tells you who changed a file and when, but not what they changed or why they changed it.

The Teamworks change control model is a simple Check Out-Check In one. When you make a change to a file the authoring environment checks it out. This puts an exclusive lock on the file until you check it back in. If any other user wants to make edits to the file they must wait until you check it back in. This may have been state-of-the-art in the 1980s with RCS (Revision Control System), but not today.

There is also no concept of meta-data associated with these audits, meaning you can’t even associate specific changes with specific fixes. For example, say you are trying to figure out which three services you edited to fix a bug from six months ago similar to one that just cropped up. There is no way for you to find those changes. This makes the audit trail essentially useless for auditing. A change that tidies up the layout looks exactly the same as a change that rewrites the whole service. Its only seeming use is seeing who last edited a file when I need it so I can tell them to check it back in if they are done with it.

Supposedly Teamworks 7 will have real version control, but I am skeptical. First, this is a pretty essential feature to get to version 6 and still not have. To me it shows that they are not dogfooding their product in any meaningful manner. Second, having spoken to a couple of consultants about the new version control coming to version 7 I have real fears that they are implementing their own solution instead of integrating something like Subversion. If this is true it is pretty much guaranteed to be buggy.

On of the first things you will notice when you start to use Teamworks Authoring environment is that every window pane is too small.  You can maximize the too-small pane but then it takes over your entire window at the expense of the other panes.  So everytime you want to look at something, the process basically goes like this:

• Restore current pane to normal size
• Go to new pane of interest
• Maximize new pane

 

This means you can only look at 1 window at time.  And since there are no hot keys (that I can figure out), it is very slow to switch between these views. 

Probably the worse offender is the Data Mapping tab in the Property Pane.  The image below shows how you map data into and out of an embeded component.

 

 

To reference local variable in a service you specify the variable name with a "tw.local." prefix.  So to reference equity-in-property, you must type in tw.local.equityInProperty.  Due to the design of the Data Mapping pane, all you see is the "tw.".

So essentially, in the normal view,  you have no idea what is mapped to the component.  This makes the Data Mapping view nearly worthless in its normal size.  The only way to get anything done is to maximize the pane and sometimes you still need to click into the field and press END to see what’s in the edit box.

A better solution would be for the Data Mapping pane to have 1 column and we can scroll down to see the output mappings.  At least that way, we wouldn’t have to maximize the window just to see what’s mapped to what.

Trying to work with the Data Mappings tab/pane is like trying to tie your shoe with only one hand.  It can be done but its a lot harder than it needs to be.