five things

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!

Five Things Not To Say When Presenting

Peter Cripps presenting

Whilst I cannot confess to have never said any of these myself here are five phrases that you should avoid at all costs when delivering a technical (or indeed any) presentation.

  1. I’m sorry you can’t see this at the back. Are you really sorry? I suspect not otherwise you will have made sure everyone could see what you are presenting before showing the slide. Know how big your room is and how big the screen is. As a matter of course never make any font size less than 24 point. Better still avoid words altogether and use pictures or diagrams instead.
  2. I’m just going to skip over the next few slides. Why? Either the slides are relevant to what you have to say or they are not. If they are not then they should not be there. There is always a great temptation to include extra slides “just in case”. Don’t! You should include only that which is relevant to what you have to say and discard everything else.
  3. Sorry but the colours on this slide don’t show up very well. Using colour in presentations is a great way of getting across information. When used properly colour can be used for emphasis as well as categorising data or information. However, be aware that the way colour can appear on a computer screen and how it can appear on a data projector can be very different. Always use bold colours and, if possible, check out the projector you are going to use before starting your presentation.
  4. You probably can’t hear this but I’ll play it anyway. Use of sound and video can be a great way of getting information across and also helps to keep your audiences attention. However if you are using sound make sure you have an effective sound system and don’t, what ever you do, rely on the speakers on your laptop. If you are using sound or video make sure there is adequate kit in the room. As a standby carry a set of portable speakers with you but these will only have limited reach.
  5. I’ve only got 30 minutes and we need t get through 75 slides. Or any other large number that will be impossible in the given time. Actually there is no golden rule for how many slides you can present in a given amount of time. If each slide has only a single word or picture then 75 slides in 30 minutes is entirely reasonable. However most times those 75 slides are densely packed with information which is impossible to assimilate in the amount of time allotted. As I’ve said elsewhere don’t pack too much information into your presentation. Instead just focus on the key points and use handouts for detailed stuff.

Why Didn’t I Do That?

Peter Cripps architecture, creativity ,

You know how annoying it is when someone does something that is so blindingly obvious in retrospect you ask yourself the question “why didn’t I do that”? I’m convinced that the next big thing is not going to be the invention of something radically new but rather a new use of some of the tools we already have. When Tim Berners-Lee invented the world-wide web he didn’t create anything new. Internet protocols, mark-up languages and the idea of hypertext already existed. He just took them and put them together in a radically new way. What was the flash of inspiration that led to this and why did he do it and not someone else? After all that is basically the job of a Solution Architect, to apply technology in new and innovative ways that address business problems. So why did Tim Berners-Lee invent the world-wide web and not you, I or any of the companies we work for? Here are some observations thoughts.

  1. Tim had a clear idea of what he was trying to do. If you look at the paper Berners-Lee wrote, proposing what became the world-wide web, the first thing you’ll see it has a very clear statement of what it is he’s trying to do. Here is his statement of the problem he’s trying to solve together with an idea for the solution: Many of the discussions of the future at CERN and the LHC era end with the questions – “Yes, but how will we ever keep track of such a large project?” This proposal provides an answer to such questions. Firstly, it discusses the problem of information access at CERN. Then, it introduces the idea of linked information systems, and compares them with less flexible ways of finding information. It then summarise my short experience with non-linear text systems known as “hypertext”, describes what CERN needs from such a system, and what industry may provide. Finally, it suggests steps we should take to involve ourselves with hypertext now, so that individually and collectively we may understand what we are creating. Conclusion: Having a very idea or vision of what it is you are trying do helps focus the mind wonderfully and also helps to avoid woolly thinking. Even better is to give yourself a (realistic but aggressive) timescale in which to come up with a solution.
  2. Tim knew how to write a mean architecture document. The paper describing the idea behind what we now call “the web” (Information Management: A Proposal) is a masterpiece in understated simplicity. As well as the clear statement on what the problem is the paper goes on to describe the requirements that such an information management system should have as well as the solution, captured in a few beautifully simple architecture overview diagrams. I think this paper is a lesson to all of us in what a good architectural deliverable should be.
  3. Tim didn’t give up. In his book Weaving the Web Berners-Lee describes how he had a couple of abortive attempts at convincing his superiors of the need for his proposal for an information management system. Conclusion: Having a great idea is one thing. If you can’t explain that idea to others who, for example have the money to fund it, then you may as well not have that idea. Sometimes getting your explanation right takes time and a few attempts. The moral here is don’t give up. Learn from your failures and try again. It will test your perseverance and the faith you have in your idea but that is probably what you need to convince yourself it’s worth doing.
  4. Tim prototyped. Part of how Tim convinced people of the worth of what he was doing was to build a credible prototype of what it was he wanted to do. Tim was a C programmer and used his NeXT computer to build a working system of what it was he wanted to do. He actively encouraged his colleagues to use his prototype to get them to buy into his idea. Having a set of users already in place who are convinced by what you are doing, is one sure fire way of promoting the worth of your new system.
  5. Tim gave it all away. In may ways this is the most incredible thing of all about what Tim Berners-Lee did with the web; he gave it all away. Imagine if he patented his idea and took a ‘cut’ which gave him 0.00001¢ every time someone did a search or hit a page (I don’t know if this is legally possible, I’m no lawyer, but you get the idea). He would be fabulously rich beyond any of our most wildest dreams! And yet he (and indeed CERN) decided not to go down this path. This has surely got to be one of the all time most altruistic actions that anyone has ever taken.

Five Tips on How to Think Like a Designer

Peter Cripps comment , ,

I got this idea from Garr Reynolds blog entry 10 Tips on how to think like a designer. Ten is too large a number for my simple brain so instead I’ve picked the five that I think we as software architects can most learn from the world of design.

  1. Embrace constraints. An architect often complains about the constraints and limitations she has to work under (especially those related to money, time and resource). The skill is to accept constraints and figure out what you can do with the resources you have. After all, a completely unbounded problem with total freedom on how to solve it is likely to end up never being solved. Remember how the NASA engineers managed to fix the Apollo 13 CO2 filter problem using just what they knew was available on the spacecraft. Now that’s embracing constraints.
  2. Practice restraint. This is related to the previous one. As Reynolds says: “any fool can be complicated and add more, it takes discipline of mind and strength of will to make the hard choices about what to include and what to exclude”. As software architects we are often overwhelmed with choice when putting together a solution. There are often many different vendors software products and packages from which to choose and, of course software, by definition, is malleable and can be shaped in many different ways. The trick here then is to practice self-constraint and go for simplicity rather than complexity and cleanness of form rather than clutter and obfuscation.
  3. Check your ego at the door. Ultimately all software, no matter how deeply imbedded or how far it is along the food chain, has an end user to cope with. How that user interacts with and understands the system of which your software is a part depends on how well designed it is. The software architect usually has many different people to deal with (people who use the system directly, people who must maintain the system, people who need to ensure the system is secure, the list goes on). Each of these people has a “stake” in the system (hence the name we some refer to them by as “stakeholders”) and a good architect understands the needs of these stakeholders and is empathetic towards those needs. Empathy is a difficult soft-skill to master but is very important to acquire. It is so important that Dan Pink in his book A Whole New Mind states it as one of the key differentiators that will mark out those people who are able to survive the 21st century world of work where everything is outsourced, commoditised or performed more cheaply by a computer.
  4. Become a master storyteller. You may have just devised the greatest software architecture the world has ever seen but if you cannot sell that solution it’s not going to be any good to anyone and will most likely never see the light. Much software is, by its very nature, complex and describing what it does and what are its benefits can be difficult. Storytelling, that is weaving a story around your system by illustrating it verbally and using multi-media to back up what you are saying can help. Don’t rely on complex and overly-cluttered PowerPoint slides when trying to describe what the system does but instead relate it to everyday experiences your audience are likely to identify with.
  5. Obsess about ideas not tools. As Reynolds says: “tools are important and necessary, but they come and go as better tools come along”. Probably no discipline is more blessed (sic) with tools than ours is. Whilst tools are clearly important to the software architect remember they are a means to an end so don’t sweat over them too much. Instead concentrate on the ideas and use pencils and paper or whiteboards and pens to capture your ideas. These also have the benefits of being readily available and don’t suffer from expired batteries.