Choosing Between Schedule, Budget, Scope, and Quality

Yaacov Apelbaum-Choosing Between Options

Argumentum ad populum is that the best way to beat your competitor is to one-up him. If he has 2 features, you need 3 (4 would be even better). If he is budgeting 1 x $  on his solution, you need to spend 2 x $.

This arms race style upmanship is a dead-end. It’s a prohibitively expensive, reactionary, and is a schizophrenic paranoid way of developing software. Organizations following this philosophy can’t plan for the future, they can only react to the past. They don’t lead by innovation, they follow by imitation. If you want to rapidly build a leading solution and not merely mimic existing products, you need to focus on innovation and quality.

The traditional Project Management iron triangle model proposes that every project is controlled by these four elements:

  1. Schedule
  2. Budget
  3. Scope (features and Functionality)
  4. Quality

Yaacov Apelbaum - Iron Triangle of Project Management

Illustration 1. The PM Iron Triangle

Some project managers believe that you can only pick three out of the four variables. I don’t agree, because quality should never be compromised. Would you buy a new car knowing that it has a defective engine or transmission? Most likely not, regardless of how many other features it has or if it shipped on time to the dealer. Quality is not a variable and is a ‘given’, and as such, it should always be baked into the the product.

I’ve seen numerous projects who compromised on quality by reducing unit test coverage and then engaging in creative bug severity reclassification, just to catch up with a slipping shipping date. In the end, no amount of Bondo and marketing spin can cover up the quality holes in your delivery.  Still not convinced, check out the annals of software development screw-ups, they are full of product humdingers that shipped on time, on budget, and scope, but failed miserably because of substandard quality.

So what do you do when the going gets tough? How do you make that difficult decision and chose the right sacrifice for the greater good? And while at it, what is the greater good anyway?

In this posting, I’ll share with you a few insights into selecting the lesser of two evils, and some specific project hostage negotiation techniques that may help you get out of some tight delivery spots.

The Project Web
On the surface, each of the four options from the list above seems to be equally weighted, but in reality, It’s not as simple. In a dynamic living and breathing software project, the schedule, budget, and scope actually carry different degree of importance and impact each other in subtle ways.

Yaacov Apelbaum-Choosing Between Options Pyramid

Illustration 2. The Project pyramid

It turns out that rather than a interwoven triangular knot that is made up of equal sides that can be resized and traded equally, the project elements actually resemble an intricate spider web (illustration 3). This structure in turn is controlled by many variant and dynamic factors. As you apply force (i.e. poll or push) to any strand in this web, the whole web flexes and deforms unevenly in multiple axis.  Each change you apply to the project (adding scope, increasing the budget, etc.) will ripple through the entire project structure like a pebble dropped in a pond.

Yaacov Apelbaum-Project Option Grid

Illustration 3. The Project Element Web

As you can see in Illustration 4, increasing the budget and decreasing the schedule will adversely impact the schedule, scope and quality. This action will also disproportionally deform all project axis and introduce a negative self-reinforcing feedback loop. This is because the team will now need to quickly add more development resources to complete the additional work, this will result investing less time on actual development on more time on knowledge transfer, which will introduce more bugs, which will ultimately result in a reduction of the overall quality of the software.

Yaacov Apelbaum-Project Options Budget Increase Schedule Decrease

Illustration 4. The Project Element Web – Impact of Budget Increase and Schedule Decrease

This is counter-intuitive to popular wisdom which states that increasing the budget for the project can allow you to complete the work faster with more functionality.

The Project Annihilator Shooter
Software product development lifecycle is in many ways similar to a shooter video game. You play each scenes collecting, oxygen, ammunition, and kill points. If you are successful and survive enough missions without losing your vitals (i.e. reputation, stamina, leadership, etc.), you get to move to the next level and play again. If you run out of ammunition, oxygen, or your life gauge falls below some critical level, you’re out of the game.

The Project Annihilator Dashboard

Following this corollary, your ability to continue to play the software development equivalent of Metro: Last Light, depends on your ability to juggle all the elements that go into your software project.

The following are your variables:

Ammunition/Oxygen = Funding/Budget
Scene Length = Schedule and drop timeline
Number of Targets per Scene= Number of Features of your project

Here’s an easy way to launch on time and on budget: keep features minimal and fixed. Never throw more time or money at a problem, just scale back the scope. There’s a myth that states that: you can launch on time, on budget, and on scope, while keeping quality in check. Well, it’s nonsense, it never happens, and when you try, quality always takes a hit.

If you can’t fit everything in within the allotted time and budget then don’t expand the time and budget. Instead, scale back the scope. You will always have time to add more content later–later is eternal, now is short-lived. Launching early a product that’s smaller is better than launching a solution that is full of bugs just because of some magical date. Leave the magic to Siegfried, Roy and, their tigers. Your customer will judge you on how well your features work, not on how many of them you’ve delivered.

Still not convinced, here are some more benefits of fixing time and budget, and keeping scope flexible:

Keep Scope Real and Relevant
Less is more. Less code, less documentation, less regression testing. Remove all but the essentials. Trust me, most of what you think is essential is actually not. Keep your solution small and agile.

Use rapid iterations to lower the cost of change. And believe me, if you plan to deliver a functional product and are soliciting your users for input, there is going to be a lot of change. Launch frequently, tweak, launch again, constantly improving your solution will help you deliver just what customers need and eliminates anything they don’t.

Breakdown Delivery to Phases and Prioritize Content 
This is an important exercise to go through regardless of project constrains. You have to figure out what’s important for your customer and how you can deliver the most critical functionality in multiple phases. Not being tied to a single monolithic delivery will force you to make some tough decisions, but will also eliminate the need to prostrate yourself in front of the war console.

It may sound corny, but having a portion of a working product in the customer’s machine is by far better than having a full poorly functional solution on your build server.

Be Flexible
The ability to quickly change is paramount for your success. Having the scope, budget, and schedule fixed makes it tough to change. Injecting scope flexibility will allow you to be opportunistic in resolving technology and operational unknowns.

Remember, flexibility is your friend. so de-scope, reduce features, and break your monolithic delivery plan to smaller drops. In the end, there is no escaping the proverbial SDLC grim ripper and the fact that you will have to fold. The sooner you show your cards, the better you’ll be in the long run.

Dump the Ballast
Delivering less content will allow you to reduce all the fluff that represents managing upwards (i.e. lengthy Power Point presentations, the fictional development progress reports, etc.) and force you to focus on building the real McCoy.

In larger organizations, weeks can be spent on planning roadmaps and arguing about the fine details of each feature with the goal of everyone reaching consensus on what would be the ‘best’  solution.

That may be the right approach for a $$$ mainframe product, but if you are developing in internet time, fast quality shipping is the way to go. You can always trust the user to tell you if your scope is sufficient. If it’s not, you can always fix it in the next phase and re-ship it again.

When it comes to scope, there is no judgment better than that of the customer’s–resist the urge to engage in long-winded scheduling and planning and especially stay away from:

  • Senseless hundreds of page of slide ware roadmaps
  • Schedules that depend on a multi–year project plans
  • Pristine roadmaps that predict the future (in terms of market and customer needs)
  • Pie-in-the-sky solutions (technology that is immature or non-existing)
  • Reliance on never-ending status/staff meetings and project reviews
  • Dependency on hiring dozens of new resources in order to meet the current increase in scope
  • Endless version, branching, and integration debates

To succeed in building competitive software, you don’t need an excessive budget, a large team, or a long development cycle. You just need to simplify your solution and deliver it to the customer as fast as possible with the highest quality.

Or as Steve Jobs said it “That’s been one of my mantras – focus and simplicity. Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end once you get there, you can move mountains”.

© Copyright 2013 Yaacov Apelbaum. All Rights Reserved.

To Make Errors is Human, to Handle Them is Divine

Yaacov Apelbaum-We Have Bugs

Reading this advertisement made me realize just how clever the software industry has become.  Why bother fixing your bugs prior to shipment when you can sell it on the premise that you will fix the bugs “free of charge” when the users find them for you. Interestingly, anyone who bothered to read their licensing guide will find the following sobering caveat:

“…From an engineering point of view, it is impossible to fix bugs in multiple source code branches. If we would have to do this, we would never be able to implement a major redesign. Major redesigns are required now and then to be able to fix bugs and add features fast.” 

Nothing communicates your attitude towards your users better than the way you handle exceptions and errors. As soon as something goes wrong with your application the user is at a heightened emotional state and is the most impressionable. Some software products, including some of leading market applications, have developed a bad reputations for having cryptic error messages that are impossible to resolve, leaving the user feeling helpless and outraged.

The worst offenders include fortune teller style messages that inform you (not without irony) that you are about to lose all of your work because the application has encountered an unknown problem and needs to shot down.

Yaacov Apelbaum-Useless Error Message
A Useless Error Message

This is even more pronounced in the session-less environment of the internet. It seems that when it comes to web application reliability and robustness, we’ve been steadily taking a step backward in the way we treat our users.

Yaacov Apelbaum-Lost my Browser Yaacov Apelbaum-Stopped Working

Yaacov Apelbaum-Blogger Error Yaacov Apelbaum-Microsft Live Writer Error
Useless Error Messages

The Engineering Handling Failure
A civil engineer designing a bridge will invest a significant amount of time and resources in predicting potential structural failure scenarios. Failure analysis and safety factoring (i.e. redundancy) are two important cornerstones of the engineering discipline. In the physical world of machines and structures, the ability to identify a potential design flaw and remedy it is a given. Similarly, we should strive to achieve the same in the virtual software world by accounting for critical error conditions and developing robust application code capable of handling those cases.

Software engineering does have certain nuances that differ from classical engineering, which makes prioritization of work more arbitrary and less straightforward. For example, a memory leak in a server component may be considered by the development team to be a critical bug, but a relatively small data validation problem that forces the user to retype a lengthy application could have a bigger user impact and rank higher on the bug fix priority.

A 12 Step Program for Error Rehabilitation
Making your application more agile in handling failure and enabling it to degrade gracefully are not a single step processes and there is no silver bullet technology out there that will fix this problem.  If you want to break the cycle of application instability and user frustration, you will have to dedicate time and your best technical talent to solving it. I have found that a phased approach works best.  In this approach you first handle the low hanging fruits, (addressing the mechanics of the error handling), and than gradually move to higher ground (addressing automated problem resolution and preemptive countermeasures).

The following is my 4-phased program for solving your application errors. Classification is inclusive, so the 4th phase (the highest level of reliability) also includes the properties of the preceding levels:

Phase-1: Create Unique and Traceable Errors and a way to Record them
If you are under the gun and don’t have time for any other remedy, at least make sure that your error cases are unique. Telling your users that an error has occurred in the application without providing details is a sign of an immature product. When your technical support team receives an error report, they should be able to determine precisely what is causing the problem.

Generic error handling (same message for all errors), or different error causes that return identical messages, are easy to implement, but when it comes to debugging they are useless. Unique error IDs allow us to more efficiently track bugs and translate them to a more stable product.

Error codes should be visible in the error messages but not be the focal point of the the message.  You should develop a library of descriptive text that provides a human readable explanation of what the error means.  Provide a simple mechanism to either log the message directly into your app or send it to you via email.  Nothing is more annoying to the user than being asked to type in the error message manually.

Establish an Issue Tracking System that allows quick data entry and reporting.  At the minimum record the error code, error description, and the steps to reproduce it, effected environments, and its frequency.

Phase-2: Keep the User Calm and his Data Safe
Error messages should always carry a mature and responsible tone. Always use supportive, polite language, like a good teacher would when instructing a pupil.

If the user opts to leave a mandatory field empty, or mistypes the data type (CC#, zip , etc.), don’t go ballistic. Non-critical errors deserve non critical messages. Instead, indicate on the entry form where the problem was, place the cursor in the relevant field and leave the rest of the data intact. This is especially important for long entry forms that require a lot of effort to complete.

Don’t force the user to duplicate entry of some previously supplied data for verification purposes (such as billing and shipping information) as it may introduce human error and trigger him to abandon the application altogether.

Phase-3: Good Errors Messages are Clear and Provide Remedies
The way the user perceives the error is much different from the way you do. He thinks in business terms and knows nothing about the inner workings of your application, nor does he care. That’s why you should always design the error UI from the user’s perspective.

Here are the seven golden attributes of error messages:

  1. Describe the error in user terms and language
  2. Instruct the user as to how to complete the task and resolve the error
  3. Explain how to prevent the problem in the future
  4. Avoid technical mumbo jumbo and acronyms
  5. Avoid modal pop up error messages and instead write error directly to the page
  6. Provide help links that better explain the nature of the error
  7. Keep the text formatting simple and avoid bright colors and animations

When providing a solution, give clear step by step instructions as to how to fix the problem. Be specific and do not assume any pervious user knowledge. If there is a relevant tutorial or the specific solution in your on-line help, provide links directly there. If it’s a critical problem—for example, the Website is not accessible—provide a mechanism for the user to report the problem to you and immediately acknowledge the receipt of his complaint, provide an explanation and an estimate of time before this problem will be resolved.

Phase-4: Handle Errors Internally
Write code to robustly handle all errors. This will eliminate the most severe and common errors (like missing data or validation). You can achieve this by automating data entry components from the user interaction (i.e. deriving city name from zip code).

To the extent possible, take corrective action before an error occurs. For example, if the user is in the middle of a lengthy entry form, save the contents as he moves between fields, this will allow you to restore the information if he inadvertently navigates off the page or even closes his browser session.

It’s often expensive to identify and address all possible failure cases, but if you have been tracking your top bugs, you can start with the biggest offenders first.

The way you handle and communicate application errors directly reflects on your team’s and your company’s reputation. When building a new or reworking existing functionality don’t assume that the old error messages apply to your new logic and boundaries.  Building test cases around various error scenarios (missing data, wrong data, bad data, etc.) and dedicating a test cycle to generate all known error messages is also an excellent strategy.

Error handling and messages should be thought of as required phase of any feature development, and adequate engineering time for it should be budgeted into all SDLC estimates.

Real quality of service goes beyond just acknowledging your application’s faults. My rule of thumb is that there is no such thing as an “informative error message”. A good error is one that has been eliminated through error-handling code and through superior product design.

© Copyright 2010 Yaacov Apelbaum All Rights Reserved.

It’s Good Enough for Me

Yaacov Apelbaum-Giacamo the Good

I commute frequently, so I tend to have some down time at the airport while sitting at the gate and waiting for my ship to come in. I usually use this window to catch up on my technical reading, but recently I decided to take a break and venture in to one of the book stores in the concourse. After skimming the offerings, I discovered a bookshelf filled with titles of the “How I Became the Best In ___, and How You Too Can By Simply Following My Easy Three-Step Program” genre. These books, mind you, are not cheep paper backs. I was looking at thick hardbacks, generously illustrated and accordingly priced. Apparently, the “How to Become the Best” series industry is booming.

This got me thinking: statistically speaking, the best of any kind takes up only a tiny outlier of the bell curve. So why the hype? Clearly, if this industry is thriving there are enough literate people out there who were willing to buy into the idea that being the “best” is worth their time and money.

Then a few weeks ago, I found myself confronted with this concept again. I was having lunch with a colleague and he raised the argument that the only way to win in today’s lean software economy is to develop the “best” features and functionality. He expressed his strong conviction by recounting his recent experience at a trendy “how to become the best” seminar. “I am a new man,” he said, “This event has changed my entire outlook on product development”. “How’s that?” I asked, curious. He leaned forward, squinted, and in a lower and somewhat more mysterious voice, he summarized his newly acquired philosophy. He said that according to the presenters, Trump, Robbins, and Kiyosaki, success hinges on one’s ability to tap into one’s inner best. Either you’re Napoleon or you’re out of the game.

At this point, I was done with my burrito and so I seized the opportunity to respond in kind with a rival French maxim. I quoted Voltaire: “Le mieux est l’ennemi du bien” (The Best is the Enemy of the Good). Wellington, I pointed out, was by no means the best, but he certainly outlasted Napoleon in the game.

My companion was startled and said he didn’t understand what I meant. I offered an explanation: “It’s not that I am a proponent of mediocrity; to the contrary,” I said, “I pride myself on my attention to quality. I have absolutely no problem with the concept of pursuing excellence. What prevents me from realizing perfection are mundane details such as looming deadlines, shrinking budgets, and a chronic shortage of resources.”

Of course it’s easy to invoke demagoguery and claim that it’s either “best” or “bust”. Many development managers adapt this mistaken philosophy, assuming that it has a positive motivational value. The average corporate culture doesn’t help dispel this myth either, by creating unattainable criteria for personal performance and compensation plans. Regardless of how fond of the cliché’ you may be, unfortunately preaching the best when it comes to delivering software under time, quality, and budgetary constraints is one thing, actually being able to deliver on such promises is quite another. If we learn anything from human endeavors, it is that “good enough” is more than acceptable. As far as I know, most of us don’t drive the best car on the market, live in the best built house, or exclusively buy the best clothes or appliances. Compromise is the order of the day.

My favorite story that illustrates this concept is the World War II race to develop the radar. Both British and German teams were aware of the tremendous operational and strategic advantage this new technology could offer. The German development team had the more advanced science and superior technology. Their radar was more accurate, had a longer range, and provided fewer false-positives. The German team—true to their cultural heritage—was striving to develop the best apparatus possible. The British team was smaller, less experienced, and had inferior technology. But from the outset, it adopted the motto: “Second Best Tomorrow”. This philosophy eventually allowed them to release an inferior but working radar earlier than the Germans thus winning the race and ultimately tipping the balance of power.

Cheap (often free) and simple software free of stringent SLAs is popping up everywhere. Most of us now get our breaking news from Google and personal blogs, case in point. We make free, long-distance calls on Skype (and don’t mind the low QoS), watch video on tiny iPods screens rather than high definition TVs, and more and more of us are using low-power cell phones that are just good enough to meet our surfing and emailing needs. For many leading companies, the distinction between good enough “beta” versions and commercially “best” products has blurred beyond recognition. (Gmail has finally come out of beta after more than 5 years.)

To be successful in commercial software development, one must fight the urge to gold plate by adding late stage functionality. One must also learn how to be firm regarding ad nauseum pressure for application re-writes, all in the name of making it the best.

Contrary to what the motivational posters profess, when it comes to shipping on-time, the pursuit of perfection can become your worst enemy. The same also applies to excessive QA and testing. In the end, even the most comprehensive white, gray or black box tests can only provide a projection of how your application will perform. The ultimate usefulness gauge are the real users. The earlier you release your product into the wild, the faster you’ll discover if it adequately fills a need.

As I have discovered on many occasions, building a good enough product and releasing it early enough is good enough for most customers—which is good enough for me.

© Copyright 2009 Yaacov Apelbaum All Rights Reserved.

Political Science 101

Political Science

Having kids in elementary school comes with several important parental commitments. Ranking high among these is the participation in the yearly science project. The main objective is to expose kids to the fundamentals of the scientific method. Following the principal of “learning by doing,” children, with the assistance of their parents, are required to conduct and showcase a yearly science experiment.

In our school district, exhibition day is a long-awaited, festive event with hundreds of projects being showcased at the school’s gymnasium. It is a great opportunity for families to mingle and view each other’s work. To spice things up a bit, at the end of the event, a panel of teachers selects the top three projects for each grade. The 1st place winners are then entitled to enter their project into the yearly regional competition that takes place at Brookhaven National Laboratory, a much coveted honor.

Although it is a great concept in theory, for some, the yearly science project can become a dreaded event, often testing a family’s procrastination capacity to the limits. On the weekend prior to the project’s due date, it is not unusual to find many agitated parents with kids in tow still scouring craft stores for project display boards and other supplies. In our family, however, we’ve come to view this assignment as an important pedagogical opportunity worthy of careful planning and execution.

I am fan of Richard Feynman, and have enjoyed reading “Surely You’re Joking, Mr. Feynman!”.  This book in addition to being an excellent primer for the budding technology hacker, inspired me to instill in my kids the importance of not falling victim to the “Cargo Cult” syndrome, and being honest and original in one’s approach to scientific discovery.

As it turns out, this has been a winning strategy for us. Since we started conducting science projects 4 years ago, we’ve been fortunate to have won several first place awards. Some of our past projects included experiments on bottleneck formation, sound propagation through vacuum, and algorithms and mathematics used by a spider to construct a web.

This year, during a routine morning school drop off, our 4th grader, Sheva, noticed that a traffic bottleneck formed regularly at one of the entrances to her school. After discussing her observations during dinner  she proposed to dedicate her project  to deciphering it.

Over a period of several days, we examined the traffic patterns, (volume, arrival and departure times, vehicle speed, etc.), but it seemed that there was no single significant cause to which we could attribute the formation of the bottleneck. We were stumped and unsure as to how to proceed. It was during one of the site visits that my daughter noticed a hawk hovering over the area. She commented that it would have been great if we could observe the traffic from above. Well, I thought, we may not be able to fly over the site like a hawk, (it is a residential area so a fly-over in an Ultralight would be out of the question), but we could certainly build an airborne observatory to do it for us.

After considering options, we decided that a fixed winged propeller driven aircraft wouldn’t work because the wind gusts at the area can reach up to 40 mph. Another constraint was that we would need a sustained, 30-minute flight to capture the entire bottleneck sequence which would be prohibitive.

In the end, we decided to build a lighter than air aircraft (Image 1) and after an intense weekend of design and fabrication we had a functional observatory. It took several test runs to get the flight characteristics and image quality right, but by Monday we were ready to conduct our operational flight.

Aerial Traffic Observation System (ATOS)
Image 1: ATOS (Airborne Traffic Observation System)

Flight Navigation and Imaging Specifications

  1. 4′ Chloroprene weather balloon with 1.7 lbs. of lifting capacity
  2. Riveted aluminum base cradle
  3. Flight control and stabilization via 2 tethers
  4. Canon FS100 Flash Memory (16 GB) camcorder with image stabilization
  5. Wireless broadcast via an Amimon’s wireless modem, streaming HD 1080P/24 video at 120 Hz over an encrypted connection to a base station laptop

The first flight of ATOS was smooth, producing an excellent video feed.  Back home after evaluating the images, Sheva almost instantly identified the source of the bottleneck.

It was apparent that the two-way traffic at the entrance to school was restricted to only smaller vehicles. As soon as the school buses arrived for their daily drop-off and pick-up, they forced all vehicles into a single file, which resulted in the immediate formation of a bottleneck.

Gate Traffic Set

This discovery was somewhat puzzling because, from the ground, the road (which is nearly 31′) seemed wide enough to comfortably support the passage of two side by side buses. So, on our next field trip we decided to measure the gate (Illustration 1) that blocks the entrance in question.  Armed with the gate’s measurements, we then consulted the traffic calming section in the NY highway design manual and quickly concluded that indeed the gate was at fault.

Yaacov Apelbaum-Gate 
Illustration 1: Gate Dimensions

So science aside, installing a gate that blocked over 30% of a high traffic thoroughfare was clearly a bad idea, not to mention that it violated numerous design codes. The gate and the fences that are attached to each of its sides also posed a series safety hazard because drivers who were unaware of the obstruction might plow directly into the fence, while still others who miscalculated the gate’s clearance could potentially scrape the posts supporting the gate.

On the day of the science fair, I approached the school principal and inquired about the origin of the gate. I explained that it appears that someone had either made a design or installation error because the gate’s posts should have been placed on the sidewalk curbs, off the driveway. The rationale for this being that when the gate was completely open it would allow for unrestricted traffic. The principal told me that the decision to construct the gate preceded her time in office and it had been influenced by the homeowners just down the street who complained that the traffic had become a nuisance. To reduce the traffic in order to appease the homeowners, the school agreed to install the gate as built.

Not satisfied with this explanation, I proceeded to point out the hazards posed by the gate as it stands and began to enumerate various doomsday scenarios. The principal’s otherwise cheerful demeanor suddenly darkened and after a quick and nervous glance at her watch she said that it was unfortunate that our meeting had to end so abruptly, but that she had to run to an important conference.

On the way home, our daughter who had been standing by me during the entire conversation with the principal asked me if, now that we’ve provided a scientific explanation for the formation of the bottle neck, the school would fix the problem. I thought about it for few minutes and said, “Probably not.”  She asked “why?”, I said that unfortunately, sometimes in the short term, politics can trump science. She was visibly disappointed and said that she worked so hard on this project and it all turned out to be a complete waste of our time. I told her that even though we didn’t win, we still conducted a great experiment and independently discovered and solved an interesting puzzle. And by way of analogy, I told her about the Galileo affair and how despite his mistreatment by the inquisition, in the end, his theories eventually won acceptance.

A few days after the science experiment, my wife, while waiting to pickup our daughter from school, struck up conversation with another parent who seemed to be visibly upset. “Why the long face?” she asked. “Well,” said our neighbor, “while driving into the school parking lot, I was being polite and made extra room for the car approaching me, but I miscalculated the width of the opening and scraped the side of my van against the gate post.” She had carved a deep gauge in right hand side of her van from wheel rim to wheel rim.

That evening during dinner, my wife recounted the story of the accident. My daughter at first thought that my wife was making the whole thing up, but after hearing that it was the mother of one of her classmates, she asked for permission to call her friend to verify the facts. When she got back to the dinner table, she had a look of disbelief on her face. “That’s exactly what we told the principle could happen!” she said. “We sure did,” I said.

She remained silent for few seconds and then I noticed a twinkle in her eyes.

© Copyright 2009 Yaacov Apelbaum All Rights Reserved.

Bells and Whistles

Bells and Whistles

Several weeks ago, my car’s dashboard informed me that I would need to “check the engine”. Naturally, I promptly brought the car to the dealership. After a quick examination (and $170 in troubleshooting fees), the dealer told me that there was nothing physically wrong with the car and that the message was due to a software bug that was easily fixable with a software patch that he would be happy to apply for as little as an additional $120.

Now, I don’t know much about the latest trends of engine design, but I am quite familiar with software bugs. Over the years I have produced several of them myself and like many other software engineers, I spend a certain amount of my waking and sleeping hours chasing them around. But contrary to my trusted dealer, I fix my bugs—to delight of my customers—at no extra charge.

Being the pedagogue that I am, I seized the opportunity to educate Randy, the senior service adviser (the title on his tag), and proceeded to deliver a short and upbeat oration on the subject of the software industry’s best practices regarding free bug fixes. My friend behind the counter seemed unimpressed and reminded me that his dealership is not in the business of selling software. He then inquired about my preferred form of payment for the pending repair.

On the way home I got to thinking about the cutthroat business model that the car industry is following. Clearly, it must be the competitive nature of the industry that forces them to squeeze profit at the margins to included even basic service like fixing their own bugs. I then dismissed any further thought on the subject. Then a few weeks ago, the news broke out that the car industry had officially joined the federal hand-out program. It was now standing on-line with a tin can in hand and singing in harmony “Brother, can your spare a dime?” with all the other financial industry hobos.

So I figured that there has to be something here that doesn’t meet the eye. Why has such a well lubricated and fabulously successful industry suddenly collapsed? Contrary to the financial sectors, their operational and risk models have not significantly changed for over 100 years. Cars today are designed and built faster than they were 40 years ago and they are cheaper to manufacture and sell.

After pondering this for a while, I realized that this failure has been long in the making and just like in many active Ponzi schemes, this one has been finally flushed out when consumer spending came to a screeching halt.

In the aftermath of World War II as manufacturing was going civilian again, the car industry more than any other sector embraced a strategy that focused entirely on building a product with the highest degree of of obsolescence (an average car would be recycled every n years) and greatest curb appeal. Traditional engineering principles like safety, longevity, efficiency and environmental friendliness were sacrificed. They were replaced with a lot of chrome, increased fender size, overpowered V8 engines and pink leather. This was the wisdom of the time; you can’t charge higher prices for less car.

In the 70’s, when the Japanese car manufacturers finally introduced a new concept of vehicles very different from the traditional tank, domestic car manufacturers after much soul searching, publicly embraced the banner of the new smaller more efficient car. In reality, however, they continued to practice the same philosophy as they do to this day. So in fact, not much has changed. Yes, the large fenders and chrome bumpers are gone, but in their place we have a whole new list of bells and whistles. Apparently, the car manufacturers have been taking lessons from the software industry and are now playing the feature functionality game.

Go to any domestic dealership and you are guaranteed to find the following list of “key” features:

  • Rain-sensing wipers
  • Heated/cooled seats and cup holders
  • V8 with extra torque
  • Extended Length
  • Remote starter

What is noticeably missing from the list is an engine and transmission that are guaranteed for 300K miles or the 80 mpg gas efficiency, both of which are easily achievable in this day and age.

Unfortunately for all of us, the car industry has spent the last 60 years mastering the fine art of consumer psychology and honing of their salesmanship skills with too little time spent on developing quality products.

Thank you very much, but I’ll have to decline! Contrary to what the focus groups are saying, I don’t need a Hummer. And no, throwing in a free electric cup warmer is not going to change my mind. I am, however, interested in a bug free safe electric car that can go 400 miles between charges if there are any takers.

© Copyright 2008 Yaacov Apelbaum All Rights Reserved.