IT | Office | Society | World | Self

Information Technology Science is not truth; it is, instead, a method for diminishing ignorance. --J.M. Adovasio, Olga Soffer, Jake Page Hard Skills Four Areas To be a well-rounded IT professional, I figure that one needs to grasp the basics of four worlds: programming, operating systems, networking, and databases. From programming, one learns concepts like error checking and boundary testing. From operating systems, one learns about resource contention and dead-locks. From networking, one learns how to build reliable systems on top of an unreliable world. And from databases, one learns the need for consistency along with powerful applications for set theory. To illustrate the benefit of fluency in all four of these languages, consider how the networking professional, who sees dropped packets as normal, and database professionals, who see databases as either entirely consistent or entirely broken ... can look at one another in dismay. Or how the networking professional can utilize the concepts of boundary checking and resource contention when analyzing client/server interactions. Architectural Thinking Root Cause Analysis For a successful technology, reality must take precedence over public relations, for Nature cannot be fooled. --Richard Feynman IT, like all human endeavours, is plagued by 'magical thinking', the tendency of the human brain, immersed as it is in a foaming stew of hormones, to skip rational thought and to interpret the world in fantastical ways. Fortunately, reality is the ultimate arbiter of such confusions. Thinking analytically is a learned skill, and I see this skill as the foundation to my IT efforts. In this presentation, I make a case for employing reason, rather than faith, based arguments. In this seminar, I present my view of how to apply analytical thinking to solving IT problems. Introductions to critical thinking: Don't Believe Everything You Think by Thomas Kida and How Do We Know It's True? by Hy Ruchlis Carl Sagan reviews the underpinnings of analytical thinking in The Demon-Haunted World. Edward Tufte illustrates clear reasoning about data in his books: Beautiful Evidence, The Visual Display of Quantative Evidence, Envisioning Information, and Visual Explanations. My notes from one of his lectures, along with an example of how I employ these skills. Credible explanations grow from the combined testimony of three more or less independent, mutually reinforcing sources -- explanatory theory, empirical evidence, and rejection of competing alternative explanations. --Edward Tufte Patterns John Day A long timer player in the 'Net landscape, Day distills his experience into patterns. Patterns in Network Architecture: A Return to Fundamentals These two types of protocols [data transfer and application] tend to alternate in architectures. The MAC layer does relaying and multiplexing, the data link layer does "end-to-end" error control; the network layer relays, the transport layer does endot-end error control; mail protocols relay, hmmm no end-to end error control and somtimes mail is lost ... Design As I build, I'm always thinking: how am I going to fix this when it breaks? And I modify the design as I go, to make sure that I can get at it, easily, years from now, when it breaks. -- Dave, who renovates houses for a living These authors describe ways of thinking about IT design which fit my world-view. Henry Petroski A mechanical engineer, Petroski suggests building failure into the design process, in order to achieve success. Success Through Failure: The Paradox of Design When a complex system succeeds, that success masks its proximity to failure. Imagine that the Titanic had not struck the iceberg on her maiden voyage. The example of that "unsinkable" ship would have emboldened success-based shipbuilders to model more and more and larger and larger ocean liners after her. Eventually, albeit by chance, the Titanic or one of those derivative vessels would likely have encountered an iceberg -- with obvious consequences. Thus, the failure of the Titanic contributed much more to the design of safe ocean liners than would have her success. That is the paradox of engineering and design. ... the only way to test definitively a large civil engineering structure is to build it in anticipation of how nature will challenge it and then let nature take its course. This fact of large-scale engineering demands careful, proactive failure analyses. Things that succeed teach us little beyond the fact that they have been successful; things that fail provide incontrovertible evidence that the limits of design have been exceeded. Emulating success risks failure; studying failure increases our chances of success. The simple principle that is seldom explicitly stated is that the most successful designs are based on the best and most complete assumptions about failure. Over the years, shuttle managers had treated each additional debris strike not as evidence of failure that required immediate correction, but as proof that the shuttle could safely survive impacts that violated its design specifications. --Diane Vaughan Fail early and often. Theo Schlossnagle A partner at Omniti, Schlossnagle designs and installs large-scale IT environments supporting e-commerce. Scalable Internet Architectures The architecture must allow operations and development teams to watch things break, spiral out of control, and otherwise croak. Watching these things happen leads to understanding the cause and in turn leads to solutions. Stuart Kendrick My contributions to applying design principles to IT endeavors. Long Road to High-Availability Architecture in Action Testing Highly Available Hardware Musings on Hierarchical Network Design Miscellaneous Links The Internet is a Collection of End-Points by Searls and Weinberger Infrastructures.org by Traugott and Huddleston Empirical System Reliability by Bianca Schroeder et al. Failure Trends in a Large Disk Drive Population by Pinheiro, Weber, and Barroso The Athens Affair (Hacking a Cellphone Operator or Lessons in Logging) by Vassilis Prevelakis and Diomidis Spinellis IT Infrastructure Library I have a few days of basic ITIL training under my belt; our department has just begun to introduce ITIL thinking into how we deliver service. Programming I aspire to these approaches to designing and writing code. The CRC Card Book by David Bellin and Susan Suchman Simone The Pragmatic Programmer by Andrew Hunt and David Thomas Perl Best Practices by Damian Conway Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. --Brian Kernighan Operating Systems The basics, as described by three leading players in the field of operating system design. Operating System Concepts by Silberschatz, Galvin, Gagne