This is been on my mind for a while…

I’ve worked with several consultants from Lombardi and I feel for the most part, that they deserve high marks.  Somewhere in the A to B+ range.  If someone didn’t know the answer to our problem, they would do their best to figure it out.  They were very agreable and pleasant to work with.  Also, they were very informative and tried their best to educate our team as much as possible.  And when we ran into an issue, they were empathetic and felt our pain.

Lombardi also has an online Support site.  Whenever I have submitted an issue, they have been very prompt, very helpful, and very easy to work with.

Basically, everyone from Lombardi that I have come into contact with has been a pleasure to work with.

Grade: A

 

 

I have no clue what a narrative is but don’t you dare ever go and delete one.

Today we got an error message that basically said: "No more error info available."  So I started trying a bunch of different things trying to figure out what was wrong. After working on this for over  4 HOURS, I come across a line in the debug log that says "Premature end of binary stream after reading 0 bytes".

Searching their website for that text lead me to exactly 1 hit.  The result said that the problem was that a process item had a "narrative" and then someone probably removed it.

Normally, I would have dismissed this error as unrelated.  However, earlier I ran a dif tool that I wrote (why Lombardi doesn’t know how to write this kind of tool is beyond me) and saw that someone had changed a description and removed a "narative".

So - I stuck a narrative back in and now everything works.  Another 4 hours of my life I won’t get back because of Teamworks.

I’m just lucky I’d written my own dif tool or I’d still be looking.  I pity anyone that doesn’t have the ability to do a DIF on Teamworks stuff.

 

 

I’ve been monumentally dissappointed with Teamworks Authoring environment for a long long time but this one really takes the cake.

You can embed items inside BPDs and services.  When you embed something there is a tab that allows you to map data from the higher level item to the lower level item.   

For Services, there is a check box for every parameter that allows you to "Use Default".  This is good and natural behavior.

But for BPDs, there is no visual indication that there are any defaults or not.  To use the default value, you must first know it exists, then leave the data mapping blank.

Why is this so incredibly WRONG? 

1) Because we have 2 different Data-Mapping interfaces that behave differently.

2) You can’t tell if a mapping will generate an error or not without openning the embedded item.

3) If an item is set up to use defaults and the default is later moved, there is no indication from the outside that it will crash.

 

Lombardi Tech support finally explained this to me.  I pity anyone trying to develop a process that doesn’t understand how this works.

 

 

Teamworks services define input and output variables that, much like a function takes arguments and returns values. One feature of both inputs and outputs is the ability to set default values. However, it can be tricky to determine when the default output value is first initialized. There are three logical choices:

1. When the service starts
2. When the service completes
3. Some nebulous time in between

The problem for output variables seems to be that the answer is none of the above. Although you can set a default value just as you can on an input, it has no effect that we have been able to find. This is not an isolated problem when using Teamworks either, as there appear to be many features that have been implemented differently in different places or that appear to have never been implemented at all. In addition, there are other features that should never be used as they make long-term maintenance and debugging very difficult. I will touch on some of these soon.

There are some features of modern software that are just accepted as required and you never even consider to ask about them when evaluating software. One of these features is the ability to undo an action, preferably an unlimited number of them. However, the javascript editor in the Teamworks authoring environment does not have an undo. I repeat, you cannot undo an action in the javascript editor. How this happens I don’t know, but this obviously seriously effects the usability of the editor. You are left with the choice of never making an error or using the editor of your choice and pasting in your code when done. If you do use the editor of your choice you lose the autocompletion the authoring environment offers, but the autocompletion really isn’t that useful.