TechDistortion

One Man Can Lead, But That Man Isn't The Company

Today was the day that Steve Jobs, the CEO of Apple Inc., resigned his position as CEO.

Steve Jobs did not make the hardware. He did not write the software that runs on it. He did not design the batteries that go in Apple products, nor screens, nor cases, nor memory, nor processors, nor circuit boards, nor antennas - nothing.

The quality of the products (in terms of defects) were handled by test engineers, not Jobs. The manufacture of the products was by large Chinese, Japanese and Taiwanese companies (largely), not Jobs nor Apple directly. The advertising and marketing wasn’t done by Jobs.

It is fair to assume that all of these things and many others will function perfectly well without Steve Jobs as the CEO of Apple.

What Steve Jobs did do, was to set the standard - to set the bar. He has a set of design beliefs and principles that are well known: a dislike of physical buttons, cables, and a general push for simplicity as well as thinner and lighter devices. These design goals and his dogged focus on them have brought products to the world that no other company at the time could create.

Those closest to him (in a business sense), being Phil Schiller, Tim Cook and other executives, have been watching and learning about the bar that Steve Jobs set. They will continue to emulate that bar as best they can, without him as CEO. They have the last 10 years of building success to guide them in their future direction.

Apple without Steve Jobs as the CEO?

Their future is in safe hands.

Palm, HP, WebOS and Promises Broken

There are no industries that move as fast as consumer technology. The reason is simple: people want the latest, thinnest, lightest, fastest tech toy they can get their hands on. This leads to companies like Samsung, Motorola, Apple, HP, Dell, and the list goes on, that are battling to innovate to make the next best thing in the consumer market. In an effort to get involved in the tablet and smartphone consumer market HP decided to make a big investment and try to join the other companies already succeeding in those markets.

On the 28th of April last year, HP announced that it was purchasing Palm and the rights to use all of their work on WebOS. In their press release they stated the: “…webOS platform will enhance HP’s ability to participate more aggressively in the fast-growing, highly profitable smartphone and connected mobile device markets…”  It wasn’t until mid May 2011 that HP delivered their first WebOS product to the market: the pint-sized Veer, followed by their much anticipated TouchPad in early July 2011.

Sales of both devices weren’t stellar, but entering a highly competitive market with a premium priced product is never easy. The reviews were mostly positive however the OS had a feel of being unfinished and whilst a software update that followed in August solved a great number of performance issues with the TouchPad, the product didn’t seem to be gaining momentum. The final product in the line: the Pre 3 was released in the UK on the 17th of August, 2011. Suddenly, a bombshell.

Yesterday on the 18th of August 2011, HP announced that it was discontinuing their WebOS products in the market: The TouchPad, Veer and Pre 3. More details followed on a conference call/webcast later in the day. A transcript [pdf] of the conference call outlined their reasons more specifically. They indicated that: “…the tablet effect is real and our TouchPad has not been gaining enough traction in the marketplace…” and “…we see too long a ramp-up in the market share.” The most important context for their decision rests around this: “…the Board of Directors has authorized our Management team to explore strategic alternatives for PSG [the Products and Services Group]. We intend to evaluate…options that may include…a separation of PSG from HP to a spinoff or other transaction.”

There are two things I draw from this situation. First, HP executives wanted, expected, believed that WebOS and its devices would sell just like the Apple iPhone and iPad. If they didn’t perhaps believe they could sell those sorts of numbers, they certainly expected better than they saw. The cautionary tale is that original iPhone took 2-1/2 months to reach 1 million sales. That was without a GPS, without third party Apps, exclusive to one carrier in the USA. Apple didn’t start selling the iPhone 4 (at 1-1/2 million units on its first day) they built up to it.

HP should have had more realistic expectations about their new product. HP only just released these devices and it takes more than a few weeks months or a day to gain traction and ramp-up market share. Translation: HP aren’t interested in being in the smartphone business or tablet business as it currently stands. WebOS was their best chance and big investment to get them off the ground. They didn’t provide enough of a compelling reason for their product to be preferred over their competition, but that takes time when you’re entering a market dominated by one or more big devices and players. Perhaps the headstart that Apple has with its eco-system of iTunes and its App Store momentum was too great a pill for HP to swallow. To be a big competitor to the iPad for example, HP needed to deliver an eco-system and applications by the truckload. It was still early days and totally achievable if HP would put more money where its mouth was (at that time) but clearly they decided they’d spent enough on WebOS devices.

The second thing I draw from this is a large element that has nothing at all to do with WebOS or its apparent initial lack of stellar success. Splitting off the PSG from the rest of HP is a major undertaking and this affects much larger business units than HP/Palm/WebOS. In this way I have no doubt that WebOS has just become a victim of the traditional corporate restructure. Sometimes these restructures have a positive effect on the business as a whole and can focus the company (or companies) on their core businesses with less top-level management interference. Other times it can be the beginning of the end. Which of these it is only time will tell and I’m not going to hazard a guess as to which scenario will befall HP. I would say though that traditionalists within big companies that see acquisitions as deviations from the core business will often take the restructure and use it as a way to rid themselves of a division they don’t believe should be there. The more things change, the more they stay the same.

For us the consumers or the tech junkie onlookers we collectively shake our heads today, wondering why a set of products that were credible contenders to compete with the iPad and iPhone with genuinely new ideas and implementations, have just had their lives cut short by executives that still think their Blackberries are the pinnacle of tech.

It’s a terrible shame. A terrible, terrible shame.

Google buys Motorola Mobility

Yesterday, Google announced its purchase of Motorola’s mobile handset division - split out from it’s parent company into what was called Motorola Mobility not that long ago. Google seems to have three goals.

1. Eliminate the middle-man. As I’ve discussed in previous posts, one of the problems that Google used to have was that their partners, HTC, Samsung, Motorola and so on, were given the source code for the latest version of Android - that they could then choose to update to run on their phones and then pass on to the carriers for distribution wirelessly to their end users. The problem was, most of the middle-men weren’t updating existing phones - they were busy making new phones. 3-6 months seems to be the average lifetime of a phone design from most manufacturers other than Apple in the current smartphone game. Apple customers have been able to get free software updates to their 3 year old iPhones giving them new leases on life, whilst Android users have usually been stuck at the operating system version they bought the phone with. New features and bug fixes left wanting. Now that Google own a middle-man, they can control the product cycle and prioritize their releases the way they want to.
2. Acquire Patents. Recently the issue of software patents has been very public with the purchase of a mass of patents from the remains of Nortel (for whom I once worked many years ago) by Microsoft and Apple left Google wanting. The way to play the patent game seems to be more about the person/company who has the most patents is the person no one is prepared to sue for fear of a counter-suit. Motorola Mobility has a very sizable patent portfolio that Google will very likely start putting to use suing both Apple and Microsoft to keep to push their Android operating system further out of the legal reach of their competitors.
3. Full Hardware Control. This puts Google on the same table as Apple. The real question is whether they will or can deliver a highly integrated experience that they can sell on their own terms to carriers the way Apple has with the iPhone. Consider that carriers already have HTC and Samsung supplying most of their phones, tailored just the way they want. Most carriers put up with the iPhones lack of tailorability simply because it pulls in the new customers.

Google then, it would seem, has just spent $12.5 Billion USD on a good acquisition. Or have they? The problem is that if Google choose to exert their control of the hardware and give preferential treatment to their own Motorola division, how long will it be before HTC and Samsung choose to dial-back their Android phones and move more towards Windows Phone 7, or their own operating systems? If Google keep the best features for themselves to entice more people to purchase their Motorola phones (given they now OWN a mobile manufacturer - their business model requires that they sell as many units as they can) it will only drive their current partners away - losing Android overall marketshare and in the process Google will lose some of its revenue from Android. If they don’t give preferential treatment to Motorola and they are fair to their partners then why spend so much money on Motorola Mobility in the first place? After the excitement of the potential for this purchase has faded away, the reality of running a hardware product business that has seen declining sales in recent years and the potential alientation of Googles current partners will dawn on Google. I’m not so sure the purchase was wise at all. The end result could hurt Google and Android severely. Alternatively Google could elevate the hardware platform to a whole new level with many great new features that other manufacturers are too reluctant to add. Make no mistake though: one way or the other this was a pivotal moment in the history of the mobile market. Stay tuned for the glory, or the chaos to ensue.

Schedules and Software - Why don't they place nice?

Time and again lately I’ve been hammered at work regarding software schedules. Whilst it’s difficult enough to explain this to management that don’t understand software, maybe it would be possible to explain it to anyone else. I thought it would be interesting to put down my thoughts on how it is possible to generate a software schedule that is realistic and achievable.

Civil engineering is a great analogy to draw on, so let’s start by setting the scene with a project where they’re building a road. The designers start by doing investigation and determining the requirements for the road (testing soil, how many cars per day does it need to carry, how heavy are those cars etc). Once this is done and agreed the design work begins - detailed drawings, specifications and reports that are handed over to a constructor. The constructor takes these drawings, orders the bits they need and they start building. Unfortunately it rained on and off for weeks and they were unable to lay any pavement so there was a big delay. Once the road is built and the finishing touches are put on (lines, barriers etc) it needs to be tested to ensure it’s the right thickness and consistency and complies with the design. Once that’s done the road is finished and everyone is (hopefully) happy.

Still with me? I hope so because now it’s time for software development.

First the programmer defines the scope by investigating the requirements for the software: this includes the interfaces to people, other software/hardware systems, databases etc. Once these basic requirements are agreed the basic framework design begins: how they will break the code down into objects (blocks) as well as specifications describing how the code will be finally assembled and then tested. Once this is done the programmers then begin the task of programming the objects. When the objects are done they are tested and then the objects are all assembled together into larger, functional pieces of code. These pieces of code are then tested and once the finishing touches are done the final system is acceptance tested and then hopefully everyone is happy and we are done.

The similarities are clear enough, so why is scheduling software so difficult? I think there are two drivers behind the problem: 1) Because software can be easily changed, it often is - even though the change can have massive implications; and 2) Time for “inclement weather” is rarely allowed for in software schedules. In software it doesn’t rain but bugs are found that need to be fixed. Think of it like someone raining on your otherwise perfect piece of code. This time needs to be allowed for. In Civil projects weather delays are often included in the schedule from the very beginning, but time for code rework in software projects isn’t.

If one was building a road and it was discovered they forgot to cover a big hole in the ground and put the pavement over the top of it, they would have little choice but to rip it up and start again on that bit of road. So it is also for software. If we find a bug it needs to be fixed. Let’s say the road constructor was doing their final testing of the road when they discovered the hole - they would have to fix it before they could finish the road. The same is true of software. Allowances must always be made for rework - no matter how good the programmer is or claims to be, they will always make mistakes and there will always be some rework. Like the weather, the size of the delay is hard to quantify, but some delay is a guarantee.

In the land of Civil Engineering there is a well understood concept that late changes to the design like, “oh we wanted the road to a bit to the left around this forest” at the 11th hour are just impossible. The roadbase is likely done, some pavement is laid, and you well, just can’t change it right? Even if there is scope change earlier in the design once the road clearing has begun, there is usually a big cost involved in making a change. The problem with software is that there is belief that “it’s not a physical thing I can touch so I can change it.” Perhaps the problem is similar to typing a document on a typewriter and typing a document in a word processor. We have become so used to fixing typographical errors in a Word document with a simple keystroke or two and a fresh print-out, we think that changing software is just as easy.

Wrong.

There may well be some changes to software design that are minimal in impact, but every change should be assessed for its time and cost implications. If objects are already written and tested and are ready for final integration, if a change is then made all of that code needs to be regression tested again and this must be costed. Schedules should be adjusted and extended in time in that instance as well with every change to the scope of the design - no differently to a Civil schedule.

The other problem comes back to design vs implementation. Some people say that the code is the design, but in that sense it is also its own implementation. The problem is how does one separate design, implementation and testing in software? In the Civil world it’s clear: the hole you just dug is your implementation and you only dig holes when your design is done and you only test the hole is correct when the hole is finished.

The problem with software is that in this day where multiple programmers are usually needed to complete a project and programs are quite large - there is no choice but to break it down into objects and smaller pieces. This means that not only do the objects have design, implementation and test stages for each object, but so does the overall final product delivery. Add to that the fact that good programmers test continuously as they program and it gets difficult to track time.

How does one track hours? Tracking software as one blob of time (like most projects do) will artificially blow out the time taken to develop the software. If it is broken down into costs for object development and overall development and those are broken down into design, implementation and testing, the hours spent can be correctly tracked. Certainly piecemeal testing of sub-functions within an object are not always formally, rigorously tested and this testing may well be counted as code development - no system will be perfect.

There are also common things to all kinds of scheduling such as accounting for staff turn-over and retraining of new staff, illness, loss of data etc. That said, if one accounted for all of the real-world issues in a schedule and used that schedule as the basis for final project costing in a tender response, there is a good chance the company would not win the job based on their price alone. This doesn’t mean people shouldn’t try and cost things accurately. If the project is won for a cheaper price and the allowances have been removed to win the job, in the end the managers need to understand that costs were cut and they should not take it out on the programmers who are just trying to finish the job.

Thoughts; advice; venting; now over. I hope this helps someone in the future…