Architectural Issues in Large Motif Applications

I. Introduction

One of the hottest points of debate in software engineering today seems to be the whole arena of methodology. By "methodology", we mean the attempt to answer the question "How exactly should be build this software?" This is a large, tangled, and potentially confusing topic where there is no one correct answer, and often several wrong ones.

How one arrives at these answers can have profound impact on the financial and political health of a company, not to mention the mental health of the developers. Concerns include the overall architecture, which tools to use (and how they ought to be used), which languages to use where, and, of course, the ever-looming pipe-dream of cross-platform portability.

In this article, your bubble may be burst since there will be no magic bullet offered. No such bullet exists. What will be offered is an analysis of the concerns that are faced in developing large Motif applications. The author will not (and should not!) presume to make architectural decisions for the reader, but, rather, will help the reader to make their own decisions in the most informed manner possible.

II. Problems that exist now

In development environments today, any problems exist which undermine projects. These problems cause projects to go over schedule and cost, to become unmanagable, and to be disappointing in both performance and features. Here are some of those problems:

a. Misconceptions regarding "tool"-mania

Who would ever dream of coding Motif without a GUI builder? Lots of people.

It seems sometimes that there are more tools than user applications in the Motif market. There are two factors that have made this so: the unwillingness of other developers to make products for anyone other than their own kind (who wants to understand the end user?), and the notion that developers must simply have more and more tools. Surely the task will be utterly impossible without some high-level tool, won't it?

In the minds of many managers, the "tool" does all the real work while the developer merely turns the cranks and levers. Thus, investing in the "tool" is more important than investing in the people using the tools. Several problems arise here: rather than making the developers more expert, the tools often insulate developers from learning processes which would have otherwise occurred, stunting the growth of developer skills. Also, methodologies built into the tool by the tools' vendor are often imposed on the developer, not because it was the right thing to do, but just because the tool is being used. So the user is not only prevented from learning the underlying technology they use, but also restricted in having any say in methodology, since this is often dictated by the tool. The end result: a high degree of productvity in making mediocre software.

b. Priorities driven by industry fads

Certainly it is intriguing to get design ideas from magazine articles (like this one), but it is dangerous to accept the notions of others without some scrutiny. Some goals in software design are admirable in general, but not that helpful in specific cases:

C++ wrappers: while it is quite desirable to move ones development from C into C++, it does no good unless C++ is used well. Thus, it may not be of much benefit to wrap Motif widgets into C++ wrappers, since widgets have a good object oriented design already. Novice C++ programmers might not improve much upon what Motif already offers. Wrapping Motif in C++ is worthwhile only when it clearly improves the object oriented model of the overall product.

Cross-platform: it is very popular now to make cross-platform portability a paramount goal. This often leads to skewed priorities; being "portable" over Motif, Windows, Mac, and whatever often overshadows the overall quality of the product. Many "cross-platform toolkits" limit the ability to use the robust features of a given windowing system, and also intoruce more overhead. Cross platform portability, in the truest sense, cannot be fully achieved without sacrificing quality of user interface designand performance. Idiosyncracies of the toolkit often complicate development, thus stealing away any alleged "saving" in development time. The moral of the story: being platform portable is not a virtue if the end product is poor; you just have lousy software on more different machines.

The priority of being cross-platform, how to become cross-platform, and where one ought to be cross-platform, must all be carefully considered. Cross-platform portability especially is not a magic bullet, it is often a can of worms.

Market value of a platform: this often overshadows the User Interface value of the platform. Often marketing decisions are made such that a product should be moved to a certain platform, but no attempt is made to fit the product into the style guide of that platform. Moving software from XYZ to Motif is of limited value unless the features of Motif are used well. User Interface quality is not the place for technological shortcuts. The end user should not be short changed.

c. Architectures that scale poorly

UIL: In Motif, the choice of using UIL or not must be made. It is important to realize that UIL can be problematic in larger applications. The benefits of rapid prototyping and form/function decoupling are clear in a smaller product, but as applications grow larger, UIL's problems emerge. More complexity must be introduced into the application, must of it totally arbitrary. Name binding tables become unwieldy in size. Widgets must be insured to exist before they are acted upon, requiring more code. Often, that extra code is in places where more complxity is not appreciated.

Cross-platform toolkits: often show glowing prospects in small demonstration programs. But when used in a large complicated product, the Style Guide for any given platform tends to be compromised more and more. The end result: rampant compromising of Style Guide makes the larger application unbearable to use. Windowing systems were supposed to make thngs easier, remember?

Archaic data models: When porting old non-graphical software to Motif, archaic data models are often carried over. The entire user interface design can end up being driven by this data model (or a command line syntax). The resulting product is often no better than the original. This older architecture is typically very modal and must be overhauled in order to use the full features of Motif.

d. Technological "agendas"

One of the reasons that cross-platform is so popular, is that it offers a way for one platform to be coerced into looking like another. For example, virtual toolkits originating from a Microsoft Windows environment will tend to impose Microsoft look-and-feel (and programming style) onto other plaftorms. To the Microsoft lover who resents Motif, this is a virtue. To the Motif lover who resents Microsoft, it is blasphemy. Neither case is really valid. Motif should be allowed to look like Motif, and Microsoft should be allowed to look like Microsoft. There is no technical merit in trying to get other windowing systems to be more like your own. Such efforts are purely political.

Often a personal favorite language, design, or tool will be used at the expense of future maintainability. A prima-donna employee or a closed-handed consultant can steer a group towards a technology that they alone understand. While this is very good for that individual, it can be disastrous for the group if that individual leaves. Only consider technologies that the existing staff can assimilate. Secret skills do not make a good foundation for software.

Advanced software designs are often used, not so much because they will make a better product, but as an interesting intellectual exercise. "Wouldn't it be cool to use C++? Doesn't everybody else?" If the existing staff is not yet ready for C++, then using C++ will most definitely not be cool. This is not to diminish the likes of C++; advanced software techniques are great, but only after the staff is trained to use them.

e. Architectural short-cuts

Old character based software is often ported to Motif, but seldom the right way. The User Interface is often tightly bound to the data model or command line syntax. Good user interface design requires these to be decoupled. The highly procedural nature of the old product is usually burned into the underlying core of the application - often the core must be redesigned to eliminate simplistic assumptions of what will be done when. Modality must be replaced with modelessness. Limitations in the data model often restrict what can be done in a graphical environment, these must be done away with.

Failure to overhaul old character based products is a favorite shortcut, but the loss in user interface quality is tragic. Once again, the end user is short-changed in an inexcusable way.

III. Decisions to make and Priorities to set

So there we have a staggering set of pitfalls that large Motif projects can fall into. The obvious question is how to avoid them. While there is no magic bullet, there are decisions that can be made carefully. Wise decisions can help guide a group towards the correct language, tools, and architecture.

a. What language is best now and tomorrow?

While the advantages of C++ are clear, this does not mean a group is ready to use it. The level of training may not be enough to insure that C++ is used well. Also, the conversion of a large body of code from some other language to C++ may be in order, but the scheduling of such an effort is another matter. For example, a group may be willing to convert to C++, but it should be done after a critical release is completed.

A body of code can also be written in a language other that C++ (probably C), but it may already posess a level of modularity and design quality such that converting to C++ will not yield much benefit. One might be better off to leave the code in it's current language, or, perhaps, to mix languages. For example, an old core of functionality written in C could be simply cleaned up and made as modeless as possible, but new code for a Motif user interface might be written in C++.

b. What is this GUI Builder actually good for?

GUI builders have a distinct set of strengths and weaknesses. Their strengths include:
Their weaknesses are:

When a GUI builders' data files are incorporated directly into version control it makes automatic builds more difficult. This is due to the fact that the GUI builder output will almost always require some manual change, no matter how small, in order to build the product to satisfaction. Each new update of version control undoes those changes. Automatic builds become agonizingly manual.

Some GUI builders introduce new layers of API, as an "improvement". These new layers impose more overhead, require more learning of non-standard technology, entangle the product to the GUI builder vendor, and seldom introduce benefits the developers could not have made themselves.

The best GUI builder, in the humble opinion of the author, is the least intrusive. It allows rapid prototyping without trying to control other aspects of development. It spits out code which can be cleaned up and rolled into the development process, leaving the GUI builder behind.

c. What architectural model, if any, do we have?

GUI-Engine decoupling: In a large application, the User Interface should be strongly decoupled from the underlying functionality (the "engine"). This decoupling is often poor in non-graphical software being ported to Motif. By improving the decoupling, the engine tends to improve in modelessness, and changes in the User Interface do not break as many underlying engine tasks.

The underlying engine should have strong encapsulation of it's data and be accessed by a well-defined API. Also, no data types or references to the windowing system should occur in the engine, these should only be in the User Interface. This makes porting to another platform easier, one must simply reimplement the User Interface layer, and that can be done using the full rich features of the windowing system in question. While this is more work than using a watered down "cross-platform virtual toolkit", the opportunities for User Interface quality are greater.

Multiple Instance models: if an adequate object-oriented design is used, then more than one instance of some data can be supported. This can offer vast new power to a user over an older non-graphical user interface. For example, rather than loading one image, document, chart, or whatever, at a time, the user could be allowed to load as many different images, documents, etc. as they wish, each in a separate window. To achieve this, the underlying engine must be smart enough to support an unlimited number of sets of data. Many engines can only focus on one set of data at a time, thus only one image or document could be displayed at a time with any meaningful engine support. A more robust engine would use some sort of "handle" to identify what set of data it was working on, and the User Interface would reuse it's presentation functionality once for each set of data, with each instance presenting a different set of data.

Document-View models: there are several variations of this object-oriented model, but they all have the same theme - allow many diverse "views" of a given set of data ("document") to all exist at once, typically, each in a separate window. For example, a "document" might be a set of data describing some numeric data collected from an instrument; there could be several "views" that could simultaneously support different presentations of the data. One "view" might be a graph window, another might be a spreadsheet window, and so on. Each view would give some sort of presentation of the data, and some views might change the data. the document and all views would send and recieve messages between themselves so they all could have updated knowledge of the data. This model requires some work, but it allows excellent functionality for the user and extensibility for the developer.

d. Application Framework: what exactly is it?

The term "Application Framework" means many things to many people. To make a long story short: an application framework is a set of reusable code which provides all the tedious, repeatable, common parts of an application. For example, an application framework might contain utility functions that simplify the creation and management of menus, among other things.

Assuming you wish to have an applciation framework, what should it contain? First of all, it should provide strong support for your chosen architectural model(s). For example, if you are using the document/view model, than a useful application framework might contain functions that help to manage the creation and deletion of documents and views, no matter what kind they are. Also, document/view messages could be facilitated by such functions.

Enforcement of Style Guide is another important feature in an application framework. Suppose your application framework has utility functions to help build popup dialogs. The functions might automate the construction of certain repeatable parts of the dialogs, like the Motif-compliant action area at the bottom of the dialog.

Encapsulation of tedium is an essential part of an application framework. For example, widgets whose state control the sensitivity of other widgets can have this behavior automated by clever utility functions that install context-independant callback functions.

All these can save much coding. One can purchase existing application frameworks, some of which offer excellent object-oriented models, or one can create their own, customizing it to their exact needs. It is not an excessive or difficult task to make an application framework of your own, and you can then have greater control over your own destiny since it is your own.

e. Does our old code need an overhaul?

Here is a painful decision for many. As described before, most old character based code needs major revision before it can be connected in a modeless way to a Graphical User Interface. This can be a big task, and great political courage may be required. But if it is not done, and if it is not done right, then User Interface quality will probably be at an emberassingly low level. Maintainance costs of the software will be greater since both bugs and new features will be harder to deal with.

Does that old code need an overhaul? Almost always, the answer is yes. Just prior to porting into a GUI is an excellent time to do such an overhaul, since the GUI requirements will help to correctly guide you in your overhaul strategy. You can pay the price now or later. Do the overhaul now.

f. Will we beat the market or do it right?

Many of the short-cuts described up to now are taken in order to beat the market. By putting out shoddy software sooner than anyone else, you have provided your competitors with a lower hurdle to jump over. Think about it.

IV. Tools versus People

One of the most important decisions to make is often the most overlooked. It's not so much a decision about a given methodology or some tool to buy. This is more a decision of mindset, of management style. What we're alluding to is this: What is the investment priority, tools or people? Will you invest in the latest fad gizmo product that claims to put you on the cutting edge of technology with a staff of low-cost chimps paid by automatic banana pellet dispensers? Yes, we're exaggerating, but the point is valid. Many managers perfer to spend a lot on a tool, then put it in the hands of less skilled (and less paid) developers. They value the tool over the person.

Managers who lack technological savvy are sometimes mislead by advertised promises of GUI development tools. The message the manager gets is this: "I use to take five man-months to write an application. Now I just take five hours - well, I'm off to the beach now..." The guy in the picture looks happy enough. Did the ad make inflated claims. Perhaps, or perhaps not. The point is that the manager got this message for whatever reason. And, hungry for easy answers and technological shortcuts, this message is exactly what the manager wanted to hear.

Add to that the managers reluctance to train the developers since that would impact their schedule, cost more money, and, heaven forbid, make the person more viable in the job market. The end result: a manager who invests in tools, not people.

Clearly not all managers do not fit this bleak picture. But the author has seen some who have, and it is a problem the software industry must reckon with.

This author believes that investing in the skills of the developers should be the first priority. It is better for both the company and the employees.

When a novice is given a tool, the tool may allow the novice an artificial boost in productivity, but the workmanship of the novice will very likely not be enhanced by the tool. The novice will simply create mediocre results faster. Further, the tool will tend to insulate the novice from having to learn anything, so they are actually held back in their learning process. The tool can end up having a disturbing crutch-like quality.

In contrast, the expert with a tool can use the tool for some benefit, but often the expert finds some deficiency in the tool, unnoticed by the novice, that impedes their work. The expert is thus frustrated by the tool in their effort to achieve their greater level of workmanship.

Furthermore, the expert often gets little gains in speed from the tool, since their deeper knowledge of the underlying technology makes them more efficient in the first place. The classic example is the expert who, by virtue of their well-tuned convenience functions, can make a menu more rapidly in code than with the tedious interactive process of the GUI builder.

By offering interactive techniques, tools are not always faster than expert people. They are only easier for a novice to conceptualize. The real problem, therefore, is the novice level of the developer. And the solution recommended by the author is clear: invest in the person first. Train them well. Let them become an expert. Then, if they see value in a tool, get the tool.

V. Summary

There is no magic bullet, no gizmo tool, no flawless methodology, no easy answer. To decide on your own architecture, languages, methodology, and possible software tools, you must make your own unique decisions in the most informed deliberating manner possible. The observations made in this article can help you to make these decisions.

Look for real-world cases where a given tool or approach worked, or even better, where they failed. Understand the reasons why, and then determine if the other organization is similar enough to your own to expect the same results in your own.

Don't believe everything the ads promise. Also don't believe what the magazines say, not even this one! Scrutinize the views and recommendations set forth, incuding my own. Remember, we may offer expert opinions, but they are still opinions.

Finally, your most valued assets are clear goals and expert people. These should be your first priorities. Clear goals will help you stay focused on what really matters as you go through the myriad of techno-hype that is out there. Expert people will make better decisions and products, often just as quickly as a novice with a tool.

[Back to top]
[Back to home]