<CharlieDigital/> Programming, Politics, and uhh…pineapples


The Future of the Automotive Industry

Posted by Charles Chen

Lately, I've been having a lot of discussion with various folks on my thoughts on the future of the automotive industry.

Within the next 10 years, we will see a huge transformation in the industry and how consumers use cars.

Every manufacturer has announced or is working on some variant of ride sharing and autonomous driving.


Driverless cars could imminently be operating on London's streets, after Nissan announced it had been cleared by the UK government to commence limited trials.

While Google has been testing its own autonomous vehicles on public roads near its Californian headquarters, Nissan claimed that its driverless cars will be the first to hit public roads in Europe—if, that is, the Japanese manufacturer receives final approval from an undisclosed local authority in the UK's capital.

Volvo ride sharing and Drive Me:

DETROIT—Volvo is among the leaders of the pack of automakers when it comes to autonomous driving. The various advanced driver assists in its current XC90 and S90 are some of the best we've tested, and the carmaker recently linked up with Uber to develop redundant systems in self-driving cars. But before there was the Uber collaboration, there was Drive Me, a multiyear research program that the company will use to look at how it, as a car maker, can contribute to a "sustainable society." In the video above, we speak to Trent Victor, senior technical leader of crash avoidance at Volvo, about the program.

Volvo chose this year's North American International Auto Show to hand over the first set of keys in the Drive Me program. It's in the process of recruiting 100 families in Gothenburg, Sweden, but the first lucky family is the Hains. Over the next few years, the Hains and the other participating families will be testing out a number of different research vehicles like the XC90 SUV seen in the video. In addition to testing out new iterations of self-driving systems, the vehicles will also be fitted with sensors and data loggers in the cabin to monitor the occupants.

GM and Lyft, in whom they invested $500m:

General Motors Co. and Lyft Inc. within a year will begin testing a fleet of self-driving Chevrolet Bolt electric taxis on public roads, a move central to the companies’ joint efforts to challenge Silicon Valley giants in the battle to reshape the auto industry.

Cadillac (GM) has started their BOOK program:

A flat monthly fee of $1,500 eliminates the hassles of car ownership so members can experience uninhibited driving. Membership is month-to-month with no long-term commitment required. Members can use a mobile app to reserve vehicles that will be delivered to their specified locations via a white-glove concierge service. Certain location restrictions apply. Members will have access to the current year Platinum Level Trim Cadillacs, including the XT5, CT6, Escalade and V Series. Registration, taxes, insurance and maintenance costs are included in the monthly rate and there is no limit on mileage.

And of course, there is Tesla, Google, Nvidia.

While there has been a lot of skepticism with many whom I've talked to, the reality is that we are at a convergence of technology and engineering that will transform the automotive industry -- and many ancillary industries -- in the next 10 years.  Leaders in the auto industry really deserve some credit given that we've seen industries like music and television wholly unprepared for the transition wrought upon them by technology; by and large it seems clear that the industry can see the shift and have invested in shaping their futures.

This moment is the convergence of computer vision, improvements in mobile computing, and maturity in the field of neural networks and deep learning -- the latter two are now commodities that anyone can take advantage of for pennies on either Amazon or Azure.  As we saw with the shift with enterprise infrastructure once compute became a commodity, so too will we see a shift in the prevalence of "AI" given the advancements and commoditization of these capabilities.

There are powerful business drivers, of course.  From the perspective of companies like Google, it allows them to achieve higher engagement and serve more ads.  It also opens up new models of revenue and advertising; imagine a smart car that can suggest "sponsored" restaurants in the area if you are heading out for a meal.  For companies like GM, Nissan, Volvo, etc., it is an evolve or die scenario as the industry is transformed.

The degree of transformation in this industry will be massive.  The first wave will be an increase in programs like BOOK that will continue the trend of unbinding the need for transportation from the need of ownership.  We are already seeing this with the tremendous growth of Uber and Lyft in the last few years.  BOOK is currently only available for Cadillac's most premium cars with "white glove" concierge services -- and the price reflects that!  However, I think we will see this model move downmarket.

One might fairly ask how this is any different from renting a car.  I think there's one key difference: the model is to "rent" directly through the manufacturer and this is a precursor to an all new model.  In a future when autonomous driving is mainstreamed, these services will reach their full potential whereby manufacturers will sell services directly to consumers.  You won't buy or lease a car, but rather summon an autonomous car from a local hub that will come and transport you for your trip in much the same way that you would hail an Uber ride.  It is this transformation that every manufacturer sees and it is this inevitability that they are prototyping and investing in.

In some sense, Tesla has been at the forefront of some aspects of this model.  Obviously, Autopilot is one of the most competent semi-autonomous driving systems currently on the market.  But beyond that, Tesla has already done away with the traditional dealership model, though it has been as a result of legal challenges from entrenched dealerships.  While Tesla has been fighting these legal battles, traditional manufacturers like GM, Renault-Nissan, Ford, etc. have been sitting on the sidelines, waiting to see the result and observing.  After all, there is no logical reason why Toyota can't sell directly to you except that there is an entrenched model and legal framework that prevents them from doing so.  But they have been preparing, learning, and now experimenting as we see with BOOK.

With the inevitable reduction in car ownership, we can expect quite a bit of fallout across many industries.

For starters, the model of automotive insurance will need to change.  Consumers may carry additional personal injury insurance, but the cost of insurance will be shifted to the service provider in much the same way that the insurance on your Uber ride is the responsibility of the Uber driver.

Automotive dealerships will also need to evolve.  It is likely that we will see dealerships transform into hubs that largely provide service and maintenance as well as a central distribution point (though a fully distributed model is certainly also possible).  Many dealerships will likely go out of business in this process as profitability drops and more competitive options arise for manufacturers.

Used car dealerships and the entire infrastructure supporting that will need to evolve as there will be less buyers of used cars.  The value of used cars themselves may take a large hit as the market of buyers shrinks and the cost of ownership increases.

Municipalities will need to rethink their model of infrastructure planning.  A township in New Jersey just last year piloted a program that reimbursed for Uber rides instead of investing in a new parking lot.  What effect will a new model have on bond commitments related to existing infrastructure?  How will it affect zoning and planning?  Municipalities will also have another challenge: how will autonomous vehicles affect their revenues from traffic violations when these cars will obey posted speed limits and stop at every stop sign and red light?  What happens when no one needs to park at meters because the cars will operate on-demand?  How will they make up this gap in their revenue stream?

Small businesses like car washes and even big businesses like auto parts stores will need to plan for a future where ownership decreases.  It is likely that most will go out of business, but more likely in a time span of 15-20 years.

There will be new industries and new opportunities as well that will transform local businesses.  For example, an autonomous food or parcel delivery vehicle can be configured very differently from any typical vehicle designed to transport humans.  Will we have a need for pizza or takeout delivery drivers when an autonomous vehicle can deliver the food more cost effectively?  It is not likely that a small local restaurant would buy these vehicles, but rather rent them from a vendor that specializes in these vehicles and increase their delivery capacity on demand.

Manufacturers themselves will need to figure out how to shift their business and resource models in a future where the ratio of cars to riders is significantly lower.  How will it affect their current investments in manufacturing facilities?  What about their commitments to their human resources?  What will the effect be on their current real estate investments be?  What types of resources will they need in the future when they transition into not only a manufacturer, but also a service provider?  Or will the model be altogether different and will they spin off the service provider from the manufacturer?  Uber will be redundant when manufacturers can provide the services directly without a middleman much like how streaming has shifted the relationship between content produces and consumers.  Perhaps Uber will become more like a Hulu where it provides a consortia a platform for managing services.  Tesla is already heading down this route.

Maybe a more important question for manufacturers is how will the market shift once ownership is a thing of the past?  Will people still care about brands?  Or will they care more about the purpose?  I need to transport 6 adults.  I need to transport sheets of plywood and drywall.  I want something a bit flashier for my date.  By and large, I think most folks don't care what their Uber driver is driving; rather they care about the class of vehicle: luxury for a high end experience, mini-van or SUV for carrying people and luggage to the airport, typical sedan for lowest cost.  Perhaps we may see the death of a few brands as the market contracts in reaction to this new model.

The fossil fuel industry will also be impacted as transportation models become more efficient (forget about electrification) and less cars are needed to meet the same demand.  For example, we could see lower priced services that allow multiple riders per vehicle based on smart routing.  We could even see models like we see in the airline industry where smart routing will pool and "transfer" riders to maximize efficiency and provide a lower cost service.  Google already has a patent for smart pickup and dropoff locations.  It's not difficult to make the leap that they could more intelligently route pickups and dropoffs to maximize efficient routing of the vehicles matched to demand. "Passenger Charles Chen, please exit the vehicle here.  A blue Prius with license plate 247X3K will be here shortly to continue your trip.  Thank you for using Google Transit; you saved $3.50 and 4000 grams of CO2 by using Google Transit Eco today!  You should arrive at your destination in 15 minutes; you are still on time for your 6:00PM appointment; would you like to stop at Starbucks for coffee first?"

In discussions with skeptics, one argument that comes up is the ownership experience.  There are various aspects of this such as status or pride of ownership (Americans do have a strong history of sentiment attached to their cars) or even conveniences such as keeping your things in your car.  But I think that this, too, will change culturally as a matter of convenience in much the same way that we have shifted on from physical media for music and video.  My 2016 Mazda CX-9 doesn't even come with a CD player.  How did this happen?  After all, there is a deep culture associated with physical media from vinyl to mix tapes even to CD jackets.  The same with books; there is a certain experience associated with reading a physical book that is strongly ingrained into our culture.  Libraries, the smell of books, taking notes and putting dog ears in pages of a book, passing a book down from generation to generation.  And yet, e-books are here to stay despite their limitations and restricted ownership models (Amazon can wipe your account at any time, after all).  The answer is part convenience and how it is enabled by technology; with the availability of always connected devices, the need to even carry digital media around is redundant.  Why do so when you can stream any song, wherever you may be?  I've seen a shift even in flights where airlines are no longer investing in screens on their planes and instead investing in streaming to personal devices.

It is not the extension or progression of a model such as renting a car, as suggested by one of my counterparties, but rather an all new model.  In much the same way, Uber is not an extension of the model of taxis; it entirely disrupts the business model by removing the barrier of medallions and licenses.  Even if you slapped the Uber app on top of existing taxi businesses, it would not be the same model.  Likewise, Airbnb is not an extension of the hotel business model; it is an entirely new model that disrupts the existing business model.  The shift we will see in the automotive industry is not an extension or progression of an existing model, it is a wholly new model which will come to dominate how we consume transportation services.

It will be far more convenient for a generation of consumers who have no interest in maintaining cars.  For parents that are too busy to shuttle their kids around to this practice or that lesson.  For business travelers who need a vehicle all over the country but don't want the hassle of booking rentals.  For restaurants who can rent delivery capacity on demand instead of hiring drivers.  For a generation that will grow up with devices and have no desire to suffer boredom and tediousness when they have a choice.  The spaces that we reserve for parking cars can be used for better purposes.  Townships will not need make heavy capital investments in wasted "dead zones" like parking decks.

I look forward to this future and it will be interesting to observe what other types of fallout we see from this shift in the next decade.


Is Social for the Enterprise Useless?

Posted by Charles Chen

There is a key difference when we look at social networks in our personal lives (Facebook , Twitter, etc.) and professional lives (LinkedIn) and social networks in an enterprise and that key difference is that enterprises are still primarily concerned with getting work done.

I've already given my thoughts on it before: I think enterprise social is more or less useless for most employees in a corporation.

Wired has a good opinion piece on this:

If we sat down and read every email in everyone’s inboxes, took notes in every meeting, lurked in every chat room, and then carefully kept everything up to date, we’d be able to answer questions like, What are all the steps left between now and the next project? Who’s responsible for each step? Which tasks are high priority, and which can wait until later? Where are all the files and conversations needed to do this particular activity?

Or, Why did we decide that thing six months ago that’s affecting what I’m trying to do right now? Heck, What should I be working on right now?

But no one is able to read/note/track/lurk on everything. Even if they could, it’s soul-sucking (at least, it was for me). And this work about work — and the resulting confusion around not knowing what’s expected of us — contributes to disengagement, resulting in billions in lost productivity. Every year.

It seems crazy that 99% of companies lack a single place to track all of this, a definitive source of “truth” about everything they’re working on. Crazier still given that $304 billion will be spent on enterprise software this year, much of it — like enterprise social networks — purporting to solve these problems. The problem with many of these approaches is that they’re just ports of earlier technologies designed for connecting people, not for coordinating work.

Yet there’s a way to work together with less effort, and it requires harnessing the work graph. Whereas a social graph maps people and their relationships, a work graph centers around the work.

I think the bolded is the key; what enterprise needs today isn't necessarily tools to connect people -- there are plenty of those already -- but better tools to coordinate work.  What enterprises need is a way to streamline how work gets done and -- sure -- part of that is connecting the right people, but part of that is being able to then coordinate the effort without introducing too much process friction and overhead.

By and large, most of the teams I work with from Fortune 500 customers and clients as well as tier 1 consulting companies still rely on positively antiquated processes and software to manage coordination of work that are heavily wrought with impedance.  Microsoft Project plans and Excel spreadsheets are some of the absolute worst tools that one could possibly choose for planning, managing, and coordinating modern software projects and yet they are still the bread and butter of many teams (maybe that's why "On average, large IT projects run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted").

I find that most of that is a result of the simple fact that project managers in your typical enterprise project are likely to be more senior folks who moved on up from their prior positions that are somewhat set in their ways and their tools.  Software and how we interact with it has evolved dramatically over the last decade (think about it, Facebook didn't exist 10 years ago) and yet many project managers have not evolved their thinking and how to utilize more fit-for-purpose software for coordinating work; they have stuck to their guns and carry over legacy Excel spreadsheets and Microsoft Project plans that are simply too unwieldy for fast-paced, day-to-day collaborative execution of work.

Just as cloud infrastructure is beginning to shift how enterprises rethink IT infrastructure, will we see a similar shift in how teams coordinate work?  If it comes, I think it will look far less "social".

Thinktastic TeamPoint is one crack at solving this problem of coordinating work by integrating chat with real-time notifications linked to project artifacts (tasks, documents, milestones) to create a real-time, contextual, workstream that allows teams to view progress, broadcast status and in-progress work, as well as provide greater visibility into the overall health of the project.


Has SharePoint Jumped the Shark?

Posted by Charles Chen

I've worked with SharePoint now for some 7 years starting from SharePoint 2007 beta 2 and I've worked with portals and CMS  systems in some form or another since 2003.

Since 2006, most of my domain experience has been in life sciences, but I think that what I've observed applies to most other industries and verticals as well.

So the question is whether SharePoint has jumped the shark?  Is it the second coming of Lotus Notes?  Have businesses soured on it as an enterprise application platform?  Is it a failed vision?  Is it time for your organization to put it out to pasture?

One of my observations in the last two years or so is that increasingly, I have been called upon to defend the choice of building a solution of top of SharePoint (I've even heard audible snickers).  You can see the eyes rolling from certain folks when we mention that our solution at InnovoCommerce is built on top of SharePoint.  The skepticism and questions about scalability soon follow, but it's not unfounded: it's most often based on firsthand experience with the pains of owning and managing SharePoint.  As the saying goes: fool me once, shame on you; fool my twice, shame on me.

Indeed, I think that the popularity and rise of SharePoint has been its own worst enemy in a sense.  As adoption of SharePoint increased with 2007 and 2010 (in part, thanks to the incredible marketing of Microsoft that often oversold the ease and value), organizations rushed to roll it out and make it available to their users.  In many cases, proper governance and information architecture were either an afterthought or poorly thought out from the onset, leading to deployments which were a nightmare to manage and maintain as rogue site collections and sub-sites cropped up like toadstools after an early summer shower.

Now, after one or two upgrade cycles, and maybe half a decade of ownership, organizations are starting to sour on shelling out for another (multi-) million dollar project to upgrade to 2013.

Organizations eventually -- more or less -- run into the same key problems:

Scalability and Performance.

One of the most troublesome byproducts of poor information architecture and planning is a considerable degradation of performance.  SharePoint provides endless ways with which to shoot yourself in the foot with regards to building scalable, performant applications; it's a field of landmines that even experienced SharePoint architects have to navigate carefully on each project as understanding the scale and intended usage patterns of data is key to coming up with a plan to build a system that will scale.  The indiscriminate use of and reliance on item level permissions is a good example of this.  Failure to break up data into manageable scopes is another.  In the case of custom code, bad or lazy coding practices can also have severe consequences in terms of performance.

Fortunately, most performance issues can be managed -- if use cases are well designed and well understood -- through some thoughtful design up front to build an information architecture that will align with how SharePoint is built to scale.  On the custom code side, following guidelines and best practices along with code reviews can help prevent or alleviate many of the most common traps that developers fall into.  For this, experienced, battle-tested SharePoint architects and developers are worth their weight in gold (wink, wink)!

Of course, this feeds well into the next point...


Getting a large SharePoint architecture and deployment right is expensive (getting it wrong, even more so!).  From the cost of the hardware to the cost of the licenses of SharePoint (don't forget Windows Server, SQL Server, etc.) to the cost of the human resources required to plan the infrastructure, gather the requirements, design the architecture, manage the deployment, and offer on-going support.

It is a huge endeavor made all the more challenging when you factor in custom solutions that get built and installed on top of SharePoint and all that entails -- including risk.  Of course, many companies I've worked with have tried hard to minimize these costs through governance policies that severely limit the amount of customizations available -- often requiring several rounds of evaluation, validation, and approvals to get custom solutions installed.

While this does tend to help keep costs down from an ongoing maintenance perspective, I contend that it also severely limits the ROI and utility of SharePoint by crippling it.  Strip away the ability to build sophisticated business solutions on top of SharePoint, and you are left with a very expensive portal; it's like going to Chipotle and getting a rice bowl with only rice in it

In a way you could say that overzealous organizations addressed the cost of risk by squashing creativity and innovation in terms of mapping business processes into powerful solutions in SharePoint; IT simply didn't allow teams to come up with novel, creative, and innovative ways to extract ROI from SharePoint because of fear (I don't blame them!).  Oddly, by limiting SharePoint to basic ECM functionality, I believe that IT organizations simultaneously decreased their own value in terms of delivering real solutions to the business users and creating a justification for the investment in SharePoint -- everyone loses if you just treat SharePoint like a giant file share or a merely a portal.

Planned Obsolescence.

While I'm a huge advocate of SharePoint as an enterprise application platform (it's what I've been doing for years now) and not just a portal, working in the solution and product development side means that I also have an appreciation of the pain and costs associated with planned obsolescence.  You see, every three years or so, Microsoft releases a new version of SharePoint that will eventually "force" you to upgrade.  Perhaps it's a new feature of Office that can only be used with a certain version of SharePoint.  Or it's a critical fix or feature that addresses a key issue of your current deployment.  Or the product simply reaches end-of-life.  Or, from a product development perspective, you are simply forced to upgrade your codebase to capture or keep your customer base that is moving onto a new version.  It's expensive (I could imagine circumstances where migrations could cost as much or more than the original platform itself) and you are kind of forced to do it every few years.

It creates so much impedance and hand-wringing that some companies simply skip the migration and leave little zombie SharePoint deployments sitting around (our own document management portal at InnovoCommerce is still on SharePoint 2007, and we're a SharePoint shop with deep SharePoint experience).

From the product development side, it is a particularly challenging balancing act to decide how to allocate resources and time to upgrading your codebase while still developing capabilities and maintaining support for existing customers who may not move off of their current version of SharePoint for another two or three years (because of the aforementioned issue of cost and time).  When the fundamental architecture of the platform changes so drastically -- as it has with the shift from 2010 to 2013 -- this makes it all the more challenging (and expensive).

Analytics (Or Lack Thereof).

While SharePoint does offer many great features for building dashboards and KPIs, integration with SQL Server Reporting Services, and other reporting capabilities, I find it severely lacking from an analytics perspective.  A good example is that, for a platform that bills document management as one of the key features, you would think it would be simple to see a document access report that shows all documents, the number of times they were accessed, who accessed them, what actions each user took, etc.  You'd like to see it with some basic charts and visualizations that give you a good overview of the data (in an increasingly data driven and yet data saturated world).

Nope.  Instead, to get this type of basic document metrics, you have to build quite a complex solution (especially so given the barely sufficient audit log query APIs).

Another challenge from an analytics perspective is basically complexity.  For any significant deployment, it is a huge challenge to extract data from SharePoint to build sophisticated reports, especially if you follow best practices and segment data into separate site collections and databases not to mention the challenges and pitfalls of working directly against the raw SharePoint databases (practically a must if you plan on doing any serious analytics across your data).

What's the Future?

For many organizations, I can see SharePoint 2010 being their last dip into the SharePoint pool, at least as an IT owned and managed solution.  I believe that the experience that organizations had with owning 2007 and then migrating to 2010 has left a bad taste in the mouths of many IT organizations (not to mention the business sponsors).  Microsoft is making a strong push with Office 365, but many organizations are understandably reluctant to put their data into Microsoft's cloud (or any cloud, for that matter).  Other organizations might opt to migrate onto less costly, open source solutions like Alfresco, Liferay, or perhaps any number of cloud-based platforms including Google (one of our very large pharma customers has already moved their mail systems from Exchange and also use Google Docs).

It will be interesting to see how SharePoint 2013 and the future of SharePoint unfurls given much of the challenges organizations have had with 2007 and 2010.  In life sciences -- and I suspect with many other industries as well -- there has also been a large movement to downsize IT budgets and IT ownership of platforms, making ownership of SharePoint and delivering useful business solutions on top of it an increasingly challenging task.

While SharePoint 2013 is still plenty expensive when you factor in all of the licenses and expertise required to deploy and manage it, I think it addresses many of the key problems with regards to the deployment of custom solutions -- where I think the most business value is realized -- into SharePoint and is a huge leap forward from 2010 (a much bigger gap, in my opinion, than from 2007 to 2010).

At InnovoCommerce, we have yet to see any of our customers move in this direction (but then again, life sciences companies tend to move slowly anyways -- some of our customers are just going live with 2010) so it will be interesting to see how the landscape of enterprise portals and application platforms evolves over the next year or so.

We are increasingly mulling moving more and more of our codebase out of SharePoint as a mechanism for insulating against the cost of upgrade cycles as well as ensuring that our platforms can be deployed, managed, and integrated more readily and preparing ourselves for a future where our customers may be looking the other way when it comes to their enterprise portal and business application platform of choice.



Posted by Charles Chen

Received this from my sister last night:


Filed under: Technology No Comments

TFS – Does It Suck?

Posted by Charles Chen

I'm not sure, but I don't want to find out either.

I'm currently tasked with recommending a new source control platform and a new defect tracking platform as well.

I'm late to this post from March 2010, but Martin Fowler posted an internal ThoughtWorks survey of version control tools:

I conducted the survey from February 23 2010 until March 3 2010 on the ThoughtWorks software development mailing list. I got 99 replies. In the survey I asked everyone to rate a number of version control tools...

...there's a clear cluster around Subversion, git, and Mercurial with high approval and a large amount of responses. It's also clear that there's a big divide in approval between those three, together with Bazaar and Perforce, versus the rest.

The biggest offender?  TFS with a 0% (yes, z-e-r-o) approval from the ThoughtWorks staff.  Scary.

James McKay provides an interesting take on it:

Team Foundation Server advocates claim it’s unfair to compare TFS to other source control tools, since it’s not just source control, but an integrated end-to-end application lifecycle management solution. Comparing TFS to, say, Subversion, is like comparing Microsoft Office to Notepad, so they say.

Now where have I heard something like that before? Oh yes, Lotus Notes:

The main focus for frustration is Notes’s odd way with email, and its unintuitive interface. But to complain about that is to miss the point, says Ben Rose, founder and leader of the UK Notes User Group (www.lnug.org.uk). He’s a Notes administrator, for “a large automotive group”.

It’s regarded by many as an email program, but it’s actually groupware,” Rose explains. “It does do email, and calendaring, but can host discussion forums, and the collaboration can extend to long-distance reporting. It will integrate at the back end with huge systems. It’s extremely powerful.”

The thing is, it wasn’t the detractors who were missing the point. It was the Lotus Notes guys. You see, e-mail is right at the heart of any groupware application. It’s the part of the application that users interact with the most. It’s where usability matters the most. And it’s what Notes got wrong the most.

Is TFS really that bad?  I haven't used it or recommended it (mostly out of concern for cost), but 0% approval?

On a related note, I've been digging into Redmine the last few days to try to examine its suitability for a project that I'm taking over and new products that I'll be bringing online.  I've been really impressed with it, even compared to the excellent Trac.  Compared to Trac, Redmine just feels more well put thought out (i.e. native support for multiple types of source control systems, native sub-projects, so on) and the UI is a bit cleaner and easier to use.  I expect to be blogging about it frequently in the coming months.


Lev Grossman on The Cloud

Posted by Charles Chen

Lev Grossman has an article in Time this week (not available on Time.com) that pretty much hits it on the mark -- at least in my book -- with regards to The Cloud.  I look kind of befuddled when people tell me we should do this or that on The Cloud or how their product is a Cloud solution.

Grossman lays into this in his opening paragraphs:

The best thing about cloud computing is that word: cloud. Telling consumers that their data is in the cloud is like telling a kid his dog has gone to doggie heaven.  There is no doggie heaven, and your data isn't in a cloud.  It's in a windowless, fortress-like data center somewhere in the rural U.S.

Cloud computing is just a buzzword companies use to describe what they're doing when they move data and processing tasks you're used to hosting on your personal computer onto their servers, which you can access via the Internet.  It isn't new; far from it.  It's at least as old as webmail services like Hotmail.  It just didn't have a cool name back then.

Of course, The Cloud has its merits and convenience (for consumer applications) is surely one of those merits as is scalability (for enterprises and businesses); however -- as Grossman argues -- one of the biggest pitfalls of The Cloud is the lack of control over you data.  Grossman continues:

But in some ways, the cloud is a step backward.  It harks back to computing's primordial past, when everything was cloud computing -- dumb terminals connected to central mainframes.

The thing is, I'm not sure I want my computer to be just a device.  Cloud computing goes hand in hand with another trend: the netbookization and iPadization of the PC, with its transformation into a beautifully designed but lobotomized device that relies on an Internet umbilical cord to do most of its actual computing.

As for me, from a development perspective I'm not too caught up in The Cloud hype.  For most purposes, unless you really know that you have a hit on your hands, you can host your applications much, much cheaper on shared hosting for about $10/mo. which is still probably the best way for a small business to get started.  And when you need to scale, well, hopefully, you'll have tons of investment capital at that point, too and you can just port your app to The Cloud.


More Commentary on Windows 8 and HTML5

Posted by Charles Chen

Arstechnica has another feature on the aftermath of the Microsoft's game-changing Windows 8 + HTML5 announcement.

First, a quote:

The lack of broad platform support meant that Silverlight could never quite rival Flash on this front, but it was there, and it worked well on those platforms that were supported. With Internet Explorer 9, however, Silverlight took a back seat. HTML5 became the way forward. If Silverlight were to be used at all, it should only be used for those things that HTML5 couldn't do very well, such as streaming video. For anything else, the message was that developers should use HTML5.

Microsoft did have a point. If you're really wanting to target people on any platform, HTML5 is the way to go. For Web-facing applications that don't have any special needs such as DRM video, HTML5 is the long-term bet.

Excuse the smugness, but I've been saying this from the day Silverlight was released (you know, because it's basically Flash and we all know how everyone loves the Flash website experience...).  It's plain silly to suggest using Silverlight for anything other than an intranet environment where DHTML could do the job.

While Peter Bright opens the article with a discussion of the teeth-gnashing that many Windows platform developers are going through, I -- for one -- could not be happier that we'll finally see HTML5 on the desktop.  I think it's a beautiful thing  Finally: the richness and variety that we've seen in web based applications will manifest on the desktop because the skills and techniques that folks have used for over a decade to build beautiful web applications will now finally translate.

However, I do disagree with a few points that Bright makes:

Where Silverlight programs can deal with buttons, icons, list boxes, tree views, and other interface controls, HTML5 applications must generally deal with boxes of text, with no higher-level concepts to work with.

There are a few points to address here.  The first is that -- obviously -- HTML has buttons and icons (<a class='icon'><img /></a>)  😉  The second is that, to a large degree, deficiencies in the area of higher level UI abstractions in the DHTML world have largely been handled by any number of open-source UI script and widget libraries which provide even better alternatives to those on the Windows native platform.  jsTree is one example of an excellent tree view library that is incredibly rich.  Third, having worked with tree views via DOM and tree views via WinForms and WPF, my personal feeling is that it is many, many times easier to deal with the creation, manipulation, and styling of HTML than it is with Windows forms controls.  And finally, I believe that Bright misses the point of HTML+CSS; it's really not much different from the concepts put forth in WPF and Silverlight: that of applying visual styles to otherwise generic controls.

I also take issue with this assertion from Bright:

Another weak area for HTML5 is tooling. Design and development tools that work with HTML5 are not as developed or as robust as those that exist for Silverlight, making HTML5 development more complicated

Uh....HELLO?!?  The term "HTML5" is a bit misleading as it's really nothing more than HTML4 with some new tags (and some new skills required to take advantage of those new tags).  Why are current HTML tools insufficient?  I'm not getting his point here as HTML development tools have been around for WAAAAAY longer than Silverlight or WPF development tools.

Bright closes the article with more doom-and-gloom and a bit of hope for going back to the good old days of the same-old, same-old:

The prospect of being stuck with HTML5 and JavaScript for their development is encouraging them to jump ship.

The details aren't clear yet, but next time we'll take a look at the pieces of the puzzle we have, and we'll learn why Windows 8 won't be a HTML-driven horror after all.

Apparently the reaction of Windows platform developers to the news that Windows 8 will promote HTML5 and JS as one alternative to building applications for the desktop

Contrary to Bright's doom-and-gloom, I'm fairly optimistic and I really, really, really hope that Microsoft sticks to its guns here.  I can't be the only person who, while working with WPF, longed dearly for a jQuery-esque framework to traverse and manipulate XAML the same way that jQuery enables in web applications.  I can't be the only person who's turned to using the WebBrowser control in Windows applications from time-to-time because it offered the simplest way of handling complex document layouts and, in some cases, interfaces that would require developers to resort to low level drawing of rectangles and custom painting of the UI controls and dozens to hundreds of lines of code that could be accomplished by HTML in a few lines of markup.

As a developer who has worked with DHTML, WinForms, and WPF, I -- for one -- look forward to an HTML5-on-the-desktop future.

PS  — Is it just me, or are MS developers -- generally speaking -- a particularly whiny bunch that can't handle radical shifts in technology or methodology very well because Microsoft and Visual Studio has been holding their hands and enabling their ineptitude for so long?  The comments on that Arstechnica article shows the straight FEAR that this news has instilled in the hearts of those legion developers.  I love it.

A couple of commenters hit it right on the mark:

slogger: If you have a CS degree and you can't functionally use a new language within a couple months, you fail and are worthless. Switching to preferring some sort of JS API is hardly the end of the world.

jaman4dbz: First of all: Man up MS developers. This is why you should pay attention when you get your formal education. If you did you can switch languages easily. The language and libraries should not matter much.

Maybe now all those retarded MS developers can learn some theory, rather than what buttons to hit in their program maker.

deet: Nobody's talking about using HTML to write drivers, for fucksake.

emn13: I've written apps in Silverlight, WPF, and HTML+javascript. They obviously have their own pro's and con's, but this articles' assertion that Silverlight/WPF are more high-level is complete nonsense.

One of the huge problems of WPF/Silverlight is that they're very *low-level*. WPF doesn't have a sane styling system. In fact, styles are implemented as effectively side-effect laden getters+setters. This means it's quite hard to separate the content and behavior from the presentation.

WPF comes with a widely-used grid-based layout scheme (as opposed to HTML's tables). This is nice in some ways since it's easy to precisely specify where something goes on that grid (i.e. it's low-level). It's a terrible pain to use by hand however, since grid-alignment is done by row/column *number*; moving things about generally means renumbering everything.

WPF/Silverlight as general UI-specification language, I'd say: good riddance. And as a special-purpose tool to make particularly intricate, tightly controlled UI's? Well, it's not disappearing, is it; if you want more control but with helpful automatic layout system to do the basics, WPF/Silverlight will still be around.

This comment by bouncing deserves its own shoutout:

Hmm. Peter Bright makes an interesting case.

In fact, a crack team of usability experts, computer science PhD candidates, and Seth Godin impersonators recently compiled an exhaustive list of native apps which are, to any reasonable observer, far superior to web apps:

  • Photoshop
  • Various CAD programs

Although only two native Windows apps that do not suck were ever found, researchers believe the third "non-sucky .exe file" may one day be discovered. Unfortunately, locating the mythical trifectapp has proven a daunting task, as finding it requires digging through tens of thousands of incredibly crappy, hard to use, slow, confusing, mind-numbing, rage-inducing, serial-killer-inspiring "line-of-business" apps that IT managers force their interns to use on their behalf after booting a USB thumb drive flashed with a version of Windows 98 that's compatible with the version of Microsoft's far-superior C++ libraries the IT department develops on.

Perhaps Peter Bright, who wrote this passionate defense of the unnamed third native application which does not suck will tell us as to what, if any, business application is better in native Win32 than HTML 1.0. While he's doing so, a 22 year-old Ruby programmer will create a superior product using "primitive" technologies in exactly 1/100th of the time it takes a team of Certified Win32 Development Professionals to follow a stack trace in Visual Studio.

I'd also like to point out one of the stupidest comments that simply perpetuates this myth that JavaScript is inadequate:

VoodooTrucker: Is JS as mature as C#? No way. In fact its totally painful, which is what I think developers are afraid of. No strong-typing, no obfuscation, no refactoring, no generics, no direct casts, no direct disk access, minimal properties, no LINQ, no IEnumerable, no interfaces, crappy inheritance, crappy dictionaries....

This kind of makes me chuckle a bit as my own perspective has been that as C# has developed from 1.0 to its current iteration, it has taken more and more from JavaScript.  Take collection and dictionary initializers in C#.  Looks familiar?  Because it was already done in JavaScript ages ago.  Trucker's assertions are also completely off.

It's true that because JavaScript is interpreted, there's no obfuscation, but there is typing in JavaScript, you can clearly refactor in JavaScript, you don't need generics in JavaScript because an array can hold anything, you can perform direct casts by creating a new instance of a type (i.e. var five = new Number("5")), no direct disk access is a matter of the platform/runtime rather than the language itself, no IEnumerable is a misnomer because really, you can iterate over anything in JavaScript, crappy dictionaries make me laugh because JavaScript dictionaries are incredibly sexy and flexible.

Filed under: Technology No Comments

I Think It’s Time For An Upgrade

Posted by Charles Chen

Massive droolage:


Courtesy of engadget.

Filed under: Technology No Comments

And I Thought My Setup Was Badass…

Posted by Charles Chen

Excessive? Maybe.

Badass? Most definitely.

Now I'd be way more impressed if those monitors were 30-inchers.



Posted by Charles Chen

That's gotta hurt:

Windows Vista is Windows ME
Part 2. It took five years to develop because three of those were spent
building a brand new code base that didn't work at all and wound up
getting scrapped, and the remaining two were spent just tweaking the XP
code base. Almost all the features we were promised early on were
discarded and what we end up with is a warmed over Windows XP that
doesn't even do us the dignity of working properly out of the box. I
think it's particularly telling that they've already announced the next
major Windows release for late 2009.

From NotebookReview.com.

Filed under: Technology No Comments