Showing posts with label computers. Show all posts
Showing posts with label computers. Show all posts

Tuesday, April 07, 2015

A Lawyer and a Computer Geek Walk Into Disbar

April 7, 2015, 11:45 a.m.

Based on a Computer-Savvy Lawyer Friend's Actual Experience

I was getting my ducks in a row for a meeting in forty minutes when I got a call out of the blue from Jerry. “Do you have time?”

“Not really. I’ve got a meeting in forty minutes and . . .”

“I’ve got court in an hour," he interrupted. "I have fifteen minutes, tops, to get this finished.”

I grimaced. People always bother me at the worst times for their emergencies. “Fine. Interest me.”

“Short version: the judge issued a discovery order. We have to come up with, and I quote, ‘a computer-readable set of search terms which may be automatically applied to discover relevant data.’ The problem is it’s all relevant. The judge is going to approve this set of search terms and order the other side to cough up the results. So I need a set of terms that will match everything, literally everything, and say that everything’s relevant.”

“Right. And this isn’t abuse of process because . . .?”

“Because the judge is the one who’s going to be approving my recommendation.”

“Caret-dot-plus-dollar.”

“What?”

“The search term you want. Caret-dot-plus-dollar. ^.+$. It’s a Perl regular expression. Computer-readable and matches everything. Nice and clear, nothing’s hidden from anyone.”

“No, man, that’s too easy. The other side will take one look at it and know something’s up. It has to look like it’s really fastidious, but it has to really match everything.”

I let out a sigh and started typing up a block of code. I wasn’t going to complicate things by hand when computers can complicate things far better than any human being. While I was typing out the instructions I kept talking with Jerry. “So you’re asking me to cooperate with you in an abuse of process.” [Photo credit: Krasner Law Offices -- in no way related to this story.]

“Not if the judge looks at it, agrees to it, and opposing counsel looks over it, their eyes glaze over, and they agree to it because clearly something so complicated can’t be objected to.”

“You’re a jerk, Jerry.”

“Oh, stop the moralizing. The entire process is bullshit. All I want to do is keep my job and maybe, maybe, hold on to the hope that someday I’ll make partner. That only happens if you get things done.”

“By abusing process.”

“You keep harping on that.”

“Because when the ethics committee hauls you in on it, I want to be able to tell them I warned you.”

“Work product. Confidentiality. Stuff like that.”

“I’m not your employee, privilege doesn’t apply, and you should know that already.”

“Jesus, you’re a downer.”

“Just saying.”

“So, uh — how long will it take? I’m running out of time here, man.”

I copied-and-pasted the output of the program I wrote into an email window and hit SEND. “Just sent it to you.”

“So after all that abusing-process stuff you’re going to cooperate?”

“Cooperated. Past-tense. If you want to call it that, then yeah.”

“Why?”

“Because I want to see if you’re stupid enough to submit to a judge a piece of code you don’t understand, haven’t vetted, and have no idea what it really does. For all you know I gave you something that prints out HIS HONOR WEARS HIS MOTHER’S CLOTHES. Should make your next court appearance real exciting, though, not knowing what’s going to happen to you, right?”

"You wouldn’t do that.”

“Yeah, well. It’s differences of opinion that make horse races interesting.”

“Jesus, Bill, I . . .”

I hung up on him.

I have no idea whether he submitted my code to the judge.

And he has no idea whether I was kidding.

# # #

Saturday, November 02, 2013

Exclusive: Insider Explains Healthcare.gov Fiasco

November 2, 2013, 4:00 p.m.

From 'Integration Testing' to 'Full End-to-End Testing'

Unless you've spent the last month in a cave with your mountain-dwelling guru, you're aware of the fiasco in the Obama Administration's roll out of the Web page that was supposed to provide the gateway for Americans' path to near-universal health insurance. [Cartoon credit: Steve Sack, Minneapolis Star-Tribune, Oct. 23, 2013.]

It's been hard to get the details on how such a thing could happen -- especially when Obamacare ("The Affordable Care Act") has been the one major accomplishment and showpiece of President Obama's Administration.

Of course, a part of the cause may have been CMS' [U.S. Centers for Medicare and Medicaid Services] failure to fully investigate the record of their prime contractor:
Canadian provincial health officials last year fired the parent company of CGI Federal, the prime contractor for the problem-plagued Obamacare health exchange websites . . . after the firm missed three years of deadlines and failed to deliver the province’s flagship online medical registry. . . . The CMS officials refused to say if federal officials knew of its parent company’s IT failure in Canada when awarding the six contracts.
Richard Pollock, "Canadian officials fired IT firm behind troubled Obamacare website," Washington Examiner, Oct. 10, 2013.

There is project management software appropriate to this task. It is called the PERT ("planning, evaluation, review technique") system, something used and developed in part by the Polaris submarine project as I observed it in the 1960s. Polaris required the ability to manage a project involving tens of thousands of sub-contractors under an extremely tight schedule. Surely PERT could have helped, with or without a failed CGI Federal.

Thus, the Healthcare.gov scenario has been a dramatic case study in both (1) the consequences of a failure to understand some basic principles of Management 101, and (2) how not to roll out a massive, new, and complex bit of software.

Although I did some computer programming in the simplistic Basic language over 30 years ago, since then I've limited myself to some easily mastered DOS and html commands and left the real programming to others. But I've experienced enough to agree with the observation of the head of a university's computer science department when told there were over 100 million lines of code in President Reagan's "Star Wars" program: "I've never seen a computer program that was more than three lines long that ran the first time it was tried."

So I asked a very reliable source whether I could share with you some professional insights which they have provided. This source, in no way affiliated with the Healthcare.gov effort, has so many years' experience in the business, in a variety of contexts, that to help to maintain his or her anonymity I have substituted "nn" in the following at the spot where they reveal that number. I found what was sent to be helpfully informative, and it's shared here in the hope and expectation you will find it so as well.

# # #

I've been closely following the developments in the healthcare.gov debacle. I'm not a politician nor a healthcare expert, so I really can't comment on whether the Affordable Care Act will achieve its goals or fatally undermine the American Dream. That sort of pontification I leave to Democrats and Republicans, respectively.

What I am, though, is a veteran software engineer with nn years of experience dealing with large projects in both the public and private sector.

Point blank: we have been lied to, and we are being lied to, about the future of the healthcare.gov site.

I could write five thousand words on precisely how many deceits are on display. I'll try to keep it under a few hundred and just focus on the one whopper of a lie that I believe even non-programmers can understand.

The contractors who originally delivered healthcare.gov advised the White House that full end-to-end integration testing had not been completed -- and, in fact, had not even started until a few days before the October 1 rollout. That's a technical term, "full end-to-end integration testing," so let me explain what we mean by that. Integration testing means "we're putting the pieces together to see if they work well." End-to-end integration testing means "we're putting *all* the pieces together to see if they work well." And finally, full end-to-end integration testing means, "we're putting *all* the pieces together and testing them exhaustively to ensure they work well."

To put things in terms of cars: when the team building the tires meets with the team building the hubcaps and the team building the rims and the team building the axles, and they make sure the tires fit on the axles and the hubcaps look nice, that's integration testing. When all the teams come together to assemble a complete car, that's end-to-end integration testing. And when they put a test driver behind the wheel and send the car out for a five hundred mile drive at the local track, that's full end-to-end integration testing.

Any engineer will tell you that full end-to-end integration testing is a headache and a half. Things always go wrong, and they're never the things you expect. As a result, full end-to-end integration testing takes a long time -- oftentimes measured in months.

Would you buy a car if the vendor said, "We only started test laps at the track a couple of days ago and it had some serious problems we haven't been able to fix"?

Of course not. But that's exactly what happened with healthcare.gov when it rolled out on October 1.

Secretary Sebelius has been publicly humiliated over the defects in healthcare.gov. She and the President have promised the website will be fixed and will be reliable no later than December 1.

My question is, where will she find the time to do full end-to-end integration testing? Even if all the changes to the healthcare.gov infrastructure are completed November 1, that still leaves only a month for testing to make sure the site works. The contractors who originally developed healthcare.gov were adamant that testing it properly would require months. From my own experience, I am inclined to think four months of testing is about the minimum required.

I'm not a politician and I'm not a healthcare expert -- but I'm a very good software engineer.

The system needs at least four months of testing and it's not going to get it. That means that, come December 1, the best we can hope for is that we will be delivered a new healthcare.gov site which will not have received any significant testing. Rather than being able to point to a record of successful tests, we will instead be asked to take Secretary Sebelius at her word. "Trust me! It works fine now."

Software that has not been thoroughly tested, or has not passed its thorough testing, is fundamentally incomplete.

Healthcare.gov will be fundamentally incomplete on December 1.

There's simply not enough time for it to be tested, and that means there's not enough time for it to be completed.

# # #

Saturday, July 13, 2013

Getting Humans Out of the Loop

July 13, 2013, 4:30 p.m.

What Can 'War Games' Teach About Disasters?

In the opening scene from the 1983 movie "War Games," two soldiers in a missile silo watching over ICBMs targeting Russia, receive what they believe to be orders for an actual launch. Before the end of their countdown, one finds himself unable to turn the key that he believes will cause the death of millions. Here is that opening:


In fact, it was only a test. A White House official, upon learning that 22% of the missile commanders failed to launch, visits NORAD. Dr. John McKittrick (Dabney Coleman) and other systems engineers at NORAD have concluded that command of the missile silos should be handled by computer. As Dr. McKittrick puts it to the White House official, over the objections of the commanding general, "I think we ought to take the men out of the loop." Ultimately, a supercomputer named WOPR (War Operation Plan Response), replaced the missile commanders, and spent its time continuously running simulations of U.S. military encounters with the Russians ("war games").

I won't reveal more about the film's story, in case you haven't yet watched it and I've inspired you to do so.

Last evening, for reasons unknown, I chose to watch it again for what was probably the tenth time during the last 30 years. Maybe it was our recent disasters that inspired me to watch it. Maybe it was the film that caused me to think about those disasters.

As it happens, both disasters occurred on the same day, one week ago, July 6th. And both raise the dilemma confronted by the characters in "War Games": from the standpoint of safety and reliability of human-machine systems is it better to have the humans in -- or "out of the loop"?

One of the disasters involved the Asiana Airlines Boeing 777 crash at the San Francisco airport on July 6, 2013, in which three died and 50 were seriously injured. Matthew L. Wald and Norimitsu Onishi, "In Asiana Crash Investigation, Early Focus Is on the Crew's Actions," New York Times, July 9, 2013, p. A12. A human had taken over the controls, as neither the airport's glide-slope indicator nor the plane's autopilot was activated. [Photo credit: John Green, San Jose Mercury News/Associated Press.]

The other was "A runaway train [that] exploded Saturday [July 6th], killing at least one person [by today, July 13th, the death toll is more like 50] and forcing more than 1,000 people to evacuate from a town in the province of Quebec, the police said. The 73-car train, which included tank cars carrying petroleum, destroyed much of downtown Lac-Mégantic, a town of about 6,000, in a blaze that continued through the day." Ian Austen, "Train Blast Kills at Least One and Forces Evacuations in Canada," New York Times, July 6, 2013. [Photo credit: Paul Chiasson, The Canadian Press/Associated Press.]

In the case of the plane crash,
The crash landing of a South Korean airliner in San Francisco has revived concerns that airline pilots get so little opportunity these days to fly without the aid of sophisticated automation that their stick-and-rudder skills are eroding. . . . [Lee Gang-guk was] flying without the aid of a key part of the airport's instrument landing system, which provides pilots with a glide slope to follow so that the plane isn't too high or low. ["Part of the instrument landing system on Runway 28 Left here had been shut down because of construction. The 777 is built to lock on to the instrument landing system, accepting its signals for lateral and horizontal navigation to land in the correct spot on the tarmac. American pilots use that capability often . . .." Matthew L. Wald and Norimitsu Onishi, "In Asiana Crash Investigation, Early Focus Is on the Crew's Actions," New York Times, July 9, 2013, p. A12. ]. . . And he was manually flying the plane with the autopilot shut off, which other pilots said is not unusual in the last stage of a landing, although some airlines prefer that their pilots use automated landing systems. . . . . Overall, automation has . . . been a boon to aviation safety, providing a consistent precision that humans can't duplicate. But pilots and safety officials have expressed concern in recent years that pilots' "automation addiction" has eroded their flying skills to the point that they sometimes don't know how to recover from stalls and other problems. Dozens of accidents in which planes stalled in flight or got into unusual positions from which pilots were unable to recover have occurred in recent years.
Joan Lowy, "Role of Aircraft Automation Eyed in Air Crash," Associated Press, July 9, 2013.

The analysis of the Lac-Mégantic tragedy is a little more nuanced, but raises similar issues:
Revered by NASA rocket engineers and surgeons alike, [renowned U.K.-based safety theorist James] Reason’s most famous legacy is the “Swiss cheese model,” which imagines safety checks to be like slices of cheese.

When a safety system is airtight and closely followed, the slices are cheddar: Rigid and impermeable to error.

Overtime, however, as employees grow complacent and safety standards slip, the slices begin to develop Swiss-cheese-like holes through which mistakes are allowed to pass.

If the holes are allowed to multiply, it is only a matter of time before a simple mistake can pass clean through all the layers of cheese and trigger a disaster.

“There is a growing appreciation that large scale disasters … are the result of separate small events that become linked and amplified in ways that are incomprehensible and unpredictable,” wrote the U.S. organizational theorist Karl E. Weick in a 1990 analysis of the 1977 Tenerife air disaster, in which two fully-loaded 747s collided at a Canary Islands airport.

The disaster is now a textbook case of organizational vulnerability: If any one of a myriad of tiny blunders (a stressed crew, foggy weather, a crowded tarmac, botched radio communications and a first officer unwilling to criticize his captain) had been avoided, Tenerife’s 583 victims would still be alive.

Similarly, although the RMS Titanic struck an iceberg — a seeming natural disaster — its maiden voyage was doomed by decades of lax British safety standards. The liner was charging at top speed through a patch of ocean known to be unusually icy, a design flaw rendered its watertight compartments useless if the ship settled too low in the water, and not only was the Titanic famously not carrying nearly enough lifeboats, but the crew lacked any official policy on how to deploy them.

Already, the latticework of errors that caused the Lac-Mégantic disaster have begun to emerge.

For starters, the event that appears to have kicked off the disaster was a locomotive fire that broke out only minutes after engineer Tom Harding had parked the train. And, even if not a single hand brake had been applied, the train should have been held in place by air brakes. Further, the train was parked on a main line instead of a siding equipped with safety features to combat runaway trains. Also, the train was hauling enough crude oil to fill three Olympic swimming pools, yet carried it in a class of railcars highlighted by regulators as being uniquely vulnerable to leaks and explosions.

Most chillingly, this has all seemingly happened before.

In 1996, a string of 20 grain cars rolled free in an Edson, Alta., train yard, accelerating to 50 km/h before smashing head-on into the locomotive of a CN freight train. In the resulting explosion and fire, three crew members were killed.

As possibly at Lac-Mégantic, the ultimate cause of the crash was the faulty application of hand brakes: Train crews had received “little supervision” in how to properly set the brakes and the brakes they did set were almost useless due to missing parts.
Tristin Hopper, "'Complex' Latticework of Errors That Caused Lac-Mégantic Train Disaster Has Just Begun to Emerge," National Post July 13, 2013

So what's the answer? The answer is that there is no answer, as succinctly put in the aphorism, "To err is human, to really foul things up requires a computer." When informed that the software to run President Reagan's Strategic Defense Initiative ("Star Wars") program ran to over 100 million lines of code, a computer science professor is said to have responded, "I've never seen a computer program of over three lines of code that worked the first time it was run."

On the other hand, planes -- commercial airlines as well as drones -- can fly themselves. There are reasons to have pilots and flight attendants on flights; but it's not because the plane is incapable of getting you there by itself. We already have cars that can drive themselves. Trains have automatic braking systems. Tractors navigating by GPS can more precisely apply fertilizer, and plant seeds in straighter rows, than sharp-eyed farmers. From the standpoint of safety, we might be better off spending more on computer programmers and less on equipment operators.

"Despite rising fears of technology displacing huge swaths of the workforce, there remain huge classes of jobs that robots (and low-wage foreign workers) still can’t replace in the United States, and won’t replace any time soon. To land the best of those jobs, workers need sophisticated vocabularies, advanced problem-solving abilities and other high-value skills that the U.S. economy does a good job of bestowing on young people from wealthy families — but can’t seem to deliver to poor and middle-class kids. . . . In the past 20 years, almost all the net job gains were in the two areas computers struggle with the most: working with new info (for example, figuring out a customer’s Internet service issues) and solving unstructured problems (such as repairing cars when computer diagnostics can’t pinpoint what’s wrong)." Jim Tankersley, "Have the Robots Come for the Middle Class?" Washington Post, July 12, 2013.

There are many among our skilled labor force who are experienced and conscientious. We wouldn't have the country we live in without their skills and efforts. They are often under-appreciated, under-paid, and working in unsafe conditions.

But relying on humans comes with risks. Employers may cut the workforce below the number necessary to keep equipment properly maintained, replaced when necessary, and watched over when operating. New, young employees may not be adequately trained and experienced. Long hours may increase the likelihood of accidents. (The train wreck and explosion in Lac-Mégantic occurred after 1:00 a.m.; the Asiana crash at the end of a ten-hour night flight across the Pacific Ocean.) An employee may fail to show up, or be impaired by alcohol or other drugs, talking on a cell phone or texting.

"As planemakers build ever-safer jets, it’s often the split-second decisions by humans at the controls that can make the biggest difference between a smooth landing and a flight that ends in disaster. The last moments of Asiana Airlines . . . Flight 214 . . . underscore the stakes in the cockpit even in aircraft as sophisticated as [a Boeing 777], according to safety consultants, retired pilots and aviation scholars following the U.S. investigation. . . . 'Whether it’s a disaster or a close call comes down to the pilot,” said Les Westbrooks, a former commercial and military pilot who now teaches airline operations at Embry-Riddle Aeronautical University. “Airplanes have incredible automation. But when the human has to exercise judgment, you can’t design around that.'” Mary Jane Credeur, Mary Schlangenstein and Julie Johnsson, "Asiana Crash Shows Lessons of Pilots Trumping Technology," Bloomberg, July 9, 2013.

Of course, there's more to humans in the workplace than their superiority to computers -- when that's the case. If we fully automate everything the computer programmers can automate, which is a lot, we end up with an even more severe unemployment problem than we have now. And we create stores and service centers that seemingly have no employees -- after entering a big box store you're on your own with nothing but a hunting license, and when you go to check out the only reason you get assistance with the self-checkout is that without it frustrated customers would simply give up and leave without paying. There would be nothing but automated answering, voice recognition phones.

But now that computers can beat the world chess champions, and win at "Jeopardy," we better get used to fellow workers who look a whole lot like robots, and be willing to hand the controls over to them once it becomes obvious that they really can do a better job than we can when landing a plane or driving in bumper-to-bumper freeway traffic.

# # #

Tuesday, September 07, 2010

The Medieval Helpdesk

September 7, 2010, 9:40 a.m.
(Looking for Labor Day blog entries? Here they are: "Labor Day: Honor Workers Every Day," September 6, 2010; "Finding Jobs on Labor Day; Former Labor Secretary Reich Has Economic Solution," September 5, 2010; and "Danger in the Workplace; Honoring Those Who Built, and Build, America," September 1, 2010.)

A You Tube Video Worth 1000 Words
(bought to you by FromDC2Iowa.blogspot.com*)

Whether you're taking "customer support" calls, or trying to get someone to answer when you make one, here's a You Tube video that's going around and should provide you a little relief -- and a laugh.

The new digital tech keeps coming at us fast. What it can do and how it does it is not immediately obvious -- especially if you didn't design it, all you did was just buy it. For such confidence-building as it may provide, know that it has always been thus.

Here is "Medieval Helpdesk in English":



_______________

* Why do I put this blog ID at the top of the entry, when you know full well what blog you're reading? Because there are a number of Internet sites that, for whatever reason, simply take the blog entries of others and reproduce them as their own without crediting the source. I don't mind the flattering attention, but would appreciate acknowledgment as the source -- even if I have to embed it myself.
-- Nicholas Johnson
# # #