steve jobs

What Would Google Do?

Peter Cripps creativity, education , , , ,

Readers of this blog will know that one of my interests/research areas is how to effectively bring together left-brain (i.e. logical) and right-brain (i.e. creative) thinkers in order to drive creativity and generate new and innovative ideas to solve some of the worlds wicked problems. One of the books that have most influenced me in this respect is Daniel Pink’s A Whole New Mind – Why Right-Brainers Will Rule the Future. Together with a colleague I am developing the concept of the versatilist (first coined by Gartner) as a role that effectively brings together both right- and left-brain thinkers to solve some of the knotty business problems there are out there. As part of this we are developing a series of brain exercises that can be given to students on creative, problem solving courses to open up their minds and start them thinking outside the proverbial box. One of these exercises is called What Would Google Do? The idea being to try and get them to take the non-conventional, Google, view of how to solve a problem. By way of an example Douglas Edwards, in his book I’m Feeling Lucky – The Confessions of Google Employee Number 59, relates the following story about how Sergey Brin, co-founder of Google, proposed an innovative approach to marketing.“Why don’t we take the marketing budget and use it to inoculate Chechen refugees against cholera. It will help our brand awareness and we’ll get more new people to use Google.”

Just how serious Brin was being here we’ll never know but you get the general idea; no idea is too outrageous for folk in the Googleplex.

To further backup how serious Google are about creativity their chairman Eric Schmidt, delivered a “devastating critique of the UK’s education system and said the country had failed to capitalise on its record of innovation in science and engineering” at this year’s MacTaggart lecture in Edinburgh.  Amongst other criticisms Schmidt aimed at the UK education system he said that the country that invented the computer was “throwing away your great computer heritage by failing to teach programming in schools ” and was flabbergasted to learn that today computer science isn’t even taught as standard in UK schools. Instead the IT curriculum “focuses on teaching how to use software, but gives no insight into how it’s made.” For those of us bought up in the UK at the time of the BBC Microcomputer hopefully this guy will be the saviour of the current generation of programmers.

US readers of this blog should not feel too smug, check out this YouTube video from Dr. Michio Kaku who gives an equally devastating critique of the US education system.

So, all in all, I think the world definitely needs more of a versatilist approach, not only in our education systems but also in the ways we approach problem solving in the workplace. Steve Jobs, the chief executive of Apple, who revealed last week that he was stepping down once told the New York Times: “The Macintosh turned out so well because the people working on it were musicians, artists, poets and historians – who also happened to be excellent computer scientists”. Once again Apple got this right several years ago and are now reaping the benefits of that far reaching, versatilist approach.

Creative Leaps and the Importance of Domain Knowledge

Peter Cripps creativity , , ,

Sometimes innovation appears to come out of nowhere. Creative individuals, or companies, appear to be in touch with the zeitgeist of the times and develop a product (or service) that does not just satisfy an unknown need but may even create a whole new market that didn’t previously exist. I would put James Dyson (bagless vacuum cleaner) as an example of the former and Steve Jobs/Apple (iPad) as an example of the latter.Sometimes the innovation may even be a disruptive technology that creates a new market where one previously did not exist and may even destroy existing markets. Digital photography and its impact on the 35mm film producing companies (Kodak and Ilford) is a classic example of such a disruptive technology.

Most times however creativity comes from simply putting together existing components in new and interesting ways that meet a business need. For merely mortal software architects if we are to do this we not only need a good understanding of what those components do but also how the domain we are working in really, really works. You need to not only be curious about your domain (whether it be financial services, retail, public sector or whatever) but be able to ask the hard questions that no one else thought or bothered to ask. Sometimes this means not following the herd and being fashionable but being completely unfashionable. As Paul Arden, the Creative Director of Saatchi and Saatchi said in his book Whatever You Think, Think The Opposite:

People who create work that fashionable people emulate do the very opposite of what is in fashion. They create something unfashionable, out of time, wrong. Original ideas are created by original people, people who either through instinct or insight know the value of being different and recognise the commonplace as a dangerous place to be.

So do you want to be fashionable or unfashionable?

Think Like An Architect

Peter Cripps architecture , , , ,

A previous entry suggested hiring an architect was a good idea because architects take existing components and assemble them in interesting and important ways. So how should you “think architecturally” in order to create things that are not only interesting but also solve practical, real-world problems? Architectural thinking is about balancing three opposing “forces”: what people want (desirability), what technology can provide (feasibility) and what can actually be built given the constraints of cost, resource and time (viability).

It is basically the role of the architect to help resolve these forces by assembling components “in interesting ways”. There is however a fourth aspect which is often overlooked but which is what separates great architecture from merely good architecture. That is the aesthetics of the architecture.
Aesthetics is what separates a MacBook from a Dell, the Millau Viaduct in France from the Yamba Dam Bridge in Japan and the St Mary Axe from the Ryugyong Hotel in North Korea. Aesthetics is about good design which is what you get when you add ‘significance’ (aesthetic appeal) to ‘utility’ (something that does the job). IBM, the company I work for, is 100 years old this year (check out the centennial video here) and Thomas Watson, IBM’s founder, famously said that “good design is good business”. Watson knew what Steve Jobs, Tim Brown and many other creative designers know; aesthetics is not only good for the people that use or acquire these computers/buildings/systems it’s also good for the businesses that create them. In a world of over-abundance good design/architecture both differentiates companies as well as giving them a competitive advantage.

Learning Architecture (Or Anything Really)

Peter Cripps architecture , ,

I spent most of 2010 travelling the world teaching Architectural Thinking for a client. (Here is a reasonable description of some of what this covers. It’s the best publicly available description I can find but please contact me if you would like more information on this class).I always reckon that you learn just as much as a teacher as you do as a student (or should do) so here’s some stuff I learnt myself. This is not rocket science and many people may consider this obvious but for those for whom this is not the case I hope you find it useful.

  1. People learn best when they have some fun. This doesn’t mean you have to be a great comedian to deliver an effective training class however it does help if you can arrange some fun activities as part of the learning. Quizzes (that also inject an element of competition) work well as a way of re-enforcing peoples learning.
  2. Ensure that at least half the time (and preferably two thirds of it) are spent on getting the attendees to do something. This does not have to be a full-blown case study (though you certainly need one of those) but should at least include plentiful opportunities for discussions and Q&A sessions (where the questions are not just asked by the students).
  3. Less really is more. When delivering a lecture, or a complete class, especially one you are very familiar with. It is tempting to cram more and more information in as you deliver more classes. People ask a question, you answer it and think “hey, why don’t I create a slide for that for next time”. Don’t. Slide-creep is one of the great evils of our time. Rather thank thinking “what can I add” think “what can I remove”. Hand out detail as additional reading. Keep the main-deal brief.
  4. Try, whenever you can, to tell stories rather than deliver dry facts. For me a teacher is, above all else, an experienced practitioner. Introducing your own “war stories” at appropriate points is what makes a great and teacher.
  5. Great public speakers (Richard Feynman, Steve Jobs, Banjamin Zander) inject passion into what they have to say. If you are not passionate about what you are saying then maybe you should not be standing up in front of others saying it! Think about what first made you interested in the topic you are delivering and weave that into the storyline. Injecting some of your personal self into a subject helps engage the audience and make them believe in what you have to say.

Finally take a look at this great advice from Seth Godin on organising a retreat. It may not be a full blown retreat you are organising but it contains great advice for just about any learning event where you want to get the best out of people.

Five Inspirational Videos

Peter Cripps comment , , , , ,

As a follow-up to my six non-IT books here are five videos I have found some inspiration from recently (plus one that whilst cannot be described as inspirational is at least amusing in a vaguely nerdy programmer kind of way):

  1. Steve Jobs (A CEO): How to Live Before You Die Steve Jobs steps out from his usual Apple presentation mode and delivers this keynote to students at Stanford. He highlights three things which have had a major impact on his life and how important it is to learn from such life experiences.
  2. Winston Royce (A Methodologist): The Rise and Fall of Waterfall Not actually by Winston Royce but a humorous look at how we ended up with waterfall. An example of how to get a point across by telling a story (and using wonderfully simple graphics).
  3. Grady Booch (A Software Architect): The Promise, The Limits, The Beauty of Software Grady is an inspirational speaker on all things software related. We were lucky enough to get him to write the forword to our book (which I’m sure has done its sales the world of good).
  4. Sir Ken Robinson (An Innovator and Educationalist): Do Schools Kill Creativity SKR (as he calls himself on his website) has some strong views on how our present education system is letting down youngsters.For a great rendition of another of Sir Ken’s talks see here.
  5. David Eustace (A Photographer): In Search of Eustace Nothing to do with IT but related to one of my other passions. This simple and beautifully filmed video set to music will resonate with anyone on life’s journey.

And finally…

  1. Lady Gaga (A Singer) Lookalike: Sings About Java Programming An example of how creativity (the video production) can be used to improve even the worst ideas (the song). What else can I say!

Six Non-IT Books for IT Architects

Peter Cripps architecture , , , , ,

There are now several myriad books out there on the topic of software architecture, including this one I have contributed to. There are other skills an architect needs to do their job which are not just to be found in IT books however. Here are six books which have helped me in my job together with a few reasons why I think they are useful:

  1. Change by Design by Tim Brown. Tim Brown is the CEO of IDEO a design company based in Palo Alto, California. Introduces the concepts of “design thinking” that can be applied to any problem and shows how empathy, play, storytelling and prototyping can all be bought together in coming up with new and innovative designs. Top tip: Deploy interdisciplinary teams of multi-talented people (i.e. true versatilists) to solve hard design problems. Even if you don’t get the book at least visit the link I’ve given to view the wonderful mid map.
  2. Presentation Zen by Garr Reynolds. Garr is the master of giving advice on how to create simple, clear and relevant presentations. Here he applies the zen principles of simplicity that will change how you think about creating presentations using PowerPoint or Keynote. Top tip: Picture superiority effect. Pictures are remembered better than words. Humans are hardwired for using images to communicate. Go visual wherever and whenever you can.
  3. A Whole New Mind by Dan Pink. Dan describe how, if we are to survive in the 21st century world of work, we must make more use of the left side, the creative side, of our brain rather than the traditional right (logical thinking) side. Top tip: Use stories to help illustrate your ideas. Stories represent a pathway to understanding that doesn’t run through the left side of the brain.
  4. Notes on the Synthesis of Form by Christopher Alexander. Alexander recognises that problems come with multiple, poorly understood requirements that interact with each other, creating conflicts and contradictions. Something we in IT have known for years. This book describes an approach for dealing with often multiple conflicting requirements to come up with the “best fit” solution. Top tip: It is difficult to specify a complete set of requirements that need to be met to achieve a “best fit”. A practical approach is to define ‘good fit’ as the absence of ‘misfits’, since these are usually what makes the problem obvious and can be ascertained through inspection of prior designs. Although designers may argue over the importance of a particular misfit, they are less likely to disagree on whether the misfit exists.
  5. Ignore Everybody by Hugh MacLeod. Hugh is an artist that makes a living creating art on the back of business cards, selling wine and running an extremely insightful web site on applying creativity to help you improve your job as well as your life. Top tip: Don’t try to stand out from the crowd, avoid crowds altogether.
  6. The Presentation Secrets of Steve Jobs by Carmine Gallo. Great book with lots of example on how Steve Jobs creates, prepares for and delivers his presentations to introduce new Apple gadgetry on the world. Top tip from book: Use plain English and photographs rather than techno mumbo-jumbo and slides densely packed with indecipherable text and bullet points.

It’s Easy to Spot a Purist…

Peter Cripps comment , ,

…they’re the ones with no skin in the game. I came across this whilst reading about Hugh MacLeod’s new book on his blog. It set me thinking about how true this can sometimes be from an architecture perspective. Steve Jobs famously said “real artists ship”. Whilst there is a point to building good architectural models, defining principles that should be followed and road maps that describe the directions architects will be travelling in there comes a point that we must say “enough is enough, it’s time to ship”. The fact of the matter is that software development is, and always will be, a complicated activity and there is often no clearly defined answer to the wicked problems we need our systems to address. In fact, two of the attributes of a wicked problem namely, wicked problems have no stopping rule (instead the problem solving process ends when you run out of resources rather than when some ‘correct’ solution emerges) and solutions to wicked problems are not right or wrong (they are simply better, worse, good enough or not good enough) would seem to encourage the kind of purist behaviour where nothing ever ships. The danger with architecture (especially Enterprise Architecture) is that the artefacts being created are intangible things like models, road maps and principles and these by themselves do not make working systems. The people that produce such artefacts could often be accused of having “no skin in the game”. So how should you ensure that the architects in your organisation do indeed have skin in the game and knows that shipping is actually all that matters? Here is my SKIN (Specify Kill Integrate Negate) rule of thumb for ensuring delivery takes protracted (and unnecessary) analysis.

  • Specify to the right level of abstraction and detail, no more no less. The models, road maps, architectural principles that are defined by architects should be understood and usable by as many stakeholders as possible. This may mean having different views (levels of abstraction) of the same model but ensure if this is the case, those views are consistent. Think who your stakeholder is meant to be before building the artefacts and don’t build it if you can’t explain it clearly to that stakeholder.
  • Kill unwanted artefacts. Sometimes with the best will in the world you will build an artefact that does not have a purpose, is not read by anyone or has expired. Kill it, don’t let it linger on causing confusion and giving you an unnecessary maintenance overhead. Look at something like TOGAF for a good set of useful artefacts.
  • Integrate the work of the architect(s) with real downstream activities. Don’t let them work in ivory towers which have no grounding in reality. When planning a project and considering what artefacts need to be planned it is useful to think of what the inputs are to the task that is to create the artefact. If you cannot see any of the artefacts that are output from architecture tasks being used than maybe it’s time to consider killing off those artefacts (see above).
  • Negate unnecessary activities and tasks. Every task should have an output. This is usually in the form of a work product (a model, a piece of code, a plan or whatever). If you find you have some architecture tasks or activities (groups of relates tasks) that are not producing useful artefacts then its probably time stop performing those tasks.

How to Create Artitecture

Peter Cripps architecture , , ,

Forgive me for pushing yesterdays entry a bit further but I really like the idea of creating architectures that come from more of a right-brained way of thinking. So how should artitects go about creating an artitecture?

  1. Thrash early. Thrashing is a term used to describe the creative brainstorming process that happens during a project. Seth Godin in his book “Linchpin – Are You Indispensable?” says that amateurs thrash late whereas as professional thrash early. Late thrashing introduces bugs which are better to identify early rather than later.
  2. Make mistakes and learn from them. Like Fred Brooks said: “plan to throw one away; you will anyhow”. Use prototypes to understand how new and technically challenging components work but treat these as throwaways not release 1.0!
  3. Deliver (ship) something. According to Steve Jobs “real artists ship”. Delivering something (anything) on time and within budget is one of the great challenges of software development. Time or money (or both) usually run out before anything is delivered. Here’s a different way of looking at it though. Why not see the time/money constraint as a positive rather than a negative aspect of a project? So, if you have to produce something on time and within budget it’s quite simple really. Just work until the time/money run out then deliver something.
  4. Read the rule-book, but then change it. For software development projects the “rule book” is usually the process that is meant to be followed. However it’s important to recognise that there is no “one size fits all” when it comes to SDLC (software delivery lifecycles). SDLCs are good but don’t follow them too slavishly. Be ready and prepared to customise them to your needs. A good SDLC will have this flexibility.
  5. Seek forgiveness not permission. I got this from an ex-colleague. In many companies today you are overwhelmed by (often) petty rules of engagement. If you always follow the rules that are supposedly “needed” to get a piece of work done then you won’t deliver. You’ll have done your job (followed the rules) but won’t have done the work that your client wants. Better is to not follow every rule and ask permission for doing something but to just do it and ask for forgiveness when the rules get broken (unless those rules are there to keep you out of prison of course).

Okay here’s the real irony in the above. If you read and believe my point number two from yesterday (artitects don’t follow the process in the manual, instead they write the manual) you won’t be following any of the above; instead you’ll be creating your own way of doing artitecture.