May 93 Editorial
Volume Number: 9
Issue Number: 5
Column Tag: The Editor's Page
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 - e specially 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
Editor-in-Chief
footnote: My thanks to the folks at Taligent for some of the background information.
The Publisher's Column
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.