# Monday, October 31, 2011

This week I will be attending and speaking at the 1st World CIO Forum held in booming city of Shenzhen, China sponsored by the International Federation for Information Processing.

image

The theme of the World CIO Forum is: Globalization and IT Innovation. Topics include: cloud computing (of course!), mobile innovation, green IT, CIO Leadership, “manufacturing 2.0” (my track), and e-government.

The night before the conference started (Halloween!), I had the pleasure of spending an hour with Li Ming, the deputy mayor of Shenzhen and ten fellow speakers. It was all very official; we were in a big room with name cards and we sat in big chairs drinking Chinese tea. Joining me at the meeting and then at dinner were very prestigious speakers, including a member of the board of directors of Microsoft and the CTO of Toyota (Info Technology Center). There were many toasts, something you can’t avoid in China. I feel that Telerik has made it to the big leagues.

I give a talk on Wednesday: “Lean Manufacturing's Influence on Agile Methodologies: The Past, Present, and Future.”

posted on Monday, October 31, 2011 10:11:32 AM (Eastern Daylight Time, UTC-04:00)  #    Comments [0] Trackback
# Tuesday, October 18, 2011

In the past, most developers’ approach to code is that you should write it once and hopefully never have to debug or revisit it again. This stems from the traditional waterfall approach of software development where we were trying to completely describe the entire system up front perfectly. Change was bad and bugs were not accounted for and left for the end.

The Agile movement ushered in the first change to this mentality. Agile introduced the concept of refactoring, or writing your software once and then revisiting it (often if needed) and restructuring its internals for improvement (without changing its external outputs). Refactoring is a core tenant of test driven development, where you are encouraged to refactor each method you write at least once.

The Lean Manufacturing movement is built around the concept of Kaizen, or Japanese for “improvement” or “change for the better.” Last week at the first even Lean and IT summit in Paris, France, I heard once or twice about the concept of writing code as a Kaizen event. Software Kaizen goes a step further than refactoring.

The Lean guys were talking about Kaizen as the removal of waste by the improvement of your own work. It is about understanding waste derived from your own decisions, looking at the unnecessary costs created by our wrong assumptions and decisions. The Lean guys spoke about how Kaizen is cultural shift that gets people thinking.

While refactoring addresses each individual method, Software Kaizen takes a much broader approach and looks for waste in your entire work. A lot of time we developers build features and stuff that are not needed. Where did you create a library that you only call once in the name of “maintainability?” Where did you make something unnecessarily complex in the name of “extensibility?” Where where your assumptions incorrect and caused problems or ambiguity in your code? When have you over engineered a feature? Refactoring only partially addresses this, we’ll go in on a regular basis and refactor a few complex methods, but we rarely ask ourselves if we need that entire method in the first place, or an entire feature. Software Kaizen asks us to look at our code and asks us why did we do it this way, with a “cut first” mentality. It challenges the assumptions we made at the time we wrote the code.

Traditional waterfall approached code as something you should write and be perfect the first time and only revisit it when you find bugs. Agile encourages refactoring your methods for improvements in the way it runs and reads internally. Software Kaizen encourages looking your system and looking at the choices you made in the name of maintainability, extensibility, etc, and ask yourself where you were wrong. Software Kaizen focuses on approaching your code knowing you are going to change it often. In the past we fought change, Software Kaizen embraces change as part of the process.

Give it a try, it is harder than it seems. (“Of course I need that really really complex method, I may one day port this code to a Mainframe!”) Good luck and happy coding.

posted on Tuesday, October 18, 2011 2:36:57 AM (Eastern Daylight Time, UTC-04:00)  #    Comments [2] Trackback
# Monday, October 10, 2011

A lot of people have posted tributes to Steve Jobs over the past week. I’ve seen him called the CEO of the Decade (something I agree with) and also compared to Henry Ford (I sort of agree with). I’d like to call attention to four lessons we can learn from Steve Jobs’ Apple, two positive and two negative. First the good:

Apple avoided falling into the trap of the Innovator’s Dilemma

Apple avoided falling into the trap of the Innovator’s Dilemma. In a nutshell, the Innovator’s Dilemma says the following (I am paraphrasing): when you invent something, first you are trying to penetrate a new market and convince people to buy your invention. At this stage you will do anything to get noticed. After a while, your invention becomes mainstream.  Your profits predictable. Your investors complacent. Then a new disruptive technology is starting to show up here and there. You ask your customers (who are all mainstream consumers or businesses) what they want and you build that for them. Pretty soon, you go out of business (or drastically lose share) because the new disruptive technology overtook you. You failed because you made good management decisions (focusing on profits, listening to customers, etc), hence the dilemma. Henry Ford is credited with saying:  “If I listened to my customers, I’d have built a faster horse.”

Apple constantly churned and churned out new products, defining new categories. The pace of innovation was breathtaking, as soon as a new iPhone was released, there were rumors of a newer and faster one. Some would say that Apple was going to cannibalize their older products with the new, but they forged ahead anyway, with the profits to show for it. Apple embraced the disruptive technologies, not fought them.

Apple worked to create an experience, not just raw technology

When you buy an iPad, you are buying an experience. With the integration with iTunes you can download Apps, books, movies, magazines, and of course music. There is a whole ecosystem around Apple and the iPad, that is why they don’t OEM iOS to other vendors to build a device, Apple wants to control the experience.

Android on the other hand has no such ecosystem. They build the OS and let the OEMs build the hardware. There are phones running Android that are much better than the iPhone and there are tablets that are just as good as the iPad, but don’t sell well. Why? There is no ecosystem. I went into the local electronics shop here in Hong Kong and played with the Lenovo and Samsung tablets and there was no true “feel” to them, it was just a screen waiting for you to configure stuff on. Good for geeks, but not for consumers. My mom needs the simplicity of an ecosystem and an integrated experience. 

Google and by extension their OEMs, figured that slick and cool technology was going to be enough to win. Apple realized that good technology was not enough, users demanded an experience, and Apple gave it to them.

Now some lessons from things that Steve could have done better:

Apple suffers from the “Curse of the superstar CEO”

When I was in business school, I read a case study called “Curse of the superstar CEO”. The article stated that recently we have looked to leaders (CEOs) who have a lot of charisma and we tend to worship them like a religious figure. The curse of the superstar CEO is very problematic, it leads to leadership succession problems as well as exaggerates the impact that the CEO has on the company they are leading.

Steve Jobs was larger than life, the black turtle neck shirt and jeans (which I liked) became a cultural icon. No matter how great a CEO Tim Cook will be, he will always be compared to Steve Jobs and will always disappoint simply for not being Steve. (If you don’t believe me, just ask Steve Ballmer how he is doing not being Bill Gates.)

Apple Took secrecy to an extreme

I understand how you want to keep things secret in a competitive marketplace. I also understand the value of trying to control the message. That all said, Apple took this all to an extreme. They shut down fan rumor sites (by suing fans who were kids!), sent the police to people’s homes to look for a lost iPhone prototype, and never talked to the press.

While this creates a tremendous amount of buzz, it also leads to misaligned expectations. When the MacBook Air and the iPhone 4S were announced, their reviews and reception were not that great as people were holding out and expecting something more. While the secrecy worked to generate buzz, it did not always work out as a positive. When secrecy is taken to such an extreme, it can work against you. While Apple is still super positive, they can get away with a lot, but not forever.

posted on Monday, October 10, 2011 11:43:59 AM (Eastern Daylight Time, UTC-04:00)  #    Comments [3] Trackback