Ben Shoemate's Notebook

You probably have never heard of Dieter Rams (pictured at left) but certainly know of his work. For many years he was a product designer for Braun and other German companies. Back before Frog and Apple put the "i" in many of its products Braun was selling very elegant items that were well designed, such as calculators, shavers and household appliances. Many of these items can be found in museum collections all over the world today. Rams has had several design shows over the years and is known for his ten principles of "good design," and I thought if we substitute the word "code" for "design" that there is a lot software developers could learn from his principles too. Here they are, with some of my comments.

Sponsor

1. Good code is innovative.
 One of the exciting things about working in the tech industry is that we still have plenty of innovation each and every day. And the best coding takes advantage of this innovation and wows us.

2. Good code makes an app useful
. This seems fairly obvious. We buy or download apps to use them, just like products. But the best apps carry code that can showcase their use and avoid distractions.
3. Good code is aesthetic.
 Some IDEs can turn code into quite elegant arrangements that could almost hang on your wall, they are so attractive. But understanding the aesthetic of what your code does is also important. In the design world, aesthetic is very important because it is reflected in the products we use. Just look at the crowds inside your average Apple store and how things are laid out, and contrast that with the aesthetic, if you can find it, in your average Best Buy. No comparison.
4. Good code helps us to understand an app. And bad code helps us to see a badly designed app too.
   
   Things which are different in order simply to be different are seldom better, but that which is made to better is almost always different.

   
   - Dieter Rams, 1993

   
   
5. Good code is unobtrusive. Perhaps this talks more about the resulting UI than the actual code itself. But it could also refer to the ability to easily read someone else's code too. Certainly this is the case for open software.
6. Good code is honest
. No tricks, no hidden trap doors, no malware needed. And no false advertising either: the code is the core essence of an app, nothing more, nothing less.
7. Good code is long-lasting.
 Some of the best software programs have been around for decades. They don't go out of style, just like well-designed products.
8. Good code is thorough, down to the last detail
 Squash those bugs! Find those corner cases! Test and retest with different browsers and environments. Don't leave anything to chance.
9. Good code is concerned with the environment.
 Again, somewhat obvious.
10. Good code is as little code as possible. Sadly, we have moved away from this tenet over the years, look how bloated our operating systems have gotten. I remember the early days when APL was considered the ultimate in coding - a single line could pack a ton of programming horsepower. You needed a special keyboard to code in it:
    
If you want to see some of Ram's work, go here. Discuss

Kevin Kelly wrote a thought-provoking post about how "the impossible" is happening more often nowadays, thanks in no small part to large scale collaboration over the Internet. In other words, the hive mind. He cites eBay and Wikipedia as two examples of things he would've thought impossible in decades past.

Collaboration over the Web is still evolving. One way it might be immediately improved is by adding more women to collective intelligence projects and by shutting up the loud mouths. I'm not idly speculating here, those were the findings of a recent study by MIT's Center for Collective Intelligence.

Sponsor

The study found that collective intelligence is not as dependent on individual intelligence as first thought. Having more women in a group improves the collective intelligence, because it raises the level of "social sensitivity." Another important factor is letting everyone talk equally, rather than having the loudest or most opinionated people dominate the conversation.

Back to what Kelly wrote. He posits that more previously impossible things will emerge thanks to "large-scale collaboration, or immense collections of information, or global structures, or gigantic real-time social interactions." He continues:

"Just as a tissue is a new, bigger level of organization for a bunch of individual cells, these new social structures are a new bigger level for individual humans. And in both cases the new level breeds emergence. New behaviors emerge from the new level that were impossible at the lower level. Tissue can do things that cells can't. The collectivist organizations of wikipedia, Linux, the web can do things that industrialized humans could not."

This thinking dovetails nicely with the MIT report. Carnegie Mellon's Anita Woolley explains the findings more in this video:

The implications of all of this for any company doing online business is clear: optimizing groups with more women and more democratic discussion is just as important as casting your crowdsourcing net far and wide. As Aaron Saenz at Singularity Hub put it: "With enough research the crowds of tomorrow may be optimized for the best possible amounts of collective intelligence. Not just huge amounts of thought-power, but efficiently organized huge amounts of thought-power."

It's also something that tech conference organizers should bear in mind. I for one could do with less loud, opinionated people dominating group discussions - as often those people are the least thoughtful.

Kevin Kelly concludes that "humanity is migrating towards its hive mind." Whether or not you agree with that somewhat extreme position, collective intelligence will continue to be a big driver of Web innovation. We just need more women and less loud mouths, don't you think?

Photo credit: I Love Milwaukee

Discuss

Google's quest to organize the world's information will no longer include one of society's most important and sensitive sources of data: our health records. The company announced this afternoon that Google Health will be closed forever and deleted in 18 months, along with a thematically similar and also formerly ambitious project, Google Power Meter.

Google says it's shutting down the projects because they got very little traction but health industry tech innovators say that Google Health may have been ahead of its time, did a poor job reaching out to a now growing ecosystem of developers and ought to be put on slow life support or open sourced instead of being shut down. When it comes to patient-centric cloud-based electronic health records, the opportunity remains large, the need severe but the challenges are substantial.

Sponsor

When Google Health launched just over 3 years ago, ReadWriteWeb's founding Editor Richard MacManus called it decent and a good start, but short on advanced functionality or integration with the existing healthcare system. MacManus called Health 2.0 game-changing (and potentially hugely profitable) but said that Google Health fell far short of its potential relative to the market it was targeting. All of those things remained too true throughout the life of the project.

What it Means to Lose Google Health

Medical information heavy-hitter John D. Halamka MD says Google Health was a real trailblazer in its time. Dr. Halamka is the Chief Information Officer (CIO) of Boston's Beth Israel Deaconess Medical Center, the CIO and Dean for Technology at Harvard Medical School, the Chairman of the New England Health Electronic Data Interchange Network (NEHEN), CEO of MA-SHARE (the Regional Health Information Organization), Chair of the US Healthcare Information Technology Standards Panel (HITSP) and a practicing Emergency Physician.

"Google Health is truly innovative and broke new ground when it created interfaces to hospitals, labs, and pharmacies in 2008," Halamka wrote today on his blog. "I was there at the beginning and can definitively state that it was Google's reputation and vision that broke down the political barriers keeping data from patients...Google Health [still] has the best user interface, feature set, and ease of use of all the stand alone personal health records." (It should be noted that Israel Deaconess Medical, one of Dr. Halamka's employers, was one of Google Health's launch partners.)

Halamka says Google Health "really moved the industry" but other observers express disappointment that the project barely got out of the starting gate.

"It will take someone the size of Google and not in the health space to create something that's more standardized in the health space, where everything is so proprietary and money driven," says Shwen Gwee, founder of the blog Med 2.0.

"Unfortunately, it's always been Google's philosophy to fail fast and cut off the arm that isn't doing any work. Early adopters were interested in using Google Health, but it took too long to move. I wonder what would happen if they launched it now, with everything that's coming out around open and standardized data. I wish they would donate the platform, open source it, issue a challenge or something, and see what others could do with it."

The request that the Google Health platform be open sourced is something we heard from multiple industry players. People feel burned by the loss of a big opportunity due to the impatience of a big, slow company.

"Google is cutting and running too early from Google Health..in the long term I believe this to be a big mistake," says Mark Scrimshire, co-founder of the HealthCamp Foundation, an organization that puts on events around the world to hack on the future of healthcare.

"Health was always a long term play. An industry mired in regulation and conservative approaches, things were never going to change quickly. However, momentum is building. We are [now] seeing a tremendous uptick in innovations that make use of Government Health Data [for example].

"Personally, I still use Google Health on a daily basis. My Fitbit and numerous other health related data sources feed in to Google Health and pass data out to other services like Keas.com [a workplace wellness program]. I recently moved my Pharmacy because I could have my data automatically piped in to Google Health.

Right: HealthCamp's Mr. Scrimshire, before and after using Google Health.

"Google Health - what we call an untethered Personal Health Record - was NOT a destination in and of itself. Instead it was more useful as a conduit through which we could channel our health data.

"As Meaningful Use requirements kick in as a result of the implementation of the Affordable Care Act we can expect to see Patient Portals popping up like daisies and consequently a growing need to provide a place that Patients can bring together all these disparate data sources in order to get a comprehensive view of their Health. It is not happening yet, but expect to see changes happening in 2012 and people starting to look for solutions to help them get their arms around their health data. The problem for Google will be that by cutting and running now who will trust them in the future if they decide to come back to the table?"

A spokesperson for Google declined an offer to respond to any of the issues raised in this article prior to publication, saying the company preferred that its announcement today speak for itself.

Why Did Google Health Fail to Gain More Traction?

There are many different theories about why Google Health didn't grow faster.

Dave Chase, founder of Microsoft's health business and now CEO at a startup that overlaps with Google Health, offers a number of explanations for Google's health stumble. The most interesting was the company's failure to work with more doctors:

"As much as there's a massive consumer-empowerment movement, in order to get ongoing and broad adoption of something in healthcare, one needs to lead with the clinicians. Take a look at ZocDoc, for example. They are having success with appointment scheduling by leading with doctors/dentists who then, in turn, bring in their patients. Without provider adoption first, they would have had limited success with consumers."

Matthew Holt, Co-Chair of the organization the Health 2.0 Network says he thinks insurance companies were in part to blame. "Google became disappointed when they found out how hard it was to get Insurance agencies to share their data voluntarily," Holt says. "They made some progress but not enough."

The most common critique we heard though was of Google Health's work with tech developers.

Healthcare blogger Faisal Qureshi said on Twitter this afternoon, "Google Health failed at not reaching out to vertical developers, Android fixation & not learning how MSFT partners."

Brian Ahier, a hospital IT evangelist in Oregon echos that sentiment:

"While Microsoft has assembled a list of companies that make products (glucometers, blood pressure monitors, etc.) and offered software that pulls in data from hospitals and labs, compatible with their HealthVault product, Google has made little to no headway in this area.

"I remember a few years back Google did fairly well when compared to Microsoft but HealthVault has continued to mature and Google has been stalled for some time."

Ahier says that Google's decision to pull the plug on Google Health will ultimately be a bad thing for the whole industry.

We spoke to a number of people who agreed that Google launched a stronger health data product than Microsoft, but that Microsoft's HealthVault has since surpassed Google Health.

"The problem with Google Health is that it offers no incentive to use it, it positioned itself as a data repository and not much else," says Brian Dolan, Editor of MobileHealthNews. "Some of the other consumer apps and devices are filling the gaps and they have their own back end systems and APIs, they're all sharing with each other. These other sticky consumer health apps are driving uptake and driving adoptions."

One of those startups and a platform in-and-of itself is Boston-based fitness tracking service Runkeeper. Founder Jason Jacobs says of Google Health's closure,

"Sensors are starting to proliferate across categories, but someone still needs to tie this data together and provide the users a holistic view. Google's vision for data aggregation and the good that can come from it was right, but data aggregation isn't the only piece, the consumer-facing system that people love has to be there. And that is the hardest part.

"Google was a pioneer in many ways with Google Health, and helped turn people on to the need to solve the problem of health data fragmentation. While they may not have achieved the consumer adoption they were hoping for, someone is going to crack the consumer nut in health in a Facebook-like way, and the world will be better off for it."

Or, as RunKeeper's @HealthGraphAPI Twitter account said upon learning the news, "Don't worry folks, we'll take it from here..."

Surely someone will take it from here, right?

Discuss

The recent security breach at Citibank, coupled with even RSA hiring what may be its first Chief Security Officer Edward Schwartz, point out that you can never be too paranoid about your personal and corporate data security. RSA was in the news earlier this year for an attach on its SecurID two-factor tokens, something that had been considered the ultimate in enterprise security.

It might be time to take another look at two-factor authentication, and see if it makes sense to implement this in your organization. Here are three basic steps to get started:

Sponsor

First, take a look at what Google and Facebook have done with adding two-factor authentication to their accounts. Both use somewhat similar systems, tying your account to your cell phone and sending you a text message that you have to enter as part of your login process. Google adopted two-factor authentication last fall and Facebook added two-factor to their accounts in May. And eBay/PayPal have had two-factor authentication for several years on its accounts, too. While these are all personal solutions, they help gain experience in using these two-factor solutions and give you some perspective before you want to implement these corporate-wide.

Second, look at adding two-factor security to two of your most common entry points: email and VPN access. Both will mean some end-user training and will require some effort to implement, but there are a wide variety of solutions.

In addition to RSA, there are several other two-factor authentication token vendors, some that use texting to phones and some that offer their own hardware or software-based tokens.

• PhoneFactor has a similar system to Google and Facebook, texting codes to your cell phone. They can secure a wide variety of systems, including VPNs, Outlook Web Access and others, and offer a free version for up to 25 users. For larger populations, they also will credit you $15 per each RSA SecurID token towards any new deployment.
  
• Digital Persona offers both SMB and enterprise versions of their software that can use a wide variety of tokens and methods for two-factor authentication, set up whole disk encryption, and other security measures. They also offer a free trial. Here is an example of their administrative console.
  

Symantec/Verisign offers a variety of user authentication solutions here, including tokens similar to SecurID.They have a free 30-day trial as well as a free credential you can download to your smartphone. And they also will rebate $5 for every RSA token or credential replaced with their VIP Authentication Service until September 30, 2011.

Yubico's Yubikey offers USB-key tokens starting at $25, along with keys that come with the Verisign credentials built-in.

SecureAuth Identity Enforcement Program has a similar product to SecurID and offers a quick start promotion running until September for $10 per user per year.

VMware's Horizon App Manager has taken software from its Tricipher acquisition and is using two-factor authentication to secure cloud-based apps.

Finally, if you still need convincing, re-read our story that covers some options from Forrester Research here. If you haven't yet started on any of these strategies, pick one and get going. Any action is better than nothing.

Discuss