High-Tech Industry Consolidation Continues

SAN FRANCISCO, APRIL 1, 2018 – Tsunami waves of consolidation continue to break against the software industry, as MicroCiscoYahooOraclesoft announced a US$2.4 trillion takeover of IBMhpSAPemc. Meanwhile, Apple Telephone & Telegraph agreed to merge with GoogledellSUNokia in a deal worth $3.7 trillion.

“This is a fantastic day for consumers everywhere,” shouted Steve Ballmer, chairman of MicroCiscoYahooOraclesoft. “Ever since the last anti-trust restrictions were lifted from our company yesterday, we began looking for new ways to innovate and bring more choice to customers. This acquisition goes a long way toward bringing us closer to Bill’s dream of ‘information at your fingertips across the road ahead at the speed of thought,’ or as I like to say it, IAYFATRA@TSOT.”

While critics swiftly charged that the MicroCiscoYahooOraclesoft move is all about increasing its share of Internet-based advertising, comments from a pay-for-praise analyst hint at a bigger target: mainframe consolidation and positioning Big Iron as next-generation smart clients. Noting that current mainframes rival mobile phones in size, the ability to combine the technologies in new, exciting ways creates powerful synergies, said Ivan A. Suckup, director of The Suckup Group.

“Imagine a pocket-sized IBM mainframe running Microsoft operating systems and Oracle databases, combining HP’s consumer marketing prowess with SAP’s business back-end integration, EMC’s storage technology, Cisco’s connectivity and Yahoo’s leading-edge ad-delivery platform,” Suckup said. “If they can only solve the cooling problem, and get more than three milliseconds of battery life from the fuel cell, this will truly be the killer platform of the future.”

The Suckup Group recently placed MicroCiscoYahooOraclesoft into its Golden Sector of Industry Innovation & Leadership™. “They’re our best client,” gushed Suckup, “and they subscribe to every one of our overpriced services. However, that in no way is related to our upgrading our honest, impartial recommendation to ‘Buy all their stock that you can afford, even if you have to clean out your kid’s college fund and take out another mortgage on your house.’ ”

In related news: Two months after MicroCiscoYahooOraclesoft completed its controversial acquisition of Red Hat, questions linger about the accidental loss of all of Red Hat’s source code, revealed only last week. “Whoops,” said Darl McBride, director of open-source strategy at MicroCiscoYahooOraclesoft. “Don’t know how that happened. Pity all the backup tapes were destroyed, too.”

McBride pointed out that MicroCiscoYahooOraclesoft’s Server Customer Open Source program, or SCOsource, will offer Red Hat Enterprise Linux users discounts to license Microsoft’s Windows Server 2016 through May 15. After that, the company will remotely disable all Red Hat Linux installations. “We suggest you read the fine print,” McBride suggested, “and give up Linux before it’s too late.”

“We agree with that,” agreed The Suckup Group’s Suckup.

AT&T Goes the Distance

On a roll since its 2015-2017 acquisitions of Sony, The New York Times, Starbucks, Disney and Wind River, Apple Telephone & Telegraph surprised Wall Street by agreeing to be purchased by software giant GoogledellSUNokia for $3.7 trillion.

“The combination of our companies will be an unstoppable force for doing no evil,” said Eric Schmidt, chairman of GoogledellSUNokia. “We already have the world’s largest server farms, the most mature direct-sales model, the most online advertising, the best Android-powered handsets, the best embedded operating system, and the most complete logs about everything you do on the Internet. Plus, with gJava, you can write everything once, and run it everywhere. With AT&T’s resources, we’ll have even more amazingly cool handsets, the hottest personal computers, the most reliable wireless network and the most compelling content for you and your family, at home and at work. GoogledellSUNokia truly is the happiest place on Earth.”

Steve Jobs, chairman of AT&T, will remain on as honorary spokesmodel and chief platform evangelist for the combined company, to be named GoogledellSUNokiAT&T. During Macworld 2018, webcast from San Francisco’s Moscone Center last month, the normally recalcitrant Jobs had hinted that something big was brewing.

After unveiling the iPod notouch — the first music player with direct audio/video brain-feed capabilities — Jobs said “Something big is brewing.” At the time, analysts believed he was promoting the new AT&T Friends and Family Plan, which gives you 600 anytime iTunes movie rentals along with unlimited TV episode downloads nights and weekends, if you sign up for a two-year WiMax contract. For a limited time, each new subscriber also receives a Duetto Visa card, a Magic Kingdom three-day pass and home download of the Sunday Times. Severe penalties apply for early contract termination.

Perhaps Jobs had more than Mickey Mocha in mind, said Suckup of The Suckup Group, which recently placed both AT&T and GoogledellSUNokia into its Golden Sector of Industry Innovation & Leadership™. “When Jobs smiled after asking ‘Just one more thing: Don’t you love Google?’ at the end of his keynote, clearly something big was brewing,” Suckup said.

While GoogledellSUNokia’s Schmidt declined to discuss specific plans until the merger is rubber-stamped by the U.S. Federal Trade Commission and the European Union, he did say, “Someday soon, every phone will be an iPhone,” and hinted that one could expect to see Dell PCs, Sun servers and Nokia handsets appearing for sale in every iBucks location.

“Turning every Apple retail store into a Starbucks coffee shop, and every neighborhood Starbucks into an Apple store, was inspired,” said Suckup. “Getting a fresh iced latte from the iBucks Genius Barista while you download some tunes, upgrade your RAM, do your homework and work through some technical issues with GarageBand — that’s the ultimate in 21st-century convenience.”

Suckup continued, “If that level of service is extended to supporting Windows Panorama Edition 2017, that could give MicroCiscoYahooOraclesoft the much-needed opportunity to reclaim some market share from the iMac. Hey, that’s another reason to buy some stock.”

Stay Tuned

The three remaining high-tech companies that have not yet been acquired or merged — Novell, Borland and Salesforce.com — are reportedly thinking about it.

Retired software engineer I.B. Phoolen invented Web services, Scrum, penicillin, recursion and, most recently, ALGOL 68. Read his blog at ibphoolen.blogspot.com.

Code Blue!

How do you rank the severity of application defects? Some test teams assign severity/priority scores, but that’s arbitrary, and doesn’t reflect the real-world impact of bugs. How can you really assess the importance of something that’s rated “medium” for severity but “low” for priority?

More practical dev teams use expressions to communicate, through the defect database, change-management system, email or sticky notes, how important a defect is to the team. “This one’s a show stopper,” you might say. Or “If you can fix this before the next release, that would be great,” you might comment. Or “Who cares about a teeny-weeny typo?” you might write. Or “Sheesh, this one’s definitely gonna get us sued,” you might opine. Isn’t that better than “high,” “medium” and “low”?

However creative that approach is, the expression-based defect ranking system does leave things to interpretation. One person’s “it’s a teeny-weeny typo” is someone else’s “clean out your desk and be out of here before the cops come,” especially if that typo was in your CEO’s name, or in one of the digits in your upcoming Securities and Exchange Commission filing.

Similarly: While your CFO might issue a scathing four-letter expletive in both cases, which is worse: a bug that applies the wrong algorithms to stock-options pricing, or a bug that applies the wrong algorithms to a credit-scoring system? Selecting the “we’re totally screwed” button in the issue-defect system’s severity/priority may not accurately communicate the CFO’s displeasure.

The right solution, as I’m sure you will agree, is to hand these sorts of things to the U.S. Government. No, not the actually grading of your software’s bugs, you silly person: that’s your job, and you can’t get out of it. No, we should take a leaf from how our benevolent authorities have responded to airport security. You don’t hear the public address system at the airport say, “We’re at terror level we’re-going-to-die.” That would cause panic. Worse, it is ambiguous, since it doesn’t communicate who is going to die, when this will take place, and if you have time to buy a $5 Bloody Mary from a flight attendant beforehand.

Instead, as I’m sure you know, the monotone announcement on the P.A. system says something like, “Attention: We are at Homeland Security Threat Condition Orange.” This is more practical, and more useful, because it’s from the government and they know best.

That, my friends, is the model that software test/QA professionals should use when communicating with end users and other stakeholders about bugs, when assessing the bugs for ourselves, and when classifying said bugs in the defect database.

“Hey, Bob, looks like we’ve got a nice, juicy Yellow here,” you might hear shouted over a cubicle. “Are you sure it’s not Orange? We’re only fixing Oranges before the next beta,” you might shout back. And so-on and so-on.

The U.S. Government’s colorful Homeland Security Advisory System (HSAS) was enacted in March 2002. Forget about those silly “low,” “medium” and “high” scales that you see so often in defect-management systems: the HSAS goes much farther with five levels:

Red = Severe: Severe Risk of Terrorist Attacks
Orange = High: High Risk of Terrorist Attacks
Yellow = Elevated: Significant Risk of Terrorist Attacks
Blue = Guarded: General Risk of Terrorist Attacks
Green = Low: Low Risk of Terrorist Attacks

Brilliant, brilliant, I can hear you saying. Go ahead, say it again. Brilliant. Thank you. You can see instantly why this is appropriate for software development and test/QA. I would humbly propose the following scale for categorizing software threats. Actually, I would like to propose two scales, which I call the Software Defect Advisory System (SDAS). The first SDAS scale is the one that you tell your end users, managers and other stakeholders about, and which they use for reporting bugs to your test team:

Red = Severe: This Must Be Fixed Immediately
Orange = High: This Should Be Fixed Soon
Yellow = Elevated: Fix This When You Can
Blue = Guarded: Fix This Sometime, Maybe
Green = Low: Just Thought You Should Know

The other SDAS scale, of course, is more important, because it’s the one you use to categorize actionable issues in the defect database:

Red = Severe: This Will Get You Fired
Orange = High: This Probably Will Get You Fired
Yellow = Elevated: This Might Get You Fired
Blue = Guarded: This Probably Won’t Get You Fired
Green = Low: This Is Just Stupid

Follow this system, my friend, and you’ll never get scolded for misspelling the CEO’s name, or miscalculating stock option prices, ever ever again.

Bite Vulnerabilities Before They Bite You

April 1, 2007 — Firewalls are great if you’re worried about barbarians attacking your front gate. Intrusion detection systems are fine, if your goal is to see if unauthorized traffic is on your LAN; intrusion prevention systems work in conjunction with your firewall to block that unauthorized traffic.

Bah. Firewalls, IDS and IPS systems, as well as anti-virus solutions, spam filters, worm detectors — they’re all worthless, absolutely worthless, when it comes to attacking the real causes of software security failures. So, too, are checks against buffer overflows, cross-site scripting and SQL injection. While those vulnerabilities can trip up an unwary programmer, they’re easy to catch. Just about any static or dynamic code analyzer can find those problems. The real challenge is how to handle the most significant software security challenge of our time.

Puppies.

Yes, my fellow software architects, developers and test/QA professionals, the biggest threat to our software infrastructure, and the integrity of our data, is puppies. They look so cute, don’t they, with their lolling pink tongues, soft waggly ears and short little legs. They roll and play and want to be cuddled. But don’t be fooled. Puppies, those innocent little puppies, are placing your enterprise software in deadly peril… and your CEO, if the puppies start messing with your Sarbanes-Oxley systems. He’ll be going down the river… and you’ll be down there with him, if you don’t take action now.

Where did this insidious threat come from? It’s hard to know. Perhaps the first puppies merely wanted some fun; they wanted to show off in front of their litter mates. Nobody picks on the runt, you see, if he can erase breeding records with the click of a mouse. But then things got worse. Government agencies and their espionage programs. The military. Commercial interests. Terrorists and rogue states. They learned how to use puppies to bypass virtual private networks, routers, firewalls. How in the face of a determined puppy, even 256-bit AES encryption is about as effective as an old, battered squeaky toy. Buffer overflow exploits? Ha. Puppies sneer at your pathetic algorithms; you might as well not bother.

The puppy threat is years ahead of our technology. Check your Tivoli, your OpenView, your Unicenter TNG, even Microsoft’s MOM. Do any of them detect puppies? Not the latest versions, and not the current betas. Do they have any facilities for neutralizing the puppy threat, once detected? Not a chance. Microsoft Research, the T.J. Watson Laboratories — they’re hopeless. The experts at the Carnegie Mellon Computer Emergency Response Team are asleep at the switch. The Computer Security Institute doesn’t have a clue. Even the U.S. National Security Agency and Department of Homeland Security lack contingency plans to protect our vital enterprise software from the puppy scourge.

You should pool your resources with the rest of the IT team. Gather up your LAN and WAN managers, end-user support teams, data center managers, test teams. Heck, even bring the code librarian. Get the CIO or CTO to bring the team together — there’s no time to lose! Check out the RSA Conference or the Software Security Summit, neither of which (surprise) have classes or tutorials on puppy threat management. Ask, no, demand that they address this issue immediately We need classes. We need patches. We need an action plan!

Puppies. This time, the rolled-up newspaper is not going to be enough. Let’s get to work, people, before it’s too late.

Quality Ought To Hurt

It’s been seven years since the public cared about software quality. It’s been seven years since CEOs and CFOs, Joe Six-Pack and soccer moms, presidents and kings gave a moment’s thought to bugs and flaws.

Seven years ago, remember, companies large and small were obsessed with the Year 2000 bug. Congress and the United Nations held hearings about it. The New York Times, Washington Post and Bangor Daily News ran stories about it. The Frankfurter Allgemeine, China People’s Daily, O Estado de S.Paula, and Vancouver Business Journal did, too.

Within our industry, thousands of technical articles discussed best practices for swatting the Y2K bug. IBM and PriceWaterhouseCoopersLybrandEtc. mobilized armies of pinstriped consultants. Consumers panicked. Governments panicked. Companies, frightened about lawsuits, paid beaucoup bucks to recruit old COBOL and RPG programmers.

Why was Y2K such a big deal? Because the consequences were made tangible.

Riders would get stuck in elevators, we were told. Weapons systems would shut down. Airplanes would crash. People would die. Worse, businesses would get sued. Or so everyone thought — and this scared them into making a huge, if one-time, investment in software quality.

Y2K came and went, and airplanes didn’t crash. Whether that’s because the bugs were bogus, or because those armies of consultants actually found and fixed flaws, I don’t know. But the truth remains: Governments, the media and consumers cared about software quality because the consequences were made real in terms of lives and dollars.

Software quality can’t be an abstract concept. Think about engineering, where there’s a tremendous commitment to quality: If a bridge isn’t architected properly, it falls down and people die. If an anti-lock brake system has bugs, cars crash and people die. A software flaw in the first Ariane 5 rocket, launched in 1996, caused the loss of a $500 million satellite.

Stories like those get people’s attention, if just for a little while.

The U.S. government understands that the only way to get companies to do things is to enact real and severe penalties. You’ve probably heard the capsule summary of Sarbanes-Oxley: “Do it right or the CEO goes to jail.” The threat of going to jail gets people’s attention, too, if just for a little while. That’s why we’re going to need some SarbOx perp walks to keep this issue in the public eye.

So, what does I.B. Phoolen recommend? Among other things, more visibility for software quality. Lots more visibility. Think about how the U.S. National Transportation Safety Board maintains an extensive database of aircraft accidents and near-accidents. This database, and the NTSB incident investigations, not only catch design flaws and defective aviation hardware/software, but also point to where aircraft operators, airports and maintenance crews don’t follow proscribed operating procedures.

“Best practices,” you know, ain’t optional in the aerospace industry. Why are they in the software industry? What if companies were forced to divulge all software flaws publicly to a National Software Safety Board, and submit to external investigations? You can bet they’d pay a lot more attention to quality. If that NSSB could mandate software recalls, the way automobile and aircraft manufacturers can be forced to repair — at their own cost — product defects, wouldn’t we all be better off? What if Microsoft had to file a government incident report every time someone found a Windows bug?

Transparency is a good start, but I.B. says that it’s not enough: Bugs ought to hurt, not just in the company’s cost to fix the bug, but in significant damages and penalties. I’m talking big fines. Didn’t check that buffer? $1,000 per buffer per user. Web site’s vulnerable to SQL injection? $50,000 per input field. Shipped products with known flaws? Didn’t catch an exception? Failed to certify the printer driver? $10,000 for each end user, thank you very much. Ka-ching!

Penalties like those get people’s attention, and not just for a little while.

Today, software quality for both enterprise and commercial software is left almost entirely up to the software maker to decide and address. Customers’ legal rights are often entirely abrogated by shrink-wrap software licenses and the fine print in Web site legal statements. If a bug in a commercial operating system or application costs you time and money, wipes out your data or shuts down your business — tough luck, kiddo, trying to recover anything in court. (With open-source software, at least you can try to spot flaws and fix them yourself.)

We insist on transparency and penalties when it comes to cars, aerospace and civil engineering. We should demand that for software, too. The only way to force ISVs — and those allocating resources to enterprise software development and QA teams — to be serious about quality is through bad publicity, nasty fines and criminal penalties for violations. Didn’t check your return value to detect a null pointer? Buddy, tell it to the judge, tell it to the judge.

The Case For Dysfunctional Testing

You testers, QA specialists, performance jockeys, you poor ISO 9001 efficiency experts—you’ve got it wrong. All wrong.

All this talk about functional testing. It’s a load of hooey, and you know it.

What’s the point of functional testing? You don’t want to know if your code functions.

Your designers and architects are smart, they’ve listened to the end user and created some killer UML diagrams. The UI requirements are solid. Your programmers are top of the heap. Of course it functions. It’s just plain stupid to waste time and money, and mess up your delivery schedule, with so-called functional testing.

What you want to perform is dysfunctional testing. You don’t want to know what works in your n-tier application. You want to know what doesn’t work. As that funny-looking yellow guy on The Simpsons would say, “D’oh!” And Homer ought to know, he’s a nuclear engineer. (He kinda looks like my brother-in-law Fred, only better looking.)

I know that this blinding insight may come as a surprise. But it’s not your fault. Nobody talks about dysfunctional testing. Googling for dysfunctional testing brought up 11 results. Eleven! By contrast, Googling the phrase functional testing led to 253,000 results. That’s just a crime.

It’s clear that everyone has their priorities wrong.

What do I mean by dysfunctional testing? Finding out where the code breaks. It’s just that simple. Really. Stop looking to see what works, and instead see what doesn’t work. Imagine that your million-line client/server system is 98 percent bug-free.

When you’re doing functional testing, you’re testing 100 percent of the application. That could take hours during the nightly test run. Stupid! If you just test the two percent that doesn’t work, you’ve cut the test time down to minutes.

The advantages of dysfunctional testing are all the more compelling when your organization gets higher in the quality scale. Say you’re working you’re way up the Capability Maturity Model ladder, stuck between rungs 2 and 3, and your million lines of code is 99.8 percent functional. Imagine the bottom-line benefits of testing only the 0.2 percent of the code that’s dysfunctional—that’s only 2,000 lines of code.

How hard can it be to test 2,000 lines of code, remediate the dysfunctions, and then refactor like mad to improve the runtime performance? Not hard at all. You’ll be at Six Sigma in no time, guaranteed. Take that, W. Edwards Deming!

Before you nominate me for the Malcolm Baldrige National Quality Award, let’s talk about how to actually achieve dysfunctional testing within your enterprise test/QA organizations. Believe it or not, it’s not as simple as you might think.

A key component of dysfunctional testing is something that I call “root cause analysis” — that’s a term that I’ve just made up. What you need to do is find the root cause of your software defects. In most cases, it’s easy to determine the cause: bugs. Yes, that’s it. Sometimes it might be a design flaw, but I’d put serious money on it being bugs.

There are different ways you can get rid of bugs. One way is to use a debugger. “Yes, I just got de bugger,” is something that I say a lot, ha ha! (You’ve got to have a good sense of humor if you’re working on cleaning up 2,000 lines of code before your afternoon jog.) Another way is to do a code walk through. But that can take a long time, and if you’re not good at dysfunctional testing, you might look at the wrong 2,000 lines.

That’s definitely not recommended by the President’s Council on Physical Fitness and Sports. A better approach is to employ a number of techniques, such as overload testing — that is, you whack the code so hard that it shatters. Forensic analysis will show you where it broke.

(Don’t confuse overload testing with namby-pamby load testing, where you gradually increase the transaction load on an application server while monitoring its performance on a curve. Like, who has time for that?)

Another approach is to adopt seVere Programming, my agile methodology that applies the dysfunctional testing metaphor at the daily work level. In VP, developers work in teams of three: one writes the code, one tries to breaks the code, and the third programmer smacks the first programmer with a ruler whenever a defect is found. It’s foolproof! (If the first developer runs away, this is called the Scram methodology.)

In conclusion: Functional testing is stupid. Dysfunctional testing is smart.

The Nobel Foundation knows where to find me.

SCO Slaps Itself With Lawsuit

NEW BUSINESS MODEL SHOULD RESULT IN GAINS, LOSSES, CONFUSION

April 1, 2005 – The SCO Group is preparing to reverse its flagging fortunes by launching a Unix infringement lawsuit against itself, according to documents obtained by this reporter.

Today’s SCO Group consists of the original Caldera Group, the Unix assets purchased from Novell, and the SCO name bought from The Santa Cruz Operation. Prior to launching its lawsuits against the Linux community in 2003 — hitting companies such as AutoZone, DaimlerChrysler and IBM — Caldera was a major supporter of Linux. Indeed, in 2002 it formed a consortium with Conectiva, SuSE and TurboLinux to enhance and promote the open-source operating system.

According to confidential documents, Caldera may have inadvertently shared intellectual property it gained after the purchase of Unix with its own open-source developers. If true, that would be a violation of its own Unix license, and as such, would expose the company to legal charges and potentially huge damages.

“It’s possible,” pondered Ficus McMushroom, senior legal analyst with Guernsey, Jersey, Sark & Alderney. “If SCO’s Unix staff exchanged any information with their Linux staff, whether sitting at a conference table, on an internal bulletin board, or even while swilling beers at a bar, Unix license and intellectual property violations may have occurred.”

HAND OVER THE STICKYS

Is there a smoking gun? It’s impossible to know until the lawsuit strikes, but according to the secret report, the company is prepared to subpoena extensive documents, including e-mails, voice memos and rainbow-colored Super Sticky Post-It Notes written by SCO honcho Darl McBride.

“We’re clearly on unsteady legal ground,” observed McMushroom. “If the charges are true, the damages might run into the tens or even hundreds of millions of dollars.” Collecting those fees would significantly boost SCO’s revenue for 2005, the analyst noted, and could lead to a rise in stock price or dividend payments, as well as yet another round of restated financials.

The revenue from the suit would be offset by legal fees, and may be potentially covered by SCO’s liability insurance, McMushroom believes. Any additional costs would most likely be treated as an extraordinary charge against earnings.

But in any case, he expects SCO to come out ahead.

But will the suit see the courtroom? “Frankly, I don’t think so,” said McMushroom. “I expect SCO to settle before depositions are taken. But on the other hand, if they go through with the suit, they may set a legal precedent for the Unix lawsuits.”

SCO would not return calls about the rumored lawsuit.

Eclipse Gains Local, Interstellar Support

April 1, 2005 – The Eclipse Foundation today has announced 14 new strategic members, encompassing leading IT vendors, major technology consumers and at least one alien race.

Many of the new members will be extending existing Eclipse projects. For example, the Sesame Workshop will lead development of a new cookie-handling format for the Business Intelligence and Reporting Tools project.

“Frankly, we like working with BIRT,” smiled Ernie, the affable spokesperson for the Sesame Workshop, “because it reminds us of our friend Bert. Bert likes cookies.”

“This open-source project is sponsored by the letters A and F, and the number 5,” added Ernie.

Getting involved in the Eclipse Foundation’s infrastructure challenges are Plumbers and Steamfitters Local No. 43 and Sheet Metal Workers Local No. 16. “It takes a lot of plumbing and ducting to make enterprise computing work,” said shop steward Fergus McEwan, who will represent the unions on the foundation’s board of directors.

McEwan indicated that the two locals will host membership rallies for Eclipse developers.

“It’s time to bring the power of collective bargaining into the open-source community,” he explained, “to improve wages, working conditions and job security.”

One new member fits into its own category: Strategic Warrior. According to Commander Klotha, the Klingon Imperial Navy has pledged to preserve the honor of all Eclipse developers, committers and consumers, while also donating battle-tested source code to support two new projects.

The Eclipse Test and Performance Tools for Deployment of Disruptor Based Techniques in Combat, or ETaPTfDoDBTiC, will be used to create open-source frameworks for programming and tuning real-time system controls for high-intensity phased photonic beam emission systems. Meanwhile, the new pIqaD project will seek to port the Eclipse IDE’s user interface to become compatible with the Klingonaase script and triangular display devices used on distant Qo’noS.

The Imperial fleet also will propose a Stellar Modeling Framework project to be added to the Eclipse Modeling Framework and newly formed Graphical Editing Framework. The SMF would be incubated within the Eclipse Technology Project, and would have many applications in sixth-dimensional cartography, tachyon flux computation, warp-speed navigation and Organian peace treaty negotiations, said the commander.

“You have good software tools on this planet,” praised Klotha. “Kai Eclipse! Qapla’!”