Addison Wesley has been a good Ada publisher, and
hopefully is making a handsome profit by it, even
though I don't see their Ada books in stores that
often (I always have to order & wait a week or so).
Now, AW has a series called "Object Technology" with
the "Big Three" in the OO world as series editors:
Ivar Jacobson, James Rumbaugh, and our old friend,
(Booch, you will remember, got his start as an Ada,
OOD, and software engineering guru back in the days
when the public perception was that each one of those
three things implied the other two. Since 1993 he
hasn't made many public statements either way about
Ada, though his company, Rational Corp., is one of the
leading Ada vendors.)
Seems the "Big Three" have struck gold with a new
modeling language, UML. Most of you have heard of
UML by now, but if you haven't, think of it as the
Microsoft of OO pictorial representations. All other
OO competitors, better or not, have been either
defeated or assimilated. See:
I am currently reading one of the books in the
series, and it's not bad: Real-Time UML by
Bruce Powel Douglass. The book is actually even-
handed in its treatment of C++ and Ada (though there
are more C++ examples) as implementation languages.
On the same page there are two footnotes with
snide remarks about each. I get the impression that
he likes Ada 95. He also seems to understand it OK;
surprise! It's nice to see even an honorable mention
given to Ada these days in "popular" literature. See:
The programming public at large, when it hears the
word "Ada", seems to react similarly to those times
when it hears the words "MS-DOS", except when it
comes to real-time or safety-critical systems (of
course I am refering to people who have actually
heard of such things). In the ongoing battle of
"perception", Ada, where it is not considered an
anachronism, is, as we all know, seen as a niche
But what an important niche it is! And, as it turns
out, it is a growing niche. More and more real-time
systems are being built all the time. And John Q.
Coder is hearing more and more about such systems and
wondering about them in his future. This niche may
one day be as big as some "mainstream" programming
Of course, you and I know that Ada is ideal for
such systems. And so it happens that many non-Ada
people have heard this also. The important thing
is to broaden this perception until everyone
understands it -- to make a USP (Unique Selling
Proposition) out of it. A little marketing history:
Rosser Reeves, an advertising prodigy, invented the
USP concept. To describe it I will borrow some
words from _Reagan's America_ by Garry Wills:
"What is the single strongest claim that can be
made for this product in terms of its desirability?
Reeves cautions that the USP must be true, though it
need not be the whole truth or a truth specific to
the product of which it is asserted. Once the USP
is found, the advertiser must not tire of repeating
it, or lose faith in its efficacy because hs has
become bored with it ... Reeves argued that the USP
will gain and maintain 'penetration' if it is simple
and is asserted early and often. Even if it makes a
claim that competing products can legitimately echo,
a strong USP, advanced early and often, will preempt
the claim." (p 381-382)
The USP concept, as developed by Reeves, lends itself
to sound bites, one-liners, slogans, jingles. The
necessity of grabbing people's attention with one
concept (not necessarily reduced to one *phrase*),
simple, straightforward, high-impact, is unavoidable.
What is Ada's USP? I think in the past we have
focused on "safety" or "reliability" as USPs for
Ada: "If it must be done right, it must be Ada!",
etc. Those statements are strong, have been made
often, and I believe to some extent have made
penetration in the programming community's mind.
But I believe that these approaches fail the
"desirability" test proposed by Reeves. How many
developers are really *in their hearts* worried
about reliability? After all, most of them aren't
working on nuclear power plant software. And of
course, they know they are already good programmers:
"Why do I need Ada when I'm already on top of my
game?". The fact that they spend 50-60% of their
time in a debugger tracking down memory leaks
doesn't register on their radar screens as an
indictment of their methods or tools. In general,
the reliability of a programmer's own software is
not *perceived* as a problem -- "Bugs? In *my*
code?". The blind spots that we have to our own
coding inadequacies are well known to almost every
student of the psychology of programming, from
Weinberg to today.
So, what would be a *desirable* USP for Ada?
Let me propose one that I believe has the
power to penetrate and attract: "Ada is the
most powerful language available for developing
real-time object-oriented software".
Let me repeat that:
"Ada is the most powerful language available for
developing real-time object-oriented software".
"The most powerful language you could use for
that real-time system is Ada."
"If you want good real-time software, take
advantage of Ada 95's powerful OO features."
"The powerful real-time and OO features of
Ada 95 make it the ideal language for developing
modern RT software."
Now allow me defend my choice of this concept as
It's a true statement -- easily backed up by
a recitation of Ada's features. Most
knowledgable experts would agree. It will
It's a strong claim. It asks for response.
It suggests a course of action. It plants
a flag in the ground and claims it for Ada.
It's also desirable. Everyone wants OO. It's
not even a buzzword any more -- it's the status
quo. And more and more developers are keen on
"real-time" things. In terms of perception
(what do you think I have been talking about?),
OO and real-time mean "the future". (Of course,
other variations of the USP may actually include
the word "future" -- in the old marketing
tradition of performing a frontal attack on
a negative perception, in this case the idea
that Ada is a language of the past).
For your instruction, I must point out two key
words in the variations of the USP given above:
"Power" and "Features". Perform this experiment
at a local bookstore: go to the computer section
with a notepad; look at the blurbs on the back of
each "popular" programming book (you know the kind
I'm talking about "C++ in 21 Days", etc.), and make
a mark each time the word "power" or one of its
derivatives is used. Experiment #2: go to a
software store with your notepad and look at
the "software development" packages being sold;
for every "feature" listed on the package, make
a mark on your pad.
Go home with a pad full of marks.
Now, I wonder why book and software publishers
would do such a thing? Why use the word "power"
so often? Why focus so much on "features"? (Did
you find a large number of programming tools
touting the "reliability" of the software you will
create with them? Why not?)
Of course, the answer is obvious, and I will
sum up my point with the two most important
"Programmers Crave Power"
"Features Grab Coders"
(Two marketing USPs! Isn't this fun?) Programmers
crave power. They love tools that make them feel
powerful. They will buy products that promise
them an extra level of power. They constantly
boast of the power of the systems they build and
the tools they use. They are attracted to products
that include the word "Power" in their name (make
a list of these; it's a powerful marketing lesson).
Does any programmer you know describe himself as a
"power user"? In my opinion, programmers love power
even more than they love money.
Features grab coders. Features are cool. Features
are fun. More features means more fun. And of
course, more features means more power. When the
average programmer learns about a new feature, he
can hardly wait to use it. Programmers almost
literally drool over features. To most software
developers, "full-featured" is as desirable as
(BTW, be sure to include yourself in the list of
people that love features and power -- if you are
a developer, you can hardly be exempt from these
fundamental laws of coder psychology. In some
secret places in your own mind you may discover
that you love Ada more for these reasons than
the idea that "it's so reliable!".)
So, my USP in its various incarnations emphasizes
power and features. Powerful features. And our
beloved language is indeed very powerful and
Well, where am I going with all of this? First,
I am here to say that we need a venue where we can
get Ada in front of the SW community in a positive
way, and in that venue we need to start emphasizing
our USP. Remember to treat it as a "given": "Of
course, if it's real-time OO you want, Ada is the
way to go. It's very powerful in that domain."
So, where is this venue? Where is the stump from
which to make this speech?
Of course there are plenty of venues to make our
case. Ask Richard Reihle. But I have another
How about a book in the Object Technology Series?
"Real-Time Object Oriented Development in Ada 95."
(Somone should twist Grady's arm to write the
preface.) Make sure UML is covered in the book.
Every copy of every book in the series has a list
of the other books in the series.
I am writing this note to see if anyone is planning
to write a book anytime soon on real-time OO in Ada.
If you are, get it to Addison Wesley; they are begging
for books in the OO field -- they can't print them fast
enough. With the names of the Big Three on the each
cover, the books are selling like hotcakes. And this
spring and summer there will be a *lot* of interest
in the object technology series, OO, and UML when
Booch, et. al. publish their very own UML guides.
See this page of guidelines for AW book writers:
Note that this is a *special page* for people
writing UML and Object Technology Series books.
It's *that* important to Addison Wesley. And they
are already respectable Ada publishers. And we
probably *can* get Grady to write the preface!
I know real time & OO, but I'm not familiar with
UML just yet (getting there). So, I wouldn't mind
collaborating with someone if it is necessary for
me to get involved in the production of such a book.
But it's got to be done fast because of publisher
lead times, if we want to get it out before the
end of the year.
Let me know what you think.
[log in to unmask]