Is NODE_ENV an Anti-Pattern?

(In which I make the argument that using a configuration file (or two) is a better idea than setting the NODE_ENV environment variable and propose the use of the SN Props package to make this process easier.)

Like everyone else in the node community, I started out using the NODE_ENV environment variable to set various details in my apps. I would do something like this to start an app:

$ NODE_ENV=dev /usr/bin/node foo.js

The shell would set the environment variable NODE_ENV to the string "dev" and launch the foo.js node application. Inside foo.js, we would do something like this:

var port, host; 

if( "prod" === process.env.NODE_ENV ) {
  port = 80; host = "0.0.0.0";
} else if( "dev" === process.env.NODE_ENV ) {
  port = 8080; host = "127.0.0.1";
} else {
  console.log( "ERROR: unsupported NODE_ENV value: " +
               process.env.NODE_ENV );
  process.exit(1);
} 

// insert other code here 

server.listen( port, host );

And honestly, there's nothing seriously wrong with this. It lets you express different application behavior based on whether you're running in development-mode or if you've deployed to production. But then I saw this:

var port, host, db_pass; 

if( "prod" === process.env.NODE_ENV ) {
  port = 80; host = "0.0.0.0"; db_pass = "tq6TJwFR";
} else if( "dev" === process.env.NODE_ENV ) {
  port = 8080; host = "127.0.0.1"; db_pass = "2qpwRfKB";

} else {
  console.log( "ERROR: unsupported NODE_ENV value: " +
               process.env.NODE_ENV );
  process.exit(1);
} 

// insert code to connect to the database here

server.listen( port, host );

 And where did I see this? In the source repository, of course.

Now I don't want to be too snobbish, I've written apps that check the password into the source repo before. At the time I thought it was a simple, throw-away app that no one would use after a couple months. By the time the wiley black-hats found this in the source repo, the app would be long-retired. Except that's never the way the world works. The code got used by a different group in the organization and then sold to a third party. By the time I heard what had happened, one of the third parties had lined up a SAS-70 audit they may have failed because of a fixed password in the system.

Moral of the story? Don't hard-code database passwords into your app.

"But what does this have to do with NODE_ENV being an anti-pattern?" you ask.

Simple, using NODE_ENV to set application behavior makes it easy for a developer to do bad things (like hard-coding dev & production environment passwords into the app.) In my apps, I've replaced the use of NODE_ENV with what I call the "Concatenated Config" pattern.

Avoiding Application Brittleness with the Concatenated Config Pattern

Instead of setting my config parameters from an environment variable inside the code, I use multiple JSON files to hold config settings and import them as a javascript object. The SN Props package does all the heavy lifting for you. So now, I launch an app like this:

$ node ./bar.js \
    --config file:///opt/bar/dev.json \
    --config file:///opt/bar/db_dev.json

SN Props reads the command line looking for URLs pointing to JSON files. In this example, it grabs the files /opt/bar/dev.json and /opt/bar/db_dev.json, smooshes them together and passes them to your app via a callback. Here's what the code in bar.js looks like:

require( 'sn-props' ).read( function( props ) {
  // db code goes here
  // http server code goes here
} );

And the contents of the two config files look something like this:

/opt/bar/production.json:
{
  "listen": {
    "port": 8080,
    "host": "127.0.0.1"
  }
}

/opt/bar/db_db002.json:
{
  "mysql": {
    "host": "127.0.0.1",
    "port": 3306,
    "user": "dev",
    "pass": "goats!"
  }
}

and, of course, you probably want to define other configs to use in production:

/opt/bar/production.json:
{
  "listen": {
    "port": 80,
    "host": "0.0.0.0"
  }
}

/opt/bar/db_db002.json:
{
  "mysql": {
    "host": "db002.internal.example.com",
    "port": 3306,
    "user": "bar",
    "pass": "JC7VwyguUqHm8D3J"
  }
}

And if you trust your internal infrastructure, you can replace references to file: URLs with references to http: URLs. You can probably figure out what this does:

$ node ./bar.js \
    --config https://config.example.com/dev.json \
    --config file:///opt/bar/db_dev.json

Let's Recap:

The benefits of this pattern are:

1. It discourages hard-coding passwords and other config information into the applications source. (i.e. - it discourages something that would make your app brittle and possibly insecure.)
2. It lets your DevOps team change configuration details like DB particulars & which port and IP address your app listens on without having to touch the app code.
3. If you trust your internal infrastructure, you can put all of your app configuration information on a single http(s) instance.

There are a few draw-backs, but they're relatively mild:

1. Command line invocations are a little longer
2. There are (potentially) multiple places to look when there's a configuration error
3. A malformed JSON config file will cause your app to not launch.

is email dead?

it was a rainy night; cold too. i got the call from 5th precinct that another protocol had taken the long trip to nowheresville.

"whadda we got here, charlie?" i asked o'malley, the flatfoot in charge of keeping the press hounds at bay.

"not sure, sir" he mewled back. something was wrong. o'malley was shaken up. something was definitely wrong.

"okay, let's take a look at the corpse." o'malley lifted up the sheet and i gasped. damn if it wasn't ol' mr. killer app himself: email.

i scouted the apartment for leads. this was gonna be a tough one. mr. email had fallen in with a rough crowd late in life. pictures of nigerian princes covered the walls. unused S/MIME keys littered the floor. poor guy, once a king, now an afterthought.

"hey! we caught this guy snooping around!" one of the shirts said pushing a punk kid in front of him. "go on & tell 'em your name"

"he doesn't have to," i say, "i'd recognize young mr. orkut anywhere. say... weren't you lost in the amazon jungle or something?"

"amazon? what kind of chump do you take me for, copper?" said the young punk. "i've an honest job down in rio. ask anybody."

"okay orkut. i might just do that. but what with wave and buzz missing in action... you really want me talking to facebook?"

"okay copper, i'll tell ya' what ya wanna know. but i don't know what happened to buzz. i heard he retired with google reader."

that last bit hit like a punch in the gut. i had forgot about reader's "retirement." they say it was her decision, but no one knows for sure. when you can't keep a classy dame like google reader safe on the streets and louts like g+ are running the show rather than cooling the sheets at sun quinten? it stinks, i tell you. like yesterday's session keys.

the coroner finally arrived and started poking around the body. "HOLY SMOKES! HE'S NOT DEAD!" he says.

sure enough, his breath just barely fogs the broken screen of my iPhone 6+. "o'malley! get your guys to clear out the press, we need room to get mr. email to the hearse.. er.. ambulance."

so there i am leaning over the old jake, helping the coroner wrestle him onto a gurney. and then it hits me, his breath smells bad; real bad, the kind of bad you don't get naturally, like a mix of hong kong rot-gut and half refined texas sweet crude. i used to catch a whiff of that smell whenever i went to the talkies cinema off shoreline road. it smelled... like microsoft.

"hey jay," i call to the coroner as he's wheeling email out the door, "while you're down at the hospital, get one of the saw-bones to test the old man for exchange."

"EXCHANGE!?" he cries back, "you don't think he's mixed up with the bellevue mob, do you?"

"i'm not sure, jay. but test him anyway," i answer, "call it a hunch, i think i might have caught wind of a rat."

the rest of the night goes like a million other nights: buried in paperwork and drowned by cheap scotch. and as the sun rises through the acrid smog of silicon valley, i find myself lost in thought mumbling to myself, "microsoft, it can't be you, can it?"

On Internet Enabled Watches

This is a quick post to encapsulate a few thoughts I've been having about SmartWatches. In case you haven't heard, SmartWatches are going to be next year's "break-out hit technology," and have been for the last several years. It shouldn't surprise people I'm a little bearish on the SmartWatch concept as it stands today, but I think it's less to do with the market and more to do with specific limitations of existing technology.

In short, SmartWatches are a neat idea, but they need to hit reasonably low price-points with appropriate performance before we'll start seeing them strapped to everyone's wrists.

The HP-01 Image courtesy Wikimedia Commons

But first a little history... Wrist watches were apparently a thing as far back as Elizabethan England (who knew?) and were worn almost exclusively by women until the early 20th century. Men were apparently big fans of pocket watches in the old days. Which sort of got me thinking... are mobile phones the modern pocket watch? I can't tell you how many people I know who use their phones as watches. In the early 70's digital watches appeared and were almost immediately lampooned by Douglas Adams in the Hitch-Hiker's Guide to the Galaxy.

The first "Smart Watch" I can find reference to is the Hewlett-Packard HP-01. Look at this thing! Is it not a marvel to behold!? Seriously, I was a kid when this thing came out and remember thinking it was the coolest thing since sliced bread and David Cassidy combined.

Users of the HP-01 could use a proto-stylus to enter reverse polish notation programs to run on the device. Tracking fuel consumption on a small airplane was the canonical example the HP folks gave. Every second it would multiply elapsed time by your fuel usage rate and display how much fuel it thought you had in your fuel tanks. I once wrote a program on a HP-01 simulator to display the current mission elapsed time for the Pathfinder rover on Mars. Cool beans if you're tech geek like me, but with a price tag of $650, it's not a mainstream product.

Handspring Treo 300.  From Wikimedia Commons (again)

And for the second bit of history, let's look at the Palm Treo. This bad boy hit the stores in 2002 (though this is a picture of the Treo 300, which didn't come out until 2003.) Wait! Weren't we talking about watches? Why are we looking at a Treo?

The Treo was the first successful PalmOS device that didn't need to be connected to your PC. Sure, the user experience of syncing with networked servers sucked and required additional software. But it was possible and a lot of people did it.

Nike Fuel + Band.
Image from Wikimedia Commons

And now let's look at existing SmartWatches. This is the Nike Fuel. It's one of the new breed of wearable activity trackers targeting fitness peoples. Oh wait. Hold on. Nike couldn't sell enough of these to make it worth their while. Nevermind. (That being said, there was a pretty stiff after-market of these things after Nike axed the project. So it's not like there's zero market.)

And here's the Pebble watch. It seems to be everyone's current favourite, despite offerings from Samsung and the rumoured iWatch waiting to destroy the market with it's Apple flavoured consumer electronics dominance. The pebble comes with "regular" BlueTooth and BlueTooth LE

Pebble. From Wikimedia Commons

(Low Energy) so in theory, you should be able to pair it with your PC or you iPhone. But getting it to pair with your PC requires mad Python hacking skillz.

And don't get me started about the Samsung offerings. Not only do they only pair with smart-phones, they only pair with a couple of different models of Samsung smart-phones. No thank you Samsung. I don't want my SmartWatch purchase to be useless if I drop my SmartPhone in the bathtub.

So what's your point?

Thanks for staying with me as I bounced around between seemingly unrelated bits of consumer electronics footnotes. I guess what I'm trying to say is:

1. These things are still pretty expensive. Nike had a customer base and still couldn't push these things out the door for $150.
2. The experience of using a SmartWatch sucks. Not for us, of course. If you're reading this, you're probably one of the techno-elite who repartitions the logical volume groups on your Linux desktop for fun on the weekend. But if your have to go through the bluetooth pairing dance to get your watch to talk to your phone, you've probably lost half your market.
3. People want to get at their data, they don't care that it's on their PC, on their phone or in the cloud. They want to turn on their phone and pull up a picture of their grand-kids. Or have their watch send fitness / movement data to a program somewhere.

But SmartWatches as a product class aren't a complete bust. That's one of the reasons I threw in the bit about the Treo. You don't see any Treos on the street anymore, but if you look at the iPhone and various Android phones, you see features that were pioneered by Handspring. And I think the SmartWatch market is where the SmartPhone market was thirteen years ago. We've had a few market entrants, but their experience mostly sucks and they're too expensive. Maybe next year we'll see the "Treo" of SmartWatches. Maybe it'll be Pebble releasing a slightly cheaper product with a better user experience.

What makes a better experience?

Users want their devices to "just work." You can probably get away with forcing people to do the BlueTooth pairing dance if you correctly communicate the security and privacy reasons behind pairing. But after that, they want their device to operate with zero additional complexity. What does this mean?

1. For the sake of all that is holy, allow your device to pair with more than one computer. I have a cluster of PCs at the office and a cluster of PCs at the home. I want my SmartWatch to work with all of them. Don't artificially restrict me to only working with one PC.
2. Consider making deals with WiFi Access Point manufacturers to put BlueToothLE support in their firmware. Many modern access points have USB ports and there are several BTLE USB dongles out there. Wouldn't it be simpler if your Access Point provided your BTLE dial-tone? In theory you could have a software component on the access point that relayed application layer messages to local PCs or cloud services.
3. Put as much of the configuration on the big screen as possible. This should be a no-brainer, but we still see people making products that require you to use the small screen on the wearable device. No. Just... No.

Anyway... I hope this has been interesting to someone out in the world. Feel free to drop me comments via email or twitter. Special shout-out to @jonathanstark and @balmer who ignored my twitter-brand snarkiness to have as close to a real conversation as you can have about consumer electronics 140 characters at a time.

the terminals shine

getting ready to start my day, doing a couple little tasks while watching AMC's Halt & Catch Fire in the background. i really love the show; mostly 'cause it's like re-living the microcomputer revolution. kids today don't know what it was like. every month something new and innovative came out. and most of the things that came out withered and died 'cause they were too expensive or the market for the product didn't really exist.

but at the time, that didn't matter too much. it was a crazy time and there were no rules. or rather, people were more willing to creatively bend them. i was on the tech side of the fence in the 80s and was privileged to work on firmware, application programs and even an operating system to compete with MacOS and Microsoft Windows. i wrote a lot of very cool code, but strangely, the only thing that's still in use from back in the day is some code for older ATM machines & a hack i wrote for DOS / Netware.

the common mis-conception of the 80's was sofware was written by lone coders working feverishly through the night. and that's not completely untrue. but there were plenty of small organizations, three or four coders working together to get stuff done. (and remember, this is back when version control was flinging floppies around the room.)

one of my favorite bits of writing from the time is this bit from Geoffrey James:

"The computer center is empty,
Silent except for the whine of the cooling fans.
I walk the rows of CPUs,
My skin prickling with magnetic flux.
I open a door, cold and hard,
And watch the lights dancing on the panels.
A machine without soul, men call it,
But its soul is the sweat of my comrades,
Within it lie the years of our lives,
Disappointment, friendship, sadness, joy,
The algorithmic exaltations,
The long nights filled with thankless toil,
I hear the echoes of sighs and laughter,
And in the darkened offices
The terminals shine like stars." --from The Tao of Programming

on enlightenment

had an amazing dream this morning where i reached enlightenment.

starting out as a visit to my childhood home in ohio, i remarked to myself how it looked different than what i remembered. further investigation revealed portions of it had been taken over as a dormitory by wright state university (apparently it was also much larger than i remember.)

randomly wandering into the downstairs family room, "i" split into multiple individuals representing not only the different parts of myself, but avatars of friends, family and mentors responsible for shaping my personality with Charles Baker playing the role of the friendly trickster and Peg AtKisson carrying a sword, representing my intellect.

my task was to complete (within a fixed amount of time) an introductory multiple choice test and then query 5 (sometimes 6) guardians of the experience of humanity (librarians of the akashic record?) to discover the secret to enlightenment. agriculture, mechanics (tool building), programming, and music/literature were the guardians i remember.

after being confused by a few questions, the part of me that was memory whispered a strategy in my ear. treating it like a logic puzzle, i asked each guardian what i had to ask the others to achieve enlightenment. apparently this was a good strategy, and in retrospect makes me wonder if half of the guardians always told the truth and the others always told lies.

the last couple of answers were unintelligible jibberish, but memory helped me out here and i just repeated the lines fed to me (thanks, mnemeosyne!)

when you reach enlightenment, there's apparently a very nice cocktail party where all the pieces of your psyche mingle, catch up on gossip and generally have a good time. i commented to one of the guardians that i didn't feel especially more enlightened and was told that i'm not the one who was enlightened.

it turns out that the i that i perceive myself to be is not the i that is enlightened. upon attaining enlightenment, every bit of you is enlightened and it's an experience that the conscious ego can't comprehend (maybe that's why it looks like a cocktail party where the rest of my society of mind is having a good time.)

Tom Deplonty will be happy to hear one of his compositions was being performed at the party. So Tom... you're apparently going to pen the soundtrack for enlightenment (no pressure.)

The Persistent Myth of Product

This morning i had to take it a little easy. I burned myself out last night debugging and needed a small break. So i spent a little extra time sipping my coffee, enjoying my garden and reading a random book from my young adulthood. The book i picked up from my bookshelf was Michael Tomcsyk's "The Home Computer Wars." It's a first-hand account of Commodore's rise as a home computing juggernaut in the early 1980's. Written in an informal, first-person style, it's a surprisingly fun read; sort of like a romance novel for tech geeks.

One of the things I noticed about the book was how few rules there were to making "hit computer products" in the early 80's. The market was still developing and everyone seemed to have their pet theories for how to build the next, great thing. The locations involved, Sunnyvale and Santa Clara, made me think of the companies I worked for in the valley; how their approach to structuring a business was straight out of the 80's and how that's probably why they're no longer around.

I'm thinking mostly of PalmSource, the software spin-off of Palm, Inc. PalmSource was structured in a pretty standard way: executive management at the top, different divisions for sales, marketing, operations and engineering. We worked in matrix style teams with product definition the responsibility of the team's product manager. I don't want to dispiarage anyone on the PalmSource team; with very few exceptions everyone involved were highly competent professionals. But in retrospect, I believe PalmSource's organization and rigid responsibilities set it up for failure.

My team was working on the software to secure apps on the device from other, potentially rogue apps. I was happy with the work I was doing, but the software security work I was doing quickly laid bare a sad truth: our product manager had no idea why we were including security features.

People who have implemented security features on products will probably understand how frustrating this can be. Security features frequently do things like pop up dialogue boxes or cause certain types of data accesses to fail. As feature developers, we can dial up the access protection and annoying interactions or we can dial them down. It's not exactly true that good user interface and good security are mutually exclusive, but it's frequently the case (especially in the first rev of a product.)

So as developers, we cheat. We have our software refer to configuration files to say how frequently we should annoy the user and what resources we don't let other programs access. It's great for the software developer, but it's really just kicking the can down the road. Someone, somewhere needs to make a decision about how often you annoy the user. And it's a horrible choice. If you err on the side of caution, people hate your user interface. If you err on the side of convenience, you open yourself up to vulnerabilities.

At PalmSource, we convinced ourselves that our product manager would make these decisions or would be the conduit for customer requirements. But we made a bit of a mistake. Our product manager, while very competent in the general handheld space, had about zero experience with security features and not a whole lot of experience evaluating user experience. And this was the guy who was going to make the decision in the usable vs. secure issue.

I don't blame our product manager. He was a good guy put in a situation outside his area of expertise. It did take him a little longer to recognize this than it should have, but he had a lot on his plate. As engineers, we had no way to report this issue to upper management because our management was actively hostile toward security features. (Seriously, my manager once fell asleep during a meeting when we were trying to explain the problem to him.) We had no authority to make a decision on our own, because PalmSource's corporate culture was "product tells engineering what to build, not the other way around."

In several old-school companies, the product management group is responsible for surveying the market, making educated guesses about economic trends and customer behaviour and developing a target for price and performance. Usually (hopefully) guided by the executive team's directives on ROI and general location in the price / quality matrix, they help engineering prioritize features for the products under development.

But it's increasingly important for product managers to have a deep knowledge of the product features. In the old days when the division between product marketing and engineering was established, products were effectively widgets with five or ten bullet-point features. The "quality" of your product was defined by the presence of a bullet-pointed feature or it's relative feature. Product managers didn't need to know what the features did, only that we had one.

Fast forward to the modern era... The iPhone finally got the term "user experience" on the lips of executives. Just-In-Time manufacturing is the default rather than the exception and various SaaS successes have people talking about how to provide value through an API. Selling software in Sili Valley is less about putting bullet points on boxes and more about adapting your API to fit into someone else's value chain.

So why do we still have product managers that aren't also sales engineers? Why did I, as an engineer, have to explain the business ramifications of poor design choices to our product manager? Why did I have to use back-channels to find engineers in our customer's organizations and ask *them* about their business objectives?

And I think the answer is "the Persistent Myth of Product."

There's a truism in marketing that to make money you can do two things: figure out what people want and make that, or figure out what you're good at making and make people want to buy it. In the early 80's, the vast majority of the populous wasn't familiar with what computers could do. It's safe to say people didn't know what they wanted. Sure, we all thought we wanted a device with more flashy graphics, a better keyboard and more memory. But that's just the "computer fetishist" view of computing products. What we needed to know in the early 80's was how these devices were going to fit into our lives.

And while I like to grouse about Apple's developer support from time to time, it's hard to argue they didn't do an EXCELLENT job communicating how Apple products fit into people's lives. When the Macintosh came out, IBM offered a series of ham-fisted windowing programs to counter the Mac's "ease of use" argument; ditto for Digital Research; ditto for Microsoft. I believe IBM and Microsoft survived because they understood the lucrative enterprise market.

In the early 2000's, Apple struck again with the iPod. It wasn't the first personal audio player, but it was the first to not treat the user interface as a bolt-on afterthought. And Apple did another EXCELLENT job communicating how the iPod fit in a user's life: buy an iPod, take your music with you. By comparison, Diamond and Creative were selling Rios and NOMADs like you would sell a PC component: by listing bullet points on the side of a box.

Traditional product managers are taught to identify key features of a product segment and then communicate those features to an engineering team. They are taught that all you have to do is make a widget slightly cheaper or slightly better and the world will beat a path to your door. And in many segments this is true.

But it's not true in software. Or at least it's not true for organizations that don't want to rely on dumb luck.

"Product" is not defined by a market, but by observing people, figuring out how technology can affect their lives, building it and communicating that change to the end user. Don't depend on an existing market to tell you what to build. Depend on your customer's need first. Or... figure out what you're good at building and figure out how it fits into your customer's life.

A Conservative Justification for Single-Payer Health Insurance

People who know me are sometimes surprised when I describe myself as "conservative on some issues." And to be sure, I'm mostly a raging lefty. But I've always wondered why "conservatives" oppose single payer systems. I believe a single-payer system like Canada's would be a net benefit to the United States and could be justified by "Buckley-esque" conservative ideals.

In the United States the cost of treating acute conditions in the uninsured comes from the public purse. So let's say you don't have health insurance and you're rendered unconscious in a car crash. You're taken to the hospital emergency room and revived. The hospital has already spent money on you before they could determine you couldn't pay for the treatment. So you're stabilized, shown the door and usually, the local county picks up the bill.

That's a bit of a contrived example, but it clearly shows what happens: if someone doesn't have insurance to cover the cost of medical care, it's the state that picks up the tab. Something that's a little more likely is due to some unforeseen circumstance or a previously hidden chronic condition, you need acute care. Maybe it's an accident around the home. Maybe you didn't have cash to pay for an annual colonoscopy and you have abdominal pain from stage 3 colon cancer. Treating a patient for complications due to late term cancer is considerably more expensive than detection and prevention. Put another way, appeals to the public purse are minimized if indigent and low income workers who cannot otherwise afford effective health care are provided with preventative care.

But in this country, we tie health insurance to employment. This made a lot more sense fifty years ago when the cost of health care was lower and employee turnover was lower. Health insurance was originally offered by employees as an incentive, but as costs increased it became more of an expectation. This is bad because employer provided health insurance introduces an artificial attachment to under-productive employment. That is, instead of working the job that best uses your talents or allows you to maximally contribute to economic productivity, you go for the job that offers the best health care.

In my own case, I left a "good job" to pursue an entrepreneurial opportunity. I was lucky I had enough cash to pay for COBRA coverage while my new business venture became a going concern. Other people will not be in this situation. A worker who thinks of a new process or a new invention will be hampered in their pursuit by the cost of health insurance. Minimizing the out-of-pocket expense for entrepreneurs during the initial "start up" phase of their business, gives them more "runway" to go from concept to minimum viable product. Reducing the cost of entrepreneurship increases the incidence of start-ups; increasing the incidence of start-ups increases the likelihood productivity-enhancing intellectual property is delivered to the marketplace.

And from the perspective of a mature enterprise, health care costs are now the single fastest growing expense and the least easy to predict. When I was an entrepreneur, our health care costs doubled every year as benefits went down slightly. The current system benefits large employers with larger risk pools at the expense of small and medium sized enterprises who must deal with unpredictable increases in health care coverage.

Also, the United States has the third highest per-capita health expenditure while enjoying the lowest rate of positive health outcomes of the top 17 industrialized nations. If we could replicate the Canadian model, shifting to a single-payer model would facilitate better negotiation for end consumers and more consistent pricing for health care services and medicines.

This is a just an outline of a real argument, but I think it presents the basics. We're already in a situation where the public pays for some coverage: emergency rooms, medicare, medicaid. Tying insurance coverage to employment encourages under-productive employment and minimizes the United States' competitive stance with respect to productivity-enhancing intellectual property which is frequently developed by small organizations with no stake in existing solutions.

Single-payer health care:

• reduces the per capita cost of health care
• removes barriers to technological innovation
• eliminates disparities between large and small enterprises

How is this not conservative?