It's Not About The Features

According to GlobalLogic’s CTO, Dr. Jim Walsh, Tesla vehicles are the epitome of platform-based systems, which prioritize the ability to change and adapt on a continuous basis.

Categories: PerspectiveAgileAutomotive

I bought a Tesla a little less than 2 months ago. My wife, who I think would admit to being a competitive person, responded by updating her preferred brand of Japanese sedan to their latest-and-greatest high-tech model this past weekend. While her car cost only a fraction of a Tesla, it was surprisingly close in features. And, while it is not electric, her car even has some features that my much more expensive car lacks.

Like the Tesla, her new car has adaptive cruise control, lane-keeping, low-speed follow, collision avoidance, and other advanced self-driving features. Both cars are quiet, comfortable, have great sound systems, leather-like seats, touchscreen interfaces, and lots of trunk space. Doing the Tesla one better, her car also adds a heads-up display and quite a few more cup holders than mine.

There are, however, some tip-offs that the design philosophies of the two cars are quite different.

Her car has many purpose-specific buttons: one to turn on the music, another to adjust the volume, a set for heating controls, and so on. There are also some specific-purpose mechanical gauges and displays. The Tesla has no mechanical displays and very few purpose-specific buttons; there’s basically a large touchscreen. Most controls—even to unlock the doors—are “soft,” just like on a tablet.

While her car does offer occasional over-the-air updates, the Tesla updates seem to be a regular event, and the changes can be significant—not just tweaks and map changes. For example, there was recently a major UI redesign that completely altered the “look and feel” of most of the major controls of the car—even such fundamental controls as air conditioning. Like with a major smartphone update, I liked some of the changes and not others. It was quite a bit different than the layout I’d just started getting used to.

This morning, I got another big surprise: Last night while I slept, Tesla added a “navigate on autopilot” feature to my car that adds significant additional self-driving capabilities. This new feature allows the car to not only “stay within the lanes” on the freeway, but also to enter and exit the freeway, change lanes, and change directions—all based on the final destination I give it. It still requires driver confirmation (at the moment) before it actually makes these direction changes, but the car is now able to take me where I want to go without my hands-on management, just my overall supervision. Also, not incidentally, this same update fixed the most significant things that I (and I suppose many other people) did not like about the recent UX update.

It’s like I got a new car—again.

As I was driving to work this morning—or, as I should probably say, being driven to work this morning—I thought about how this situation perfectly illustrates the power of a platform software architecture.

From a software standpoint, the Tesla was clearly conceived of as a platform that supports transportation. New software applications on that platform can be changed and deployed rapidly. My wife’s car, on the other hand, was thought of as a single-purpose system—specifically, a car—and not as a platform. In my wife’s new car, the button that turns the audio on and off will still turn the audio on and off years from now. Likewise, the mechanical speedometer will still be the speedometer. That’s all they do — and all they are ever going to do.

In contrast to a single-purpose system that focuses on delivery of specific one-off, “hard coded” features, a software platform prioritizes the ability to change and adapt. In other words, a platform’s primary purpose is to enable improvements. This emphasis on flexibility over perfection reflects a philosophy of “Kaizen,” or “continuous improvement.” In this approach, you aim to make something better than it was before, as opposed to trying to make it perfect. Ultimately, of course, we get closer and closer to perfection in this way.

The modern “Agile” paradigm for software development also has, at heart, the realization that “things will change.” This is inspired by a more negative spin than Kaizen, namely: even if it’s great today, it’ll be an antique soon. In both Kaizen and Agile, the strong recognition is that building for change is essential—both to support improvements and to avoid obsolescence. A platform approach is first and foremost a means to do this. A platform is what allows you to “embrace change” and make it work for you. A single-purpose system, by contrast, tends to be a “what you see is all you get” proposition.

While a platform approach does prepare you for change, it comes at a cost. A platform approach is almost always more expensive to develop than a single-purpose application. Platforms also generally cause you to deploy a less feature-rich system than you’d like—at least initially. Of course, as time goes on, your ability to rapidly deploy new features enables you to blow past a purpose-built system and deliver feature-richness and the ability to keep growing. On day one, though, you will likely have fewer features deployed in a platform approach than you would with a same-cost single-purpose system.

In many business situations, the ability to rapidly and cheaply add or change features delivers more business value than a difficult to change, feature-rich product. Companies with feature-rich but fragile code bases are common, and they are under threat by more nimble competitors who can move quickly. In human evolution, it was our adaptability as a species that led to our success. Likewise, the nimbler software platform and company is often the winner. While it is not always the case, the software that aggressively moves forward will often beat the one standing still.

My wife’s car was less expensive, in part, because it is single-purpose. Her car will have the same capabilities in a few years as it does today. And even if she and I were at near feature parity when she bought her new car last weekend, my Tesla has already pulled ahead in the feature comparison. She’s owned her car for less than a week.

Because I chose to buy into a platform, I can’t even imagine what its capabilities will be several years from now. I only know that it will be better tomorrow than it was today—and it will keep on going.

I guess I’m a bit competitive myself.

Author

Jim-Blog-1-1_4589994_6850804

Author

Dr. Jim Walsh

CTO

View all Articles

Top Insights

Best practices for selecting a software engineering partner

Best practices for selecting a software engineering partner

SecurityDigital TransformationDevOpsCloudMedia
7 RETAIL TRENDS POWERED BY MOBILE

7 RETAIL TRENDS POWERED BY MOBILE

MobilityConsumer and RetailMedia
My Intro to the Amazing Partnership Between the US Paralympics and the Telecom Industry

My Intro to the Amazing Partnership Between the...

Experience DesignPerspectiveCommunicationsMediaTechnology
Adaptive and Intuitive Design: Disrupting Sports Broadcasting

Adaptive and Intuitive Design: Disrupting Sports Broadcasting

Experience DesignSecurityMobilityDigital TransformationCloudBig Data & AnalyticsMedia

Top Authors

Sandeep Gill

Sandeep Gill

Consultant

Apurva Chaturvedi

Apurva Chaturvedi

Senior Manager

Neha Kukreja

Neha Kukreja

Consultant

Yuriy Yuzifovich

Yuriy Yuzifovich

Chief Technology Officer, AI

Blog Categories

  • URL copied!