The argument against HMI modeling tools

I was recently asked by a customer whether or not I would recommend use of HMI modeling or code generation tools. I thought maybe everyone might not agree with my viewpoint, so to spark some discussion I’ve posted my response here.

Let me start with some disclosures. I have in the past used Rational Rose quite a bit. It's a UML code generation tool, not an HMI one, but there is a good deal of similarity. And I've used Adobe Flash, which has many of the same characteristics as the other HMI tools you've mentioned. But I haven't directly used HMI tools myself, so my response comes from analogy to Rose or Flash, but not from personal experience. For what it's worth.

That said, I think that modeling tools are good for building small (or disposable) models, and not as good for long-term or big scale projects. I think this can be chalked up to a number of factors:

• Ease of use. It seems like the ease of use of a modeling tool is a good thing, and it is. But it also enables creation of a working model without having thought it through completely. The tools are designed to be used in part at least by HMI specialists. Because HMI builders are not always software engineers, they aren't necessarily entrenched in the ways of good software development. You can end up with a rat's nest because the model grew organically. If you're building an HMI through code, you don't have a choice—you have to think it through first. This doesn't guarantee a good design, but I would argue it has to help.

• Maintainability. You can't keep the whole of the project in a visual language like state machines—you have to drop into script/code at some point, whether that coding is directly supported in the tool environment or not. The physical separation of state machine vs code leads to a mental break, and means that it's far harder to think about. You've got to do multiple conceptual jumps to write/read/interpret. I don't know if this in itself harms maintainability, but it seems to be a hindrance once the models get rather complex. The break between visual and scripting makes it also much harder to do simple tasks. Search and replace comes to mind, but it's even a problem just finding the code that you're looking for. I find environments like Flash exceedingly frustrating in this regard, especially when it comes to someone's code other than your own. Code snippets are scattered "willy nilly" throughout the model. It might make sense to the original author, but not always to the reader. It's also hard to comment the visual model.  "It's obvious, so you don't need comments!" That statement is only said if you've never maintained anyone else's code, and everyone else knows the truth. Software artifacts like design decisions, explanations, log tracking, or PR management cannot be reasonably kept in visual models, so you lose that connection with the past history of the code.

• Familiarity. Would you ever want to reuse your first C++ program? Nope. Me neither. There’s a reason why I never put my freeware Songbird Studio program into open source.  I was too embarrassed to let anyone see how awful my first try at C++ was. The first few models in any language are not a good reflection of what you could build with the tool once you’ve had a few disasters under your belt first. The subset of knowledgeable experts on most HMI tools is quite small. In most organizations, it can be zero to start with. That leads to a "weekend experiment" type of feel to some of the models.

If you have experts in a particular tool, I know they can create well-structured and maintainable models. I’ve seen experts in action, and then it’s a beautiful thing.  And it's also very well suited for applications where the behavior can be wholly contained within a state machine.  I also think these cases are the exception rather than the rule. If the model is small enough, it might not matter. My own personal guideline is that if the model has become too big to be readable on a single sheet of paper, it's probably going to be a problem for your average software developer.

(You may read this and think I’m an old school dyed-in-the-wool traditionalist, but for the record I’d like to point out that I use the Eclipse IDE and not vi.)

What do you think?  I'm certainly happy to be proven wrong--do you have experience with these tools that you can share?