Brad's Books and Organizations

Books

Books

Organizations

Organizations

Hi, I’m Brad Feld, a managing director at Foundry Group who lives in Boulder, Colorado. I invest in software and Internet companies around the US, run marathons and read a lot.

« swipe left for tags/categories

swipe right to go back »

Why Does This Slide Suck?

Comments (6)

I have seen my lifetime supply of slides like the following:

Companydataafter

My good friend Bruce Wyman – the Director of Technology at the Denver Art Museum – has a thoughtful post up this morning titled Simplification of Things, Part 1 of Some.  In it, he shows us a better way to communicate what this slide doesn’t.

Categories: Pet Peeves
  • http://www.kidmercuryblog.com kid mercury

    seth also had a great post on how to make great presentations: http://sethgodin.typepad.com/seths_blog/2007/01/r…

  • sigmawaite

    System 'architecture' diagrams CAN be useful, but there is no end of ways to make a mess, and this slide is an example.

    What was good was just the text that explained that they had many data 'silos' and wanted to get many analyzes that used data from multiple silos. The good news was that they understood what was in the silos, i.e., likely had meaningful descriptions of the data base 'schemas'.

    So, here's a 'simple' description in just a few words: On the left they had a lot of silos, and on the right they had a lot of users who needed analyzes. Then they wanted to put a computer-based system in the middle to ease the work of satisfying the users. Okay; at times there can be a point to such an intermediate system.

    An example is IBM's Resource Object Data Manager (RODM), and the start-up Kabira has at least some of the functionality, but in the case of RODM the reasons were (A) the systems on the left were not necessarily data bases but any systems, e.g., in a server farm or network, that needed to be 'managed', (B) the system in the middle could 'cache' data from systems on the left and, thus, reduce query loads on those systems from applications on the right, (C) the system in the middle could let the systems on the right 'subscribe' to changes in the data on the left and, thus, reduce 'polling' looking for such changes, and most important (D) the system in the middle could present to the systems on the right a 'virtual' view of the systems on the left but with security, locking, transactional integrity, deadlock detection, and automatic deadlock resolution, at times important for systems management applications (on the right). Or, for (D), can have many independently developed applications on the right that still do not 'get in each other's way' in their interactions with the systems on the left. When want such functionality, then may want the system in the middle. But if can't point to some such important functionality, then don't need the system in the middle.

    Here are some problems with the figure and its description:

    (1) They overdid the undefined TLAs, that is, three letter acronyms.

    (2) They omitted any solid reason for the intermediate system. That is, it's easy enough for any PC to do a data base query of any data base the PC can get to with connectivity and privileges, e.g., passwords. So, without more explanation, all that is needed in the middle is just a communications network, e.g., a LAN or the Internet. For more, the data base systems could have some stored procedures or triggers that helped the applications.

    (3) They swept under the rug what is likely the biggest challenge — doing the applications software that goes from the data to the results the users need. They just said “decision support”, and from the explanations they gave that is the 800 pound gorilla in the room, not getting the data from the silos.

    E.g., if they are a 'job shop' then they may have a job scheduling problem to (1) let the sales staff rapidly give time and cost estimates to prospective customers, (2) have the shop get the work done on time, and (3) not have wasted motion in the shop. While this problem is real, it is well known to be NP-complete — i.e., a gorilla.

  • http://sophisticatedfinance.typepad.com Robert Hacker

    Steven Koslyn's book–Clear and to the Point–is an excellent, practical book on visual presentation. http://sophisticatedfinance.typepad.com/sophistic…

  • John

    You're first comment hit home to me. I could change some text and use that diagram to represent a couple of hundred different system I've seen in vendor presentations.

  • http://www.slideology.com Nancy Duarte

    It's amazing how many of us use PowerPoint to communicate but so few are trained as visual communicators. Business schools don't teach us how to transfer our ideas visually so we read bullets or create charts like this that mean NOTHING to the audience but have become a creepy mnemonic device for the presenter. We really need to think away from PowerPoint and try to walk in the shoes of our audience. http://www.vizthink.com/blog/2008/06/18/webinar-c…

  • Gigs

    I think slides like that are what killed Byte magazine back in the day. Well, that and blatant Java fanboism.

  • Robert Hacker

    Steven Koslyn's book–Clear and to the Point–is an excellent, practical book on visual presentation. http://sophisticatedfinance.typepad.com/sophistic…

  • http://intensedebate.com/people/kidmercury kidmercury

    seth also had a great post on how to make great presentations: http://sethgodin.typepad.com/seths_blog/2007/01/r…

  • http://intensedebate.com/people/sigmawaite sigmawaite

    System 'architecture' diagrams CAN be useful, but there is no end of ways to make a mess, and this slide is an example.

    What was good was just the text that explained that they had many data 'silos' and wanted to get many analyzes that used data from multiple silos. The good news was that they understood what was in the silos, i.e., likely had meaningful descriptions of the data base 'schemas'.

    So, here's a 'simple' description in just a few words: On the left they had a lot of silos, and on the right they had a lot of users who needed analyzes. Then they wanted to put a computer-based system in the middle to ease the work of satisfying the users. Okay; at times there can be a point to such an intermediate system.

    An example is IBM's Resource Object Data Manager (RODM), and the start-up Kabira has at least some of the functionality, but in the case of RODM the reasons were (A) the systems on the left were not necessarily data bases but any systems, e.g., in a server farm or network, that needed to be 'managed', (B) the system in the middle could 'cache' data from systems on the left and, thus, reduce query loads on those systems from applications on the right, (C) the system in the middle could let the systems on the right 'subscribe' to changes in the data on the left and, thus, reduce 'polling' looking for such changes, and most important (D) the system in the middle could present to the systems on the right a 'virtual' view of the systems on the left but with security, locking, transactional integrity, deadlock detection, and automatic deadlock resolution, at times important for systems management applications (on the right). Or, for (D), can have many independently developed applications on the right that still do not 'get in each other's way' in their interactions with the systems on the left. When want such functionality, then may want the system in the middle. But if can't point to some such important functionality, then don't need the system in the middle.

    Here are some problems with the figure and its description:

    (1) They overdid the undefined TLAs, that is, three letter acronyms.

    (2) They omitted any solid reason for the intermediate system. That is, it's easy enough for any PC to do a data base query of any data base the PC can get to with connectivity and privileges, e.g., passwords. So, without more explanation, all that is needed in the middle is just a communications network, e.g., a LAN or the Internet. For more, the data base systems could have some stored procedures or triggers that helped the applications.

    (3) They swept under the rug what is likely the biggest challenge — doing the applications software that goes from the data to the results the users need. They just said "decision support", and from the explanations they gave that is the 800 pound gorilla in the room, not getting the data from the silos.

    E.g., if they are a 'job shop' then they may have a job scheduling problem to (1) let the sales staff rapidly give time and cost estimates to prospective customers, (2) have the shop get the work done on time, and (3) not have wasted motion in the shop. While this problem is real, it is well known to be NP-complete — i.e., a gorilla.

  • John

    You're first comment hit home to me. I could change some text and use that diagram to represent a couple of hundred different system I've seen in vendor presentations.

  • Nancy Duarte

    It's amazing how many of us use PowerPoint to communicate but so few are trained as visual communicators. Business schools don't teach us how to transfer our ideas visually so we read bullets or create charts like this that mean NOTHING to the audience but have become a creepy mnemonic device for the presenter. We really need to think away from PowerPoint and try to walk in the shoes of our audience. http://www.vizthink.com/blog/2008/06/18/webinar-c…

  • Gigs

    I think slides like that are what killed Byte magazine back in the day. Well, that and blatant Java fanboism.

Build something great with me