US Digital Services

The newest thing, a legacy of the rush to fix the Obamacare website, is the US Digital Services.

Digital services' role "will stop when we get you to minimally viable project," Kruger said. The team can help define user needs, build in analytics, wireframe the user experience, deploy and test alpha and beta versions, and generally tune and refine a service to ensure it can serve the intended purpose. "When we're happy with that, we'll hand it back to the business unit, and they'll own it -- to maintain it, to make improvements over time."

"We're not going to be here forever," he said. It is up to the business unit to plan for ongoing maintenance and support, and "from the beginning, we're going to have that conversation."

I think there are some downsides to this idea, or at least there would have been in the old days of COBOL.  One downside was the difficulty of understanding what's going on and making changes to the code.  That was at least one rationale for all the documents produced in the old "waterfall" software development process: users and systems analysts were supposed to produce a lot of documents at different levels of understanding (data, system flow, etc.) which would then enable their successors to understand what was going on.  My own feeling/guess is that what happened when these documents were produced was the people involved learned the process by writing documents, so there was a reasonable base of understanding among enough people to be able to handle people retiring, etc.

2008 GAO Helps Clinton on Email Records?

In the flap over Clinton's emails, I've not seen any mention of the GAO report in 2008 on problems in preserving e-records.  Turns out I included much of its summary and commented on it back then.

I won't repeat it here, but this paragraph is interesting in light of the current controversy:

"Preliminary results of GAO's ongoing review of e-mail records management at four agencies show that not all are meeting the challenges posed by e-mail records. Although the four agencies' e-mail records management policies addressed, with a few exceptions, the regulatory requirements, these requirements were not always met for the senior officials whose e-mail practices were reviewed. Each of the four agencies generally followed a print and file process to preserve e-mail records in paper-based recordkeeping systems, but for about half of the senior officials, e-mail records were not being appropriately identified and preserved in such systems. Print and file makes no sense--electronic is cheaper [regular type is GAO, italic is my 2008 comment]

 Let me repeat words: "followed a print and file process..."  In other words, the idea in these agencies, and I think generally throughout government, was:

1. not all emails were official records worthy of retention, just as not all paper documents generated within an agency were official records worthy of retention. 
2. someone was supposed to winnow the wheat from the chaff, go through the email, select the ones which merited retention, print them out, and file them in the paper filing system which was governed by records retention schedules approved by NARA. 

My comments then, though not well expressed, were based on these ideas:

1. the cost of retaining all electronic records was low, and becoming lower with every year Moore's law applied
2. the cost of reviewing, printing, and filing email as prescribed by NARA  was high
3. the likelihood of a bureaucracy doing no. 2 in an effective way was very low, as borne out by GAO's report
4. therefore, agencies should just keep all email in a searchable repository.

In the context of Clinton, there's two issues: the propriety of using a private email server for her work, on which I've no comment, and whether she complied with rules on preserving records, on which I will comment.  Clinton seems in the end to have complied better with the 2008 rules than many of the senior officials GAO looked at.  Were there changes in the rules after 2008?  I'm sure there were, as NARA continued to play a game of catchup, trying ineffectively to bring its filing systems and records retention systems into the modern word.  So I'm not saying she followed all applicable rules--she may have, may not have. I am saying her end result, in terms of selection and preservation, is well within the range for other senior officials. 

I'm also saying I was right in 2008--the simple effective rule is to retain all email records from email servers used for any government business, and let them be searchable.

Healthcare Behind the Scenes

Politico has a piece describing problems in the overall healthcare.gov system, mostly in the backend linking the signup process with the insurance companies, and extending into handling payments and change of life events.

Sounds a bit familiar from the good old days of the System/36.  One of the enduring lessons I learned was that for everything, whether it's a building or a software system, highways or ships, everything requires maintenance.  What that means for new systems, like healthcare.gov, is that you may implement and release a set of processes while planning to come along later with additional features.  But once you have the first release out, your time gets absorbed in the maintenance of those features, and the schedule for releasing version 2.0 slides.  And the sliding means that the jury-rigs to cover the gap grow and grow, and the problems of transitioning from the jury-rigged current system to the version 2.0 system, once available, also grow.

Cross Agency Collaboration

Steve Kelman in FCW on cross-agency collaboration:

"There is a common view among public management experts in academia and government that, as problems government faces become more complex, successful collaboration across agency boundaries grows increasingly important for delivering good results.
That collaboration is not easy. I remember reading in political science courses I took in graduate school decades ago about cross-agency coordinating councils. The view then was that it is extremely difficult for these activities to be effective, because agencies simply used them to advocate for the approach they took to problems, and tried to get other agencies to go along with that, rather than actually adapting their own behavior. Furthermore, these tended to be low-priority activities, to which organizations assigned the people least likely to be missed from their regular jobs."

 That's exactly what happened in Infoshare days--each agency had their pet idea which we tried to sell to the other agencies.  SCS wanted a laptop for field work, for example.  I wanted a new basic producer and farm data setup.  We didn't have the power to commit our agencies, not really, so when the impetus from the top faded, the whole house of cards collapsed. 

On User Interfaces

Via Technology Review (I think) comes this post discussing the design of the user interface of subway ticket machines for San Francisco and New York City.  It's got a twist in the middle, and having been a tourist in NYC myself, and being older getting more easily confused and less resilient in dealing with confusion, I end up valuing the design I dismissed when I started reading it.

Refining Algorithms and Systems, Help Systems, Driverless Cars and Obamacare

I had occasion yesterday to call the Verizon help line for assistance on installing a new router.  It has been 2 or more years since I've made a similar call, so I was struck by the significant improvement in their system.  I think there were at least 2 aspects:

• improving the logic of the automated decision tree.  I got to the applicable problem-solver much faster, and when there it was quite logical.
• linking the automated phone system with databases.  It wasn't new that the system knew my phone number.  It was new that it confirmed my identity.  It was new that it knew that they had just shipped a new router, so logically my call would most likely relate to that.

What's nice about software is that improvements, once made, tend to last.  If you fix a problem or made an enhancement, it's done forever, or at least for as long as the organization behind the system lasts. The critical factor is the organization is working to improve the system, as opposed to letting it survive on inertia.  But this ratchet effect for improving algorithms means that Google's driverless car can handle increasingly unusual traffic situations.  It also means that Obamacare's website can continue to improve. 

FSA IT Crimped

On page 29 and 30 of the Cromnibus, FSA IT is somewhat crimped: half the $132 mill is withheld pending a detailed analysis/report on projects over $25K.  (Copy and paste from GPO documents is unsatisfactory, so read yourself, if interested.  Everything has to fit the "Farm Service Agency Information Technology Roadmap", which sounds like something which should be available on the internet?

Software Design Mistakes of the Past and Present

A couple of articles this week on the redesign of the Obamacare web site: among the major changes, reducing the number of screens and permitting the use of the "back" button.

Those are familiar problems--the Treasury Direct website, which has been around for this century, still doesn't permit the use of the "back" button nor is it particularly user friendly in its design.

Going back to last century, when the original software for taking acreage reports was designed for the System/36, because no one had the experience, there was one screen for entering the crop, one screen for the practice, one screen for the intended usage, one for crop share, etc.--if I remember a total of 7 screens to report one field (i.e. common land unit as it's known now).  Naturally there was mass rebellion in the field, people couldn't use the software, and there was mass evasion of the issue in Washington and Kansas City.  We all knew we'd done the best we knew, and our childhood fairy tales assured us that anything done with good intentions would turn out well. 

I'm not sure I ever fully learned the lessons that episode might have taught.  I did oversee a redesign of the software in later years, but I was too much a coward really to research whether it was as usable as it should have been--after all computerization should make life better, not worse, shouldn't it?

I think of these things when I read about doctors upset with their digitized medical records systems.

ACA and FSA

From the NASCOE President's message: "

"Here we are in 2014 and we still don’t have a good online tool for producers to communicate and file applications on the simplest of programs (okay there are no simple programs)."

Now I don't know how complex the ACA health insurance program is, as compared to the FSA programs.  Obviously there were problems with the software last October, and I gather it's still incomplete as far as payments goes.  But HHS only had a few years to get the software done and tested, while FSA has had over 20 years since the idea was floated.  I'm really p****d at the botched rollout of healthcare.gov; it's almost enough to make me regret my political allegiance.  But I guess if I'm going to be fair, I should admit that compared to USDA/FSA HHS looks pretty good.  (That's probably the first and last compliment HHS will ever receive on their IT implementation.)

It's easy to argue I'm comparing apples and oranges, because I think administering the insurance program will be handled by the insurance company, not by the healthcare.gov website. And the philosophical question is simple: do you want to maximize efficiency or employment in rural areas.  If the former, then go the way some of the loan programs did--centralize administration in St. Louis.  If the latter, become friends with the senators and representative and fight to keep all offices open. 

I suspect we'll continue to muddle our way down the road, closing some offices, doing some modernization, trying to reach both goals: efficiency and rural life.

What's Happening on MIDAS: Congress Wants to Know

Getting around to the omnibus appropriations bill:  the first part of the report  dings USDA for failing to report timely on MIDAS.  Also says:

"In order to leverage existing capacity and expertise within the Department, the Secretary is directed to explore the creation of a Center of Excellence for loan servicing support functions in order to provide consolidated customer service, field office support, and centralized loan services to USDA agencies and other Federal agencies. The Secretary shall consult with employee representatives and management in the Farm Service Agency Farm Loan Information Technology, Accounting, and Finance Office loan servicing support functions; the Rural Development Deputy Chief Financial Officer and Deputy Chieflnformation Officer functions; and the Rural Housing Centralized Servicing Center."

Not sure what the quote means, except that someone, an employee, a contractor, or a congressperson has a bee in their bonnet.  "Center of Excellence"?  Sounds like bs to me.

Paperless FSA Operations

"The USDA Farm Service Agency offices are moving toward a paperless operation."

That's from a piece on producers receiving material by email.

I remember when the System/36 back in 1984 was being justified as allowing us to move to a paperless office.  Not sure that ever worked out.

ACA and FSA MIDAS

Being old, I've no need to sign up for Obamacare, so I've no personal experience with the website.  From what I've read, however, apparently the "navigators" who are helping people sign up are using the same software/website as those who are signing up on their own.  If so, that seems wise to me.  It's hard enough to keep one set of software operational and supporting the program.  It would be much harder to keep two sets up-to-date: one set for the public and one set for the government employees.  It would be particularly challenging when you have legislation passed late which requires changes to implement.

I don't know how MIDAS is set up, but I hope they've followed the same approach. 

Failure To Launch [Website] Successfully

New guidelines for treating people at risk for heart attack or stroke released today.  That's a subject near and dear to my head and heart, so naturally I went to the new calculator website  
to see how I rated.  Oops--apparently they've a problem (too much traffic perhaps). 

ACA IT and Testing

I can't resist the temptation to comment on the healthcare software process.  (BTW, here's a link to their blog.)

They've taken hits for not fully testing, which I can agree with.  On the other hand, remembering the test process we had for System/36 software, I can only imagine the problems they would have had. If my imagination is right, they had these choices for beginning to end testing:

• use live data--i.e., have all the 20-something IT types try to sign up for health insurance for real using their software.  That has some obvious problems, particularly when you have to cover 36 state exchanges. 
• create test data.  The problem here is while you can create applicants, you need to have SS numbers which meet the SSA criteria, and/or you need to create credit histories over at Experian, then you need to tack on test data for those SSN's with IRS, etc. 
• use a subset of live data for test data.  That's what we used to do--get a copy of a counties files in and modify the data to create test conditions. That's very problematic, both from a security standpoint and from a Privacy Act standpoint. And  our FSA system was simple compared to the sort of system ACA requires.

Words To Design By

From a TPM post on Kentucky's ACA IT system:

"From a design standpoint, Kentucky made the conscious choice to stick to the basics, rather than seeking to blow users away with a state-of-the-art consumer interface. A big part of that was knowing their demographics: A simpler site would make it easer to access for people without broadband Internet access, and the content was written at a sixth-grade reading level so it would be as easy to understand as possible.
"We wanted it to have a branded feel, but that was not the most important part," said Gwenda Bond, an exchange spokesperson. "The most important part was that it works. I think a lot of people would say that simplicity is good website design."

Software Problems

There seem to be many experts who are diagnosing the problems with the ACA online system.  I'm not going to join their ranks--I'm no expert.  I expect only those on the inside, and only some of those, know really what has gone wrong and how hard or easy it will be to fix.

The one thing I will say (immediately contradicting the paragraph above) is that they shouldn't have changed the design to put establishing an account first, instead of putting it at the end.  The problem seems likely to have been the change.  It apparently was too late in the day to make it; they should have kept on with the general design they started with.  That raises the question of whether they had buy-in on the system design from everyone, by which I mean Tavenner, Sebelius, OMB, and the President, well in advance.  

The closest I've ever come to this sort of problem was the 1983 payment-in-kind program, in which the Reagan administration strongarmed the lawyers into a tricky device to swap CCC-owned grain for acreage reductions, a program which I remember as being slapped together in about 2 weeks (though memory is probably fallible).  The Secretary had the Under Secretary ramrodding the implementation, because it was a high risk endeavor, and he had regular (daily?) meetings with the peons who were doing the scutwork. 

Ezra Klein Differs on ACA Software

Kevin Drum and Ezra Klein are notably more damning of the Obama administrations healthcare exchange software than I have been.  This from Klein:

'But the Obama administration did itself -- and the millions of people who wanted to explore signing up -- a terrible disservice by building a Web site that, four days into launch, is still unusable for most Americans. They knew that the only way to quiet the law's critics was to implement it effectively. And building a working e-commerce Web site is not an impossible task, even with the added challenges of getting various government data services to talk to each other. Instead, the Obama administration gave critics arguing that the law isn't ready for primetime more ammunition for their case.

Obama's Open Government Fail--on Obamacare

I just love to tweak IT types and goo-goo types about openness, and occasionally I like to tweak my liberal friends.  In that spirit, let me quote this from the NYTimes post on activity on the healthcare exchanges:

"It is unclear what the [healthcare] exchanges meant in citing heavy volume; most did not provide numbers, or even return phone calls in the first hours of operation. It is also unclear to what degree problems with the Web sites were due to the kind of technical hurdles that supporters of the program had warned about and that opponents had predicted would demonstrate its unwieldiness."

 Too bad HHS didn't require each exchange website to post their count of unique visitors.

More seriously, I expect the dust to settle and the glitches to get resolved (mostly) in the next few days or weeks, just as Medicare Part D did back in the Bush days.

Walt Jeffries and IT Development

Sugar Mountain Farm is a blog I follow.  Not sure why, maybe the combo of intimidating expertise, different lifestyle, humor, ....  and just enough commonality (that's not the right word, but it's close enough) with my rearing to be able to enjoy it vicariously.  (Come to think of it, I wonder if Walt ever read "Swiss Family Robinson", one of my favorite books when growing up.)

Anyhow, that's not the point.  Let me quote from most of a recent post:

Will [a son] is working on learning to weld stainless steel in preparation for making some of the parts we need for the butcher shop. Tractor ears was his first sheet metal project in stainless steel. By doing small useful tests we explore techniques and develop the necessary skills for design and production. This is a way. Chez Tao.

To build the butcher shop we developed techniques by building our cottage, a much smaller version using many of the same methods. Prior to the cottage we built the dog house. Before that a ferro cement and brick pig hut. Even earlier, table top models. With each progressively larger version we developed technique and honed skills.

To me that sounds much like the "code a little, test a little" process of software development and very different from the  big project "waterfall" model which used to reign supreme in the 1980's, and which seems to retain a hold even today.  It's a model which often leads to disaster, and waste of money--witness the failed project to create a common health record between DOD and VA.

There's not much point to this observation, except as it confirms the saying: "too soon old, too late smart".   There's much in my career I'd redo if I could.  And much of what I regret in my work life traces back to hubris. 

The Greeks were right.

Data Hubs

A couple days ago I mused about the pros and cons of data sharing versus centralized data.  Today my reading reintroduces me to the idea of "data hubs", not in the context of commercial software as in the Wikipedia article but in the context of ACA (Obamacare) implementation.  I imagine a video showing a circus performer/juggler, who juggles maybe 3 items, plus catching another, adding it to the juggling, then tossing out an item and catching another.

I think it still fits into my "sharing" category.