Software Project Management

Linux & Red Hat

SEO Writing

Written for Networking, the newspaper of the Western Massachusetts Software Association (1998) with highly technical readers.
© 1998, 1999, Ray Wilson

Ed Mangiaratti On Successful
Software Management
by Ray Wilson

As Ed Mangiaratti describes it, management of a software development project is far from what might be expected by someone drawn to the technological world by the tangibility of things which can be measured, drawn, or encoded. Likewise, successful management is not merely a matter of who is defining "successful", but more a matter of how well the project manager integrates at least three differing -- perhaps even competing -- perspectives on success. He illustrates his point with a graphic he calls "The Triad" -- a triangle with the manager at its geometric center and the three corners occupied by (1) the customer, (2) software company management, and (3) the project team.

Red Hat's Lisa Sullivan on Linux
by Ray Wilson

Red coats in 1776; red flags through much of the 1900s; and in the latter 1990s -- a revolution where solitary red is finally on the side of the good guys. Red Hat Software's Lisa Sullivan, keynote speaker at the 1999 WMSA Annual Meeting outlined the emerging leadership role in the Linux-centered software marketing revolution of the Research Triangle Park, North Carolina company. It is a revolution within a revolution. It began with an upstart open source operating system as an in-your-face alternative to proprietary commercial systems. Then, Linux appeal quickly spread beyond the early high-tech rebels to those who needed to hire -- i.e., PAY for -- technical assistance and other services to help them keep pace (Linux -- unlike commercial operating systems, doesn't bring computers and operating systems crashing when an application fails, isn't a memory hog, and does allow tailoring and adaptation of it's code to the user's particular needs). Thus, the anti-commercial open source revolution created its own commercial market.

What Sullivan calls "service in a box" is warranted Red Hat Linux software, complete with installation and operating manuals and help-desk assistance. What the package does not contain are restrictions on the use of the non-proprietary code -- no prohibitions against copying, modifying or adapting into other software. Red Hat's commercial interest is protected not by code-use restrictions, but only that copied programs do not have the Red Hat quality guarantee, the manuals, or help desk assistance.

OF BOTS & BRAINS: Writing for Search Engine Optimization (SEO) versus Reader Action Optimization (RAO)
by Ray Wilson
           © Copyright 2009 by Ray Wilson

A fishing lure may attract thousands of fish, but if they are not led to think it is food, the lure isn't worth its purchase. An SEO Writer knows that search engine optimization (SEO) is half the job; reader action optimization (RAO) is not only the other half, but the full measure of the true value of the whole job. Search engines are attracted by keywords which have been specified by the searcher, one of the reasons that the phrases "search engine," "search engine writer," and "SEO writer" are repeated in this article, and that my delightfully clever and fully original RAO concept is mentioned less often. You, the reader, are smart and need little repetition; the search engine robot is an idiot (including those of so-called "decision engines"). Key word repetition gets the bot's attention, while creativity, relevance, and message clarity get and keep a reader's attention.

You can figure it out (the advantage for both of us of your being smart), so I won't beat the RAO concept or the fishing-lure metaphor to death with repetition. However, please tolerate the redundant use of

SEO, search engine, search engine optimization, search engine writer, search engine robot, bot, seo writer, seo content writer, seo writing ... etc...
which were needed to satisfy the idiot that brought you here. Now that the bot has been lured, it is time for your smart reader's brain to decide whether to taste the food.

Long before the Internet, I wrote a newspaper ad to sell my own house. Real estate agents looking to list the house called and scoffed at my ad. They assured me it was too long and detailed, would attract very few buyers, and that an ad written by professionals (them) would attract far more buyers. I agreed, but said I had only one house and needed only one buyer.

True to the agents' predictions, the ad produced only four calls, but three times the number of buyers needed. With one purchase agreement and two back-up purchase offers, all full price, time on the market was only two days. The lengthy but clear and accurate itemization of features reinforced the interest of those who would offer, and actively disinterested those who would be wasting their time and mine.

In subsequent years, I wrote house ads for real estate agencies -- this time structuring each single house ad as bait for multiple buyers to whom agents could pitch the many houses at their disposal. (In even later years, I wrote one book and many articles about the practices of the real estate industry).

Again, you get it. You also know that no search engine grasps the quality of the logic implied in the story I just told. Search engine optimization begins and ends with body count; but an SEO writer has a bigger job, appealing to the brains that come in those bodies. Optimizing the search engines for the benefit of a particular site requires including in the real text, key words that satisfy the automated appetites of brainless search robots. A too-literal perception of "search engine optimization" or even "SEO" may cause a writer to overlook the

Return to Top

Mangiaratti On Successful Software Management -- continued

In his presentation at a WMSA Workshop on "Successful Software Projects" (Springfield, October 22), the Triad proved to be a useful device in maintaining common focus in a diverse audience. There were twenty five participants representing seventeen software firms, organizational levels from programmer to company president, and two planetary hemispheres. Three visitors from Russia not only broadened the audience profile, but highlighted both the global significance of the subject and the shrinking world caused in part by the very technology of this industry.

Conventional wisdom holds that a job completed on time and within budget is successful. Mangiaratti points out that a job completed according to contract specifications on time and within budget may still fail to retain either the customer or the valuable project staff, making it far less than a success for either the software firm or its management.

He notes that the word "software" in itself implies that the elements involved in its development are less tangible than hardware or other hard goods produced by the industries in which conventional production management practices evolved Yet, it is clearly a product that is developed to a customer's specifications, rather than a customer service. However, those specifications cannot be reduced to blueprints and bills of materials susceptible to the exact quantifiable measures of in-process material-quality inspection. Specifications may indeed be more than soft, actually fluid, requiring words like "granularity" to capture the nature of component tasks. The good news is that there are words and concepts and tools which can be applied to give ongoing tangibility and process control to the software project manager.

"Granularity" is a good example. Using a graphic, Mangiaratti illustrates the overall software development process flowing from a cloud-like representation of the customer's "requirements" to arrive ultimately at the solid box-like representation of the working "code" that is the final product. The granularity of a cloud -- the size and spacing of its component molecules -- determines it's tangibility in our sight. The granularity of a substance determines how it is contained and handled.

As a concept of software development management the molecules of the requirements "cloud" are its component tasks. The size and spacing of tasks (i.e., granularity) is put into a tangible measure -- manhours of work. In practical application, Mangiaratti suggests the ideal granularity in a project schedule fits all tasks within a maximum of 80 man-hours of work. Tasks larger than that should be broken up. Tasks smaller than four hours should be grouped; keeping them as they are on the project manager's schedule is one practical definition of "micro-management".

Mangiaratti's approach is neither to pretend tangibility or clarity where it doesn't (yet) exist nor to dismiss the intangible as irrelevant. His approach is to develop practical management tools and processes for containing the real -- though precision-defying -- elements of the real-world environment of software development and application. The key, he says, is neither software nor hardware, but peopleware. Unlike the quality of a manufactured part intended for static fit in a mechanical assembly, software quality is ultimately determined by its fit into the visions, thought processes, predispositions, interests, and even moods of people who are endlessly changing and unavoidably imperfect. This is all on top of the human resource problems inherent in any production process. The manager needed to take all that on is not one who looks for a set of unchanging detailed specifications at the beginning of a project and then sees the job as getting the thing built on time and within budget.

A good manager is one who draws his own direction not from the details of budget or schedule, but from a vision of what the project is all about, derived with the customer at its outset. Appropriate budget and schedules are determined by the vision and subordinate to it; these are tools -- maps --for the manager as he steers along the journey to the vision's destination. It is the manager, and not the schedule, doing the steering, anticipating inevitable changes, continuously taking readings on where the project is, and what lies before it.

Always conscious of the Triad, the manager knows he is not alone in the project, that he must keep all three elements (customer, team, and firm management) apprised of where things stand, focused on the vision, adjusting to changes, and united in their expectations. In all this, the manager must constantly be managing "feature creep" (growth in the number of program features, inherent in any software development program) by restricting the growth or adjusting schedule and budget to accommodate it.

From the early-on capturing of the vision, through establishing requirements, project life-cycle, schedules, and budgets, Mangiaratti's presentation and 38-page participant handout detailed approaches, techniques, and tools for the Triad-conscious software project manager.

Red Hat's Lisa Sullivan on Linux -- continued

Linux accounted for 17.2 percent of all 1998 server operating system shipments -- with Unix at 17.4% and MS Windows NT at 36 percent! That represented 212 percent growth over the year before, making Linux the fastest-growing server environment in 1998. Catching the edge of the Linux wave, Red Hat is widely recognized as the world's leading Linux vendor and now operating with formal alliances with IBM, Compaq, Novell, Oracle, Intel, Netscape, Dell, Computer Associates International, and Hewlett Packard (the first six with equity positions in this privately held corporation).

Whether software product specifications originate with customers or with a software firm interpreting customer need, the traditional market model draws a clear line between the roles of provider (software proprietor) and customer (paying consumer). Someone owns the stuff, and others pay to use it. Owners closely guard trade secrets and rigorously enforce their proprietary rights. Purchasers are typically forced to conform their operations and methods within the limits of the commercial software. Sometimes they'll develop their own -- burying the code in their own vaults and, if they market the executable software, it's with the same strings and price tags attached. More often than not, internally developing software to supplement purchased packages is reinventing a wheel already turning within the walls of some other user firm for whom the commercial product fell short.

Open source development did not -- as expected -- lead to the balkanization of the Unix market, but in fact movement toward homogeneity. The traditional market assumption was that the few custodians of commercial sector decision-making served as a check against chaos inevitable with free-ranging development in the hands of the consumer mob. As it turned out, too many hands did not spoil the soup after all. In the first place, quantity did not preclude quality as the technologically astute shared ideas and development in unanticipated harmony.

Secondly, where those outside the expert core needed technical assistance to use the non-proprietary code, the assistance itself could be provided commercially. That in turn added a quality filter in the code-distribution process, inserting software quality assurance into a production system where ongoing product is copied rather than built. Quality achieved is quality transmitted.

A multinational noncommercial software production system emerged under its own energy, built and shaped not by interpreters of consumer need, but by the consumers themselves. The consumers not only provide the software product specifications or applications design, but the software product itself. The product's function and design are inherently in full conformance with consumer need, the fundamental prerequisite of consumer quality. The development "staff" is enormous, spreading across the consumer population and not limited to a software development firm's payroll capability. It is there simply because the nonproprietary nature of the code allows it to be there -- no restrictions on modification and adaptation. That provides not only an explosion of useful applications but almost as many test sites -- so the quality-checking program begins with the already best-working applications.

Red Hat -- or any Linux software firm -- needs heavy budget outlays for neither software development, nor market promotion. The product task is not development, but quality assurance on the flood of developments; and as just noted, even there the consuming population takes on much of the role and expense.

The market task is not to promote interest in the software, but to keep up with interest advancing faster in the user population than any company campaign could ever promote. New customers for the Red Hat package may in fact already be users of the nonproprietary code -- not usually the case in the traditional market model. The challenge is not to spread the message of Linux, but to track where the message has already gone and then let people know that Linux is in the Red Hat box.

Of Bots and Brains -- continued

critical need that these words first be "key ingredients" in recipes irresistable to the intellectual appetites of site visitors. Even the correct ingredients in wrong amounts and improperly combined will mean a culinary disaster, producing the aforementioned fishing lure that attracts but gets no bites. Visitors do what search engines do not do: they think; they decide whether or not to go on to the next line of the site message, let alone to the point of the ultimately intended action.

Ironically, to be a truly effective SEO writer, it is wisest to first design the site and write the text with no consideration whatsoever for search engine optimization. Whatever the sought subject material, searchers and search engines seek real substance, not stuff artificially molded to conform to the search mechanics. The "key words" entered by seekers into search engines are not words they want to encourage websites to use, nor even to find in websites, but rather the words they hope will be clues to the presence of the real substance they want and need. They are the words the seekers guess the websites would naturally use in straightforward presentation of the intended subject matter.

A new visitor does not arrive at a website with a keyword check list or score sheet, but rather with a collection of incomplete notions (to be completed by what they seek) which will help them spot clues to information relevant to their specific personal need. Expecting variety, complexity, and junk (non relevant elements), they will be relieved, pleased, and encouraged to be patient in their relevance-seeking by clarity, ease of discovery, and non-distracting creativity. Every newspaper reader and website visitor scans the broad page, homes in on specific areas, and proceeds from one sentence to the next intuitively asking one and only one question:

What's in it for me?

So, write the site text that way. Welcome the visitor as an individual with a "me" and not an "us" self-conception. The herd approach works for the search engines, but is distracting and even destructive to rapport with consumers addressing personal need. Put yourself in the individual visitor's shoes. Write about

the site's subject matter from the perspective of its substance and its utility for thinking consumers, i.e., how it will answer the "What's in it for me" question, and not as some thread for stringing together the keywords to lure a brainless bot.

The herd approach works for a real estate agency's newspaper ads, but the agent who could not distinguish between that and my needs as an individual home seller would never land me as a client. He did not put himself in my shoes. I, on the other hand, as seller, put myself in the shoes of potential buyers. The detailed ad I wrote answered the "What's in it for me" question so fully for the three buyers that they came ready to buy. The successful buyer, who made the first offer, later joked that his advantage over his two competitors was that he apparently was the fastest reader. The businessman, the real estate agent, took the "What's in it for me?" approach for himself, but saw all consumers as a herd following a single mindset, the collective "us." He failed to put himself in the consumers' shoes.

Truly putting one's self in a website visitor's shoes makes it unavoidably evident that those shoes are in the website and not anywhere in the search process! They have stepped beyond the search function and past any and all relevance of search engines or any need on the visitor's part for "keywords." Certainly, search engine optimization does have to be ensured, and that will require the presence of the keywords; but SEO and the sacrosanct keywords are still not in any way necessary elements of the strategy to keep the visitor on site and guide him/her to the ultimately desired action.

Search engine optimization means providing clues for searchers to find and visit sites most meaningful to their purposes. These clues -- call them keywords -- provide keys to the content of the sites. It logically follows that the keys are derived from the sites which, in turn, have been developed purely to suit the searchers' needs, and not to suit the keys. There is a science to deriving the chronological order from the logical order; but it is not rocket science.