Making Software a Viable Business Again

By Neil Ticktin, Editor-in-Chief

Before we get into this topic, I would like to announce that MacTech Magazine is now online on America Online, AppleLink and CompuServe. Now, you can download information about the magazine, order things, renew your subscription, and most importantly, download the source files that accompany issues. See Mag Online for more information.

To the pulpit

For some time now it has been more difficult for small (and large) companies to make a healthy profit in the software business. There are many reasons for this - competitiveness, saturation of market, difficulty in finding talent, under-captilization, dealer and distributor channels, etc

Many of these are business problems that would require a whole magazine to themself. But, there is a fundamental technical issue that we as the ‘mavens’ of the computer industry can address - revising (or should I say, revolutionizing) the development process.

The Problem

Plainly stated: today’s computer technology has become so complex that it has completely overwhelmed the conventional development processes that originated in the 1960’s and 70’s. We’ve brought the hardware into the 90’s, but we’ve neglected the development process.

In software alone, graphical user interfaces, extensive operating system feature sets and changing standards in OS’s have created the incredible task of ‘keeping up’. Application developers can spend as much as half of their development effort conforming to system-software requirements.

The industry’s upgrade approach has turned into feature wars. Innovative ideas just aren’t coming to market anymore. The end result is that 10% of the software packages make up 90% of the sales. The average user only uses 20% of the features that are in a specific piece of software. It’s interesting that there are feature wars when users don’t even use the additional features!

Corporate ‘in-house’ developers have similar problems. They are making custom solutions that always need to be done yesterday. Furthermore, the average MIS department uses 85% of its resources to just maintain software.

From an economic viewpoint, the computer industry is entering the mature phase of its life cycle. If this is the case, there are two options we can take: let the industry decline, or better yet, give it a kick in the butt (technically known as revitalization)!

Everyone's got the problem

Some people will tell you that if you don’t have the resources to play with the big boys, don’t play. It’s true; not everyone has the marketing muscle and cash flow to talk vaporware the way Claris did with MacWrite Pro (although it did start shipping as I’m writing this). There are plenty of examples of small companies that ran into one major problem and as a result, lost their cash flow projections and went under. Yet, software shouldn’t require luck and excellent programmers and timing.

The big boys in the marketplace are in better, but still unacceptable shape. They sell so many units that even with an incredibly innefficent process, they have enough slack to deal with large programming, technical support and quality assurance staffs. They too would benefit significantly if they could produce products faster and with less resources.

Imagine a company being able to produce more products, and with more reliable time schedules. Innovation instead of constant refinement. Software could truly find its way to solving a much greater number of problems. Even with few resources, developers could attack problems that they normally wouldn’t.

But all of that is just a dream given today’s methodologies.

Is there any hope Obi-Wan?

Obi-Wan Kenobi I’m not, but there are players in the market who may be. Today, we already have a number of vendors - Apple, Symantec, Component Workshop, and many, many more - who provide class libraries that help.

Object-oriented programming brings a lot of benefits to the table. The problem with object-oriented programming today is that it is not integrated into the operating system and it has a steep learning curve - especially with those libraries that are particularly rich. Reusability of code is also lower than originally expected. The reason for this seems to be that the tools are not well integrated enough with the development environment. Furthermore, because the objects are based at the operating system level, there is less commonality between tasks (and therefore objects).

Taligent, on the other hand, is approaching the problem by creating an object-oriented operating system from the ground up. Their stated goals are: reduce software development cycles from years to months; foster innovative customization; level the industry playing field; better align information technology with business needs; be open and extensible at all levels; offer extensive native functionality; be portable, adaptable and scalable; deliver integrated development tools; provide backward compatibility and investment protection; and ensure a breakthrough in software development productivity and innovation.

They are definitely biting off a lot here. If you ask them, they don’t plan on shipping anything until the “mid-1990’s” (whatever that means). What can we do? Hold them to their promises - particularly in the area of revolutionizing (instead of just enhancing) the development process. If Taligent comes through just as complex as a class library, forget it. But if they somehow come up with a way to be complete without having the steep learning curve, and if they provide the tools to make it so that development can be done fast - now, we’ve got something! Good luck, Taligent - we’re cheering for you.

Neil Ticktin

footnote: My thanks to the folks at Taligent for some of the background information.

Changing Concepts - Economics
and System Documentation

By David Williams, Publisher

Recently, two completely divergent things have Neil and I thinking about policies and change. The first, and most far-reaching, is Mr. Clinton’s new economic plan. The second, and more immediate, is the expansion of our “Documentation Services” division, in which our staff writes documentation for our client’s programs. The reason I came to connect the two is that before making or changing any policy in our company, we first try to get a good grip on the causal forces at work, and thus avoid addressing only symptoms. As Mr. Clinton attempts to push his economic approach through Congress, it seems to me that like every President since FDR, he's attacking the symptoms, and ignoring the actual problems.

It is easily arguable that the problems of software documentation are simpler than those of the economy. So, lets take a simplified look at the documentation environment with an eye to developing documentation policy, and then analogize to the development of economic policy.

The central problem of software documentation is that users insist that programs should be intuitive, and shouldn’t need very much documentation to begin with. What is needed should be simple to understand, yet technical enough to answer any possible question directly, and without much thought on the reader’s part. In other words, users want to be “rich” in program-using ability without having to “work” to learn or think about the program. They want instant access to great detail without having to sift through any voluminous information.

At the same time, developers want to avoid every user calling them with questions, and they want their documentation to encourage users to buy the program rather than pirate just the software. As Caroline Rose pointed out in develop, if the documentation is really good, users will read it, learn more about the product, and be happier and less likely to switch to a competing product that advertises a function that they already have but don’t know how to use. In other words, if the developer fails to educate the user, it is the developer’s fault. The user has little or no obligation to work at a problem. The risk, as it were, is on the developer.

Most documentation today falls into one of two categories: too much, or too little. In order to avoid questions from novice users, the documentation frequently provides a click by click explanation of each function involved, followed by some more technical stuff designed to avoid questions from experienced power-users.

This approach addresses the symptoms, but not the true problems. The real problems are that every user needs to fully understand the overall concept behind the program before addressing the “how to” aspects of it. Power users only need to fully understand the concept before they will be able to intuit all but the most technical aspects, while novices need to understand the concept that the clicks are working on before the clicks themselves will make sense.

The moral of this part of the story is that all documentation should start with a presentation, in as non-technical a manner as possible, of what the program does and how. Further, each succeeding chapter should refer to those concepts so the reader can jump quickly to the detail required. While I have encountered very few manuals that contain such a format, we have nevertheless made it a policy to design all documentation we write around these rules. Thus, we attempt to attack the problem directly, rather than the symptom.

As to Mr. Clinton, he’s using the same strategy as most developers. Create policy to stop the loudest complaints without starting any louder new ones. This won’t work any better than most developer’s documentation does. Reforming the health care system is impossible without a complete restructuring of the tort system. As long as a health-care provider can be sued for hundreds of millions for an error in judgement, the cost of treatment must remain high. The tort system also cripples our industry. As long as the law looks to whatever deep pocket it can find to “compensate” an individual for injuries relating to the unavoidable risks of life, our industries will never be able to compete with foreign companies. As long as the poor of this country are treated as welfare problems rather than potential work trainees, there will never be enough money to go around. As long as the tax system is so complex that all but a few highly trained lawyers and accountants can’t understand it, people will continue to perceive it as unfair, and will try to avoid paying.

This is indeed a time of many changes. I hope the administration of both our government and of our development firms will seek to address the real problems, and avoid attacking only the symptoms.