Jacoby on Health Care

Jeff Jacoby dropped another turd in my Sunday Boston Globe, this time about how awful it is that people might spend more on health care when they have insurance than they would otherwise. Let’s start with the lesser of his two mental malfunctions first, just to get it out of the way.

Why is health insurance so expensive? One explanation is that the extraordinary gains medical science has made over the last few decades come with hefty price tags. The revolution in cardiac care, the myriad new drugs, the invention of CAT scanners and MRIs, the ability to transplant organs — these and so many other lifesaving medical miracles didn’t come cheap. It stands to reason that insurance covering the cost of such miracles doesn’t come cheap either.

But wait — does it stand to reason? Information technology has exploded in recent decades too, yet computers have never been as affordable as they are now.

Jacoby’s “one explanation” is not based on any actual facts. People who have actually studied this subject have found many contributing factors to rising health-care costs – an aging population, higher physician salaries, increased administrative costs, shifts in focus from prevention to late-stage intervention, litigation and malpractice insurance, prescription drug prices propped up by government patent and procurement policy, etc. Yes, those MRI scanners do contribute to costs somewhat, but they’re far from the driving force and their price has come down as technology has improved. Having an MRI scanner still costs more than not having an MRI scanner, though, just as having a personal computer or television costs more than not having one, no matter how much the price for all of those things might have decreased over the years. The difference is that it might be reasonable to say that someone should forego the use of the PC or TV, but denying them an MRI scan is often a bit less reasonable. That brings us to Jacoby’s more serious crime against reason.

Why does it matter whether Americans pay for medical care directly or let insurers cover their bills? Because thrift and price awareness usually go out the window when we’re spending other people’s money. Under the present setup, most Americans have little incentive to be economical consumers of healthcare. As a result, health care expenditures — and insurance premiums — have been racing upward at three and four times the rate of inflation.

Oh yes, it’s all about “thrift” isn’t it? Decreasing costs is the most important goal, right? WRONG! Very few people pursue health care as a form of recreation. When they incur those costs it’s not for fun; it’s because they’re sick or injured and they want to be well again. As economists would say, demand for health-care services is a lot less elastic than for most commodities. People don’t rush out and break a leg or catch a disease just because treatment is cheaper. Let’s put this in very simple terms. Imagine that there’s a $1000 pill that can cure some fatal disease, and insurance enables 1000 people to have that pill who wouldn’t otherwise be able to afford it. Sure, it’s cheaper to deny them the pill, but is that a better outcome? Obviously not. Despite what Jacoby and other disciples of Mammon might tell us, being cheap isn’t the only goal – not for most things, and especially not for health care. There are other measures that also apply. When Jacoby gets paid for copying other people’s work, does he spend it only on the cheapest house, the cheapest car, the cheapest food? Obviously he’s willing to forego a decent haircut, but would he be willing to forego medical treatment that he could only afford because of insurance? Remember, all insurance claims – whether the insurance is employer-provided or privately purchased – are a way of spending someone else’s money. The truly “thrifty” by Jacoby’s own definition would do everything they could to keep premiums down, even if that meant sacrifice. But, as we well know, to a conservative, sacrifice is always for other people.

Monday Amy

Some pictures from the week or so leading up to Christmas.

Amy with Daniel Amy on the chair with Daniel. Along with the wombat and the various platypuses, Daniel has been one of Amy’s enduring favorites. He’s also the referent for the term “Daniel cookie” referring to an Oreo.
Amy's new dress Amy in a dress that Cindy made. I think it looks pretty great, especially in this picture.
Amy with Cindy and Grammy Christmas day. What more is there to say?

Moving Right Along

“OK, Jeff,” I can imagine people saying, “enough about Revivio. How about SiCortex?” Well, now that I’ve been there a week, I’ll try to answer.

First off, the technology still seems way cool. 5832 processors in one system is still pretty awesome, even if they’re not the fastest processors on the planet. Having a really fast interconnect built right onto the chip is pretty neat too. Dolphin’s products were pretty good for their time – 1.6Gb/s full duplex in 1996, with 4.0Gb/s always right around the corner – but 2GB/s times three coming in plus the same going out makes that seem pretty wimpy. Depending on how you look at it, that’s either a 12x or a 30x improvement in ten years. Just for perspective, that’s about the same as CPU speeds going from 100MHz to 3GHz, or disk capacities going from 10GB to 300GB, and better than disk-interface speeds going from 160Mb/s to 4Gb/s – all changes which took about the same amount of time. It just so happens that the “fabric” is where I’ve spent most of my time so far, which is pretty exciting. There’s tremendous complexity there, but also tremendous opportunity to solve fun problems. I’ve turned notions of power efficiency and CPU/memory/communication balance over and over in my head, trying to find the fatal flaw in the reasoning behind the product, and I’m still pretty convinced we’re on the right track.

Another good thing about SiCortex is the people. In the past I’ve usually known as much as anyone around me about anything relevant to the product I’m working on, or at least been within a short conversation of that. Not so at SiCortex. The product is so complex and so advanced, and the people around me are such experts in fields where I’ve never even dabbled, that I have to accept that I’ll never understand something like they do. That’s a bit of an adjustment for someone who takes pride in breadth of knowledge and experience. I’ve often said, though, that if I’m not a little bit intimidated then I’m probably not challenging myself enough. Another thing that helps is that everyone so far has been really nice. Sometimes it seems that as expertise increases so do aloofness and arrogance, becoming almost intolerable well below the technical level these guys are at, but so far everyone from the CEO on down has literally gone out of their way to include me and make me feel welcome and help me get up to speed. I’ve actually noticed the same thing in a few other “big names” (which I won’t drop) in the field, so I wonder whether the real top-flight techies sort of get “over the summit” attitude-wise and mellow out. Maybe I’ll get there some day. ;)

Here are some other random notes.

  • The commute isn’t bothering me so far. It’s almost exactly a half-marathon away, not that I ever intend to run it, which means about 20-30 minutes each way. I’d been spoiled by the ten-minute commute to Revivio, but the route’s almost scenic and I don’t mind listening to the radio a bit more.
  • The cafeteria downstairs is very impressive, and of course convenient. The prices are on the high side, though, probably higher than the local sandwich shops and such.
  • Speaking of local sandwich shops, I remember when downtown Maynard seemed almost totally deserted. Now it’s quite lively, with a lot of restaurants and shops and people (a high percentage of whom seem to be 20-something techies from Clock Tower Place) roaming around.
  • Speaking of Clock Tower Place, it’s an amazingly funky place. I’d heard the stories about walkways and tunnels between buildings, and floors that don’t match up, and little hidden routes, and they’re all true. I already found one route from Building Three to Building Five (nipping through a corner of Building Four) that involves a very narrow and well-hidden stairway and makes me feel like a kid exploring secret passages. The downside of a space like this is the noise. I don’t know what those people upstairs from us do, but there are some truly amazing thuds at times. I hope nobody has been hurt.

That’s all I can think of for now. I’m sure I’ll have more to say as time goes by.

Setting the Record Straight

I knew that someone would read my article about Revivio and try to turn it into something it isn’t. Chris Mellor, who I’ve never heard of before and who I doubt knows all that much about Revivio except what he has read in other publications, apparently skipped my disclaimers and then stretched quite a bit to come up with something snarky enough for publication. Here’s his jumped-to conclusion.

What has Symantec bought? It sounds like there will need to a lot of product clean-up work before the Revivio CDP product becomes a usable and reliable one.

Sorry, Chris, but it was already usable and reliable. It was just not selling as well as we’d hoped, largely for the reasons I mentioned. Sure, Revivio had problems, but – as another linker correctly pointed out – they’re pretty typical ones for a startup. I don’t know when you were last a player instead of a kibitzer, but I’d be surprised if any startup completely lacked such problems. At least Revivio had a good idea and a lot of excellent people working on it, which most startups don’t. What Symantec has bought is nothing to be ashamed of, and any rework that will be necessary is no more than should be expected whenever one company absorbs another’s technology.

Jacoby Lies Again

Yeah, I know, that’s not news. In today’s Globe, Jeff Jacoby has a polemic entitled The debate shifts to the left. Here’s his thesis.

A more liberal policy agenda isn’t all that will be moving into the spotlight. There will be a heightened focus on liberal arguments as well — which means we’ll be hearing more about good intentions and less about good results. Political discourse will dwell even more than it already does on “fairness” and “compassion” and “unmet needs” — and even less on factual evidence and the historical record.

Here’s the example he chooses.

The minimum-wage issue illustrates the pattern. Proponents of this quintessentially liberal prescription emphasize the difficulties faced by those trying to make a living and support a family while working a minimum-wage job.

Opponents, by contrast, point to data and economics. They note, for example, that most minimum-wage workers are neither poor nor family breadwinners, but singles in their teens or early 20s, often students working part-time while living with Mom and Dad.

Note that JJ doesn’t provide any sources. Here’s one. (Yes, I know it’s slightly old, but it’s highly doubtful that much has changed.) How do minimum-wage opponents’ claims match up against the actual facts? Well, according to this source and consistent with others, 71% of those under the prevailing minimum wage and 79% of those above that but below the proposed minimum wage (the cutoff that really matters) are in families at 150% of the poverty line or less. They might not be totally destitute, but they are poor, so one half of Jacoby’s claim is patently false. As for breadwinners, he might be technically correct. Between 19.2% and 24.6% of the sample are parents, so some even smaller number must be breadwinners. That’s misleading, though, because in poor families the “breadwinner” often doesn’t earn all of the bread. For example, I worked in high school but all of my income went toward putting food on the table instead of movies and video games like it would for wealthier kids. The composite statement that “most minimum-wage workers are neither poor nor family breadwinners” remains false in any case because most are one or the other even if they’re not both. Similarly, while most minimum-wage workers are students and some work part-time (often not by choice) and some (probably few of the 53.2% to 57.9% over age 25) live with Mom and Dad, to say that “often” minimum-wage workers meet all three criteria is a stretch. Not often enough for that to be anything more than another convenient stereotype. Let’s look at the next misstatement.

“The enactment of the first federal minimum wage law in 1933,” writes economist Thomas Sowell, “raised the average wage rate in the Southern textile industry by 70 percent — and half a million blacks nationwide lost their jobs.”

Hm. How do you reconcile that with this statement from my source?

Overall, recent studies have found that minimum wages have negative effects on employment but the magnitudes have varied across studies. At the lower end, researchers have found that a 10 percent minimum wage hike would reduce employment by only 1 percent. At the high end, other researchers have found that the same hike would reduce employment by 10 percent.(8) Moreover, other studies have concluded that minimum wages have no effect or a positive effect on employment.(9)

Well, we might start to distinguish the two by noting that JJ’s claim is unsubstantiated and comes from a prominent full-time employee of the right-wing noise machine, while mine is thoroughly substantiated and comes from the US government. Which is closer to “relying on data and economics” as JJ seems to think we should?

Jacoby isn’t afraid that “factual evidence and the historical record” will be supplanted by appeals to compassion. He’s afraid that factual evidence and the historical record will be more prevalent, supplanting the myths and distortions he uses to deny any need for compassion. He’s afraid that the debate will become more empirical and rational, not less.

Amy Sayings

Yesterday was ridiculously warm for January in New England, so I decided to take advantage and asked Amy if she wanted to go outside (meaning the back yard). She agreed enthusiastically, so we did the whole shoes-and-socks-and-jacket routine and headed out. By the door were some flowerpots and such that were filled with leaves and rainwater. Amy stopped, looked for a moment, and then pronounced, “Leaves diving.”

Another recurring source of amusement is the way Amy uses “tired” to mean “unavailable” (or something similar). It doesn’t seem so strange when we try to encourage her to play or read with Cindy once in a while instead of wearing me out and she says “Daddy tired” in that very disappointed/accusatory way. It’s a little funnier when we tell her we’re not going to play with the computer (or any game/toy/inanimate object) right now and she comes out with “Computer tired.” That’s usually good for at least two or three chuckles a day.

What Happened At Revivio

I’m kind of itching to write about my new job, but I kind of promised I wouldn’t do that until I’d written something about the old one. Most of what I’ll have to say is negative, not because everything that happened at Revivio was bad but because – like many engineers – I tend to focus more on things that go wrong and can be fixed than on things that go right and don’t seem to require further attention. I’m sure somebody will be offended by something I say here. Oh well. It’s all but impossible to write about something that turned out so poorly without someone feeling that they’re being blamed, but blame is not my intent. What I hope is that those of us who were there will learn from our experience, and maybe someone else will learn too, and neither can happen if our mistakes remain unexamined or unremarked.

What happened at Revivio was basically attributable to three factors, in decreasing order of importance: strategy, organization, and technology. Strategy was by far the most significant. To put it simply, we chased the wrong market. Enterprise storage customers are unbelievably demanding. Many just won’t even talk to startups. At all. Ever. End of story. Others will talk . . . and talk, and talk, and talk, requiring endless justification and persuasion all up and down the management chain before you even get to the point where a normal sales cycle would start. Way too many times, our salespeople thought they were about to close a deal, then all of a sudden there’s a new key player who’s skeptical or outright hostile, and at best we’d have to start all over again. Even those who finally did sign often required amazing amounts of free support as part of the package, often solving problems that were absolutely nothing to do with us or our product, just to prove our mettle and our commitment. Then, the contracts were written so that even after they had formally accepted the product they could throw it back in our face for no reason whatsoever and get their money back. I don’t think our salespeople or execs were incompetent to accept such terms; they were just desperate, but we still got burned by those deals.

Another strategic factor was that our product was just too new. We not only had to develop the technology for what is now known as Continuous Data Protection, but we had to create an awareness in the industry that this previously-impossible thing was now real and beneficial to storage consumers. We’ve all heard about the so-called First Mover Advantage, but I’m a big believer in the Second Mover Advantage. It’s very rare in this industry for the real originators of an idea to be the ones who profit most from it. NetApp didn’t invent network storage. EMC didn’t invent RAID. Microsoft didn’t invent windowing systems, and neither did Apple. The very energy and resources required to develop and evangelize any new idea become unavailable to exploit it commercially, leaving those who bear that expense at a disadvantage compared to latecomers who can devote 100% of their energy and resources to exploitation. One reaps, another sows. Somebody will make a lot more money from CDP than Revivio ever did. Yes, it’s natural to ask how this theory applies to “Dense Cluster Computing” but I’ll leave that answer for another day.

The second set of problems at Revivio was organizational. I was not the first or only person there to remark that Revivio seemed to be more Balkanized and have more communication problems than any company its size ever should. Management was usually off in their own world of closed-door meetings between the same dozen people – none of whom had ever so much as installed the product – but that’s normal at tech companies. The problem I’m thinking of was down in the trenches. From the early days when development was split into three groups (platform, indexing, and system management) to the late ones when it was just two (work and play) there was an amazing tendency for groups or even individual developers just to go their own way without bothering to tell others who were affected. Most developers had only a tenuous relationship with QA, and none at all with CS. Requirements and completion criteria were generally missing, or so confusing and whim-driven that simple absence would have been a blessing. It was really sad. I was made product architect partly to solve these problems within the development organization, but at this point I’d have to say I failed. Yes, I did well enough that we managed to get a product out. However, there was only so much I could do. Without innate authority even to reject checkins on the basis of technical insufficiency or inconsistency, and with only lukewarm support from those who did have such power, there was not much I could do if a developer decided to thumb his (or her) nose at the product architecture or even basic software-engineering practice. Short of jumping in and rewriting code that we had already paid someone to write, all I could do was offer warnings or criticism that fell on deaf ears . . . until the predictable bugs and integration problems generated the predictable crisis. Did I mention that we spent way too much time in crisis mode? Anyway, I did sometimes manage to avert some of the worst disasters, but they were always a few raindrops in a downpour.

But enough about me . . . or maybe not, because I exemplify another part of the problem. Nobody ever seemed to have a $#@! clue who was helping or hurting the company. Some people who busted their humps trying to do the right thing consistently got no credit at all and eventually got laid off. Other people who spent half their time on unapproved pet projects and the other half schmoozing just coasted right along, and often seemed to benefit compared to if they’d been more diligent. Some of my own most crucial contributions were ignored, taken for granted, or even mocked. Some other things that I did were recognized and rewarded out of all proportion to the difficulty or sacrifice involved. Overall I admit that I was among those who benefited from this corporate inability to tell good from bad, not to the extent that anyone dropped a huge bonus on me while others were being laid off or anything like that, but still. Just because I was a beneficiary rather than a victim doesn’t mean I was blind to the problem, though. If there’s one thing that was fully under Revivio’s control and that they were really bad at, it was this issue of credit and accountability and motivation.

I’ve left the technical issues until last because, frankly, I think they contributed least to the negative outcome. Everyone who worked there knows we had major issues with the third-party software we were using, from its initial selection to now. I don’t want to get in trouble for describing technology that is now the property of Symantec, but I will say that I’m referring to all of the third-party software, not just the obvious culprits that people seem to have eliminated but also some that I know are still in use. I’ve known companies to be too afflicted with the “Not Invented Here” syndrome, but Revivio almost seemed to have its opposite. We had opportunites to build something more suited to our purposes, in some cases we expended significant resources on developing them, but in almost every case we succumbed to the old “bug fixes will be someone else’s problem” narcotic. Relatedly, we also had problems with multiple languages and paradigms within the system. Getting different parts of the system to talk, when each was written in a different language and with a fundamentally different view of the world, was often a nightmare. There were way too many communication paths as well, many of them bizarre and cumbersome by anyone’s estimation but their author’s. Way too many technical decisions were made based on who would be doing the work instead of what was best for the system, but that’s more a reflection of the already-discussed organizational problems than of anything truly technical. In the end, though, every day spent getting code to solve actual product-functionality problems seemed to require three more figuring out how to fit into the weird little ecosystem we’d made for ourselves. Here I share blame with the other senior technical staff. All too often, the senior person who had complained the loudest about a problem was the least helpful in finding or implementing a solution, so we just ended up with churn instead of progress.

What would I have done differently? First and foremost, I would have targeted a different market. We could have had a non-highly-available system with better performance ready a year sooner than the product we actually shipped, and it would have faced fewer barriers in the market. We could have had a hundred customers by spring 2006, instead of a dozen by fall. Then we could have begun work on the scaled-up version. I would have insisted on simple but firm requirements and exit criteria. I would have had not one but two architect-level people with real authority to ensure that what got produced matched what was needed and not the developers’ own preferences. One would have been the traditional “think about all the hard problems and draw the big boxes” kind of architect. The other would be like a super release engineer, responsible for code quality. That means staying on top of every checkin, immediately and peremptorily rejecting those that do not meet either formal or informal standards. It also means running code-analysis tools, analyzing defect trends, etc. It would be nice if these two functions could be performed by one person, but even in a small development organization it’s just too high a workload. The goal, not just in development but throughout the company, would be empiricism. Measurable results should matter more than personality or presence in the right meetings. That means measurements must be made, and people who measure up poorly given the opportunity to improve or leave. If Revivio had adopted that philosophy, most of the “old crew” would still be working at Hartwell Ave., finishing up the third generation of the product and planning what to do with all that money after the IPO later this year. We certainly had the technical talent to do it, and I think we probably had the business talent as well, but somehow all of that ability never crystallized into a team that could win. A few key decisions years ago, filtered through an organization that tended to magnify mistakes and attenuate success, ended up making all the difference.