no silver bullet

20 results back to index

The Computer Boys Take Over: Computers, Programmers, and the Politics of Technical Expertise by Nathan L. Ensmenger

barriers to entry, business process, Charles Babbage, Claude Shannon: information theory, computer age, deskilling, Donald Knuth, Firefox, Frederick Winslow Taylor, functional programming, future of work, Grace Hopper, informal economy, information retrieval, interchangeable parts, Isaac Newton, Jacquard loom, job satisfaction, John von Neumann, knowledge worker, Larry Ellison, loose coupling, machine readable, new economy, no silver bullet, Norbert Wiener, pattern recognition, performance metric, Philip Mirowski, post-industrial society, Productivity paradox, RAND corporation, Robert Gordon, scientific management, Shoshana Zuboff, sorting algorithm, Steve Jobs, Steven Levy, systems thinking, tacit knowledge, technological determinism, the market place, The Theory of the Leisure Class by Thorstein Veblen, Thomas Kuhn: the structure of scientific revolutions, Thorstein Veblen, Turing machine, Von Neumann architecture, world market for maybe five computers, Y2K

Thomas Wise, “IBM’s $5,000,000,000 Gamble,” Time, September 1966, 226. 36. Thomas Watson Jr., cited in Campbell-Kelly and Aspray, Computer, 199. 37. Frederick Brooks, cited in Campbell-Kelly and Aspray, Computer, 200; Emerson Pugh, Lyle Johnson, and John Palmer, IBM’s 360 and Early 370 Systems (Cambridge, MA: MIT Press, 1991). 38. Frederick P. Brooks, The Mythical Man-Month: Essays on Software Engineering (New York: Addison-Wesley, 1975), 17. 39. Ibid., 31. 40. Ibid., 34–35. 41. Ibid., 42, 7. 42. Frederick P. Brooks, “No Silver Bullet: Essence and Accidents of Software Engineering,” IEEE Computer 20, no. 4 (1987), 10–19. 43. F. Terry Baker and Harlan Mills, “Chief Programmer Teams,” Datamation 19, no. 12 (1973): 198–199. 44.

…

The adoption of metalanguages and the BNF allowed for the rapid development and implementation of creative new languages and dialects. If programming was enjoyable, even more so was language design.53 No Silver Bullet In 1987, Frederick Brooks published an essay describing the major developments in automatic programming technologies that had occurred over the past several decades. As an accomplished academic and experienced industry manager, Brooks was a respected figure within the programming community. Using characteristically vivid language, his “No Silver Bullet: Essence and Accidents of Software Engineering,” reflected on the inability of these technologies to bring an end to the ongoing software crisis: Of all the monsters that fill the nightmares of our folklore, none terrify more than werewolves, because they transform unexpectedly from the familiar into horrors.

…

S Tropp, “ACM’s 20th Anniversary: 30 August 1967,” Annals of the History of Computing 9, no. 3 (1988): 269. 5. Maurice Wilkes, David Wheeler, and Stanley Gill, Preparation of Programs for an Electronic Digital Computer (Reading, MA: Addison-Wesley, 1951). 6. Richard Wexelblat, ed., History of Programming Languages (New York: Academic Press, 1981), 10. 7. Frederick P. Brooks, “No Silver Bullet: Essence and Accidents of Software Engineering,” IEEE Computer 20, no. 4 (1987), 10–19. 8. Remington Rand Univac. An Introduction to Programming the UNIVAC 1103A and 1105 Computing Systems (1958) Hagley Museum Archives, Accession 1825, Box 368. 9. John Backus, cited in Wexelblat, History of Programming Languages, 82. 10.

Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software by Scott Rosenberg

A Pattern Language, AOL-Time Warner, Benevolent Dictator For Life (BDFL), Berlin Wall, Bill Atkinson, c2.com, call centre, collaborative editing, Computer Lib, conceptual framework, continuous integration, Do you want to sell sugared water for the rest of your life?, Donald Knuth, Douglas Engelbart, Douglas Engelbart, Douglas Hofstadter, Dynabook, en.wikipedia.org, Firefox, Ford Model T, Ford paid five dollars a day, Francis Fukuyama: the end of history, Free Software Foundation, functional programming, General Magic , George Santayana, Grace Hopper, Guido van Rossum, Gödel, Escher, Bach, Howard Rheingold, HyperCard, index card, intentional community, Internet Archive, inventory management, Ivan Sutherland, Jaron Lanier, John Markoff, John Perry Barlow, John von Neumann, knowledge worker, L Peter Deutsch, Larry Wall, life extension, Loma Prieta earthquake, machine readable, Menlo Park, Merlin Mann, Mitch Kapor, Neal Stephenson, new economy, Nicholas Carr, no silver bullet, Norbert Wiener, pattern recognition, Paul Graham, Potemkin village, RAND corporation, Ray Kurzweil, Richard Stallman, Ronald Reagan, Ruby on Rails, scientific management, semantic web, side project, Silicon Valley, Singularitarianism, slashdot, software studies, source of truth, South of Market, San Francisco, speech recognition, stealth mode startup, stem cell, Stephen Hawking, Steve Jobs, Stewart Brand, Strategic Defense Initiative, Ted Nelson, the Cathedral and the Bazaar, Therac-25, thinkpad, Turing test, VA Linux, Vannevar Bush, Vernor Vinge, Wayback Machine, web application, Whole Earth Catalog, Y2K

The software that frustrates and hog-ties us also captivates us with new capabilities and enthralls us with promises of faster, better ways to work and live. There’s no going back. We need the stuff more than we hate it. So we dream of new and better things. The expert who in many ways founded the modern field of software studies, Frederick P. Brooks, Jr., wrote an influential essay in 1987 titled “No Silver Bullet,” declaring that, however frustrated we may be with the writing of computer programs, we will never find a magic, transformational breakthrough—we should expect only modest, incremental advances. Brooks’s message is hard to argue with but painful to accept, and you can’t attend a computer industry conference or browse a programmers’ Web site today without bumping into someone who is determined to prove him wrong.

…

Wilkes, Memoirs of a Computer Pioneer (MIT Press, 1985) as cited in M. Campbell-Kelly, “The Airy Tape: An Early Chapter on the History of Debugging,” Annals of the History of Computing 14: 4 (1992), pp. 18–28. That article is available at http://www.dcs.warwick.ac.uk/~mck/Personal/CampbellKelly1992.pdf. Frederick P. Brooks, “No Silver Bullet: Essence and Accidents of Software Engineering,” Computer, 20: 4 (April 1987), pp. 10–19. Also reprinted in The Mythical Man-Month Anniversary Edition (Addison Wesley, 1995). Available online at http://www-inst.eecs.berkeley.edu/~maratb/readings/NoSilverBullet.htm. CHAPTER 1 DOOMED Netscape developers as a legion of the doomed: See Jamie Zawinski, Netscape Dorm, at http://www.jwz.org/gruntle/nscpdorm.htm.

…

There was more and more code around: libraries of objects and functions and modules, increasingly available under open source licenses that meant you could tinker with them and incorporate them for free. Programmers setting out on big new projects could stand on the shoulders of ever taller giants. But they still had to decide where they wanted to go. As Frederick Brooks put it in his “No Silver Bullet” essay: “The hardest single part of building a software system is deciding precisely what to build.” Python appealed to Kapor and company for many reasons. Like the program they aimed to build, it was open source and cross-platform (the same Python program could run on Windows, Macintosh, and Linux computers).

Kill It With Fire: Manage Aging Computer Systems by Marianne Bellotti

anti-pattern, barriers to entry, business logic, cloud computing, cognitive bias, computer age, continuous integration, create, read, update, delete, Daniel Kahneman / Amos Tversky, data science, database schema, Dennis Ritchie, DevOps, fault tolerance, fear of failure, Google Chrome, Hans Moravec, iterative process, Ken Thompson, loose coupling, microservices, minimum viable product, Multics, no silver bullet, off-by-one error, platform as a service, pull request, QWERTY keyboard, Richard Stallman, risk tolerance, Schrödinger's Cat, side project, software as a service, Steven Levy, systems thinking, web application, Y Combinator, Y2K

Continue this local-global-superglobal routine until the system is where you need it to be. The deeper your team understands the system and its quirks, the more predictable the system’s behavior is on a day-to-day basis and the easier it is to make big changes. No Silver Bullets The only real rule of modernizing legacy systems is that there are no silver bullets. The rest of this chapter outlines different styles of organizing development activities. You will likely use all of them at different points on a large project. The key thing to remember is that this is a toolkit. You break down large problems into smaller problems, and you choose the tool that gives you the highest probability of success with that specific problem.

…

Contents In Detail Introduction Chapter 1: Time Is a Flat Circle Leveraging What Came Before The User as the Market Co-Creator The Mainframe and the Cloud The Flat-Rate Internet Migrating for Value, Not for Trends Chapter 2: Cannibal Code Alignable Differences and User Interfaces Unix Eats the World Inheritance Paths Leveraging Interfaces When Approaching Legacy Systems Beware Artificial Consistency Chapter 3: Evaluating Your Architecture Problem 1: Technical Debt Example: The General Ledger Problem 2: Performance Issues Example: Case Flow Management Problem 3: Stability Issues Example: Custom Configuration Stages of a Modernization Plan No Silver Bullets Full Rewrite Iteration in Place Split in Place Blue-Green The Hard Cutoff Putting It Together Chapter 4: Why Is It Hard? The Curse of Hindsight Easy and Also Impossible Overgrowth: The Application and Its Dependencies Shifting Vertically: Moving from One Abstraction Layer to Another Shifting Horizontally: Moving from One Application to Another Shifting from Client to Server Shifting Down the Dependency Tree Cutting Back the Overgrowth Automation and Conversion Transpiling Code Static Analysis A Guide to Not Making Things Harder Chapter 5: Building and Protecting Momentum Momentum Builder: The Bliss of Measurable Problems Anatomy of the Measurable Problem Momentum Killer: The Team Cannot Agree Step 1: Define a Scope Step 2: Check for Conflicting Optimization Strategies Step 3: Perform Time-Boxed Experiments Momentum Killer: A History of Failure Momentum Builder: Inspiring Urgency Protecting Momentum: A Quota on Big Decisions Protecting Momentum: Calculating Opportunity Costs The Cost of Not Adding New Features The Cost of Not Fixing Something Else The Cost of Not Deprecating in Favor of a Different Solution Chapter 6: Coming in Midstream Finding the Bleed Mess: Fixing Things That Are Not Broken Figuring Out Whether Something Needs to Be Fixed But . . .

…

Leaders of large organizations do not like hearing this, because it means they will be held accountable for outcomes that are beyond their control. It is easier to cling to a popular strategy that offers guarantees. That way, if it fails, it can be passed off as a freak occurrence no leader could have prevented. There are no silver bullets with legacy modernization; every technique in this book could fail under the wrong conditions. I’ve done my best to describe the right conditions, and the vulnerabilities of each approach, but I am limited by my knowledge and experience, which are not (and never will be) infinite. The person in the best position to find a working strategy is the person on the ground watching the gears of the system turn.

The Art of UNIX Programming by Eric S. Raymond

A Pattern Language, Albert Einstein, Apple Newton, barriers to entry, bioinformatics, Boeing 747, Clayton Christensen, combinatorial explosion, commoditize, Compatible Time-Sharing System, correlation coefficient, David Brooks, Debian, Dennis Ritchie, domain-specific language, don't repeat yourself, Donald Knuth, end-to-end encryption, Everything should be made as simple as possible, facts on the ground, finite state, Free Software Foundation, general-purpose programming language, George Santayana, history of Unix, Innovator's Dilemma, job automation, Ken Thompson, Larry Wall, level 1 cache, machine readable, macro virus, Multics, MVC pattern, Neal Stephenson, no silver bullet, OSI model, pattern recognition, Paul Graham, peer-to-peer, premature optimization, pre–internet, publish or perish, revision control, RFC: Request For Comment, Richard Stallman, Robert Metcalfe, Steven Levy, the Cathedral and the Bazaar, transaction costs, Turing complete, Valgrind, wage slave, web application

Assemblers, compilers, flowcharting, procedural programming, structured programming, “artificial intelligence”, fourth-generation languages, object orientation, and software-development methodologies without number have been touted and sold as a cure for this problem. All have failed as cures, if only because they ‘succeeded’ by escalating the normal level of program complexity to the point where (once again) human brains could barely cope. As Fred Brooks famously observed [Brooks], there is no silver bullet. The only way to write complex software that won't fall on its face is to hold its global complexity down — to build it out of simple parts connected by well-defined interfaces, so that most problems are local and you can have some hope of upgrading a part without breaking the whole.

…

* * * [114] The terms we have invented for these design traps, unlikely as they may sound, come from established hacker jargon described in [Raymond96]. [115] The distinction between accidental and optional complexity means that the categories we're discussing here are not the same as essence and accident in Fred Brooks's essay No Silver Bullet [Brooks], but they have common ancestry in philosophy. A Tale of Five Editors Now we're going to use five different Unix editors as case studies. It will be helpful to bear in mind a set of benchmark tasks as we examine these designs: Plain-text editing. Manipulating plain ASCII (or, in this internationalized age, perhaps Unicode) files with no structure known to the editor above byte level, or perhaps line level.

…

[BlaauwBrooks] Gerrit A. Blaauw and Frederick P. Brooks. Computer Architecture: Concepts and Evolution. 1997. ISBN 0-201-10557-8. Addison-Wesley. [Bolinger-Bronson] Dan Bolinger and Tan Bronson. Applying RCS and SCCS. O'Reilly & Associates. 1995. ISBN 1-56592-117-8. Not just a cookbook, this also surveys the design issues in version-control systems. [Brokken] Frank Brokken. C++ Annotations Version. 2002. Available on the Web. [BrooksD] David Brooks. Converting a UNIX .COM Site to Windows. 2000. Available on the Web. [Brooks] Frederick P. Brooks. The Mythical Man-Month. 20th Anniversary Edition.

Coders at Work by Peter Seibel

Ada Lovelace, Bill Atkinson, bioinformatics, Bletchley Park, Charles Babbage, cloud computing, Compatible Time-Sharing System, Conway's Game of Life, Dennis Ritchie, domain-specific language, don't repeat yourself, Donald Knuth, fallacies of distributed computing, fault tolerance, Fermat's Last Theorem, Firefox, Free Software Foundation, functional programming, George Gilder, glass ceiling, Guido van Rossum, history of Unix, HyperCard, industrial research laboratory, information retrieval, Ken Thompson, L Peter Deutsch, Larry Wall, loose coupling, Marc Andreessen, Menlo Park, Metcalfe's law, Multics, no silver bullet, Perl 6, premature optimization, publish or perish, random walk, revision control, Richard Stallman, rolodex, Ruby on Rails, Saturday Night Live, side project, slashdot, speech recognition, systems thinking, the scientific method, Therac-25, Turing complete, Turing machine, Turing test, type inference, Valgrind, web application

(Edinburgh University Press, 1969) Magic House of Numbers, Irving Adler (HarperCollins, 1974) “META II a Syntax-Oriented Compiler Writing Language,” D.V. Schorre in Proceedings of the 1964 19th ACM national conference, (ACM, 1964) Mindstorms: Children, Computers, and Powerful Ideas, Seymour A. Papert (Basic Books, 1993) The Mythical Man-Month: Essays on Software Engineering, Frederick P. Brooks (Addison-Wesley Professional, 1995) Principles of Compiler Design, Alfred Aho and Jeffrey Ullman (Addison-Wesley, 1977) “Proof of a Program: FIND”, C.A.R. Hoare in Communications of the ACM, Vol. 14, Issue 1 (ACM, 1971) Programming Pearls, Jon Bentley (ACM Press, 1999) Purely Functional Data Structures, Chris Okasaki (Cambridge University Press, 2008) A Retargetable C Compiler: Design and Implementation, David Hanson and Christopher Fraser (Addison-Wesley Professional, 1995) Smalltalk-80: The Interactive Programming Environment, Adele Goldberg (Addison-Wesley, 1983) Smalltalk-80: The Language & Its Implementation, David Robson and Adele Goldberg (Addison-Wesley, 1983) Structure and Interpretation of Computer Programs, Harold Abelson and Gerald Jay Sussman (MIT Press, 1996) TeX: The Program, Donald Knuth (Addison-Wesley, 1986) The Programming Language LISP: Its Operation and Applications, Edmund Berkeley and Daniel Bobrow, eds.

…

But at some point we have to have better languages. And the reason is to have proof assistants or proof systems, to have some kind of automatic verification of some claims you're making in your code. You won't get all of them, right? And the dynamic tools like Valgrind and its race detectors, that's great too. There's no silver bullet, as Brooks said, but there are better languages and we should migrate to them as we can. Seibel: To what extent should programming languages be designed to prevent programmers from making mistakes? Eich: So a blue-collar language like Java shouldn't have a crazy generic system because blue-collar people can't figure out what the hell the syntax means with covariant, contravariant type constraints.

…

But I simply don't have the capacity and speed to read through all of it, so I'd be lying if I told you I had. An old book that I think is great is The Elements of Programming Style, by Kernighan and Plauger. All the examples are in Fortran IV and PL/I, so it's a bit out-of-date. But it's amazing, given the age of the book, the ideas are all still current. Another old one is Frederick Brooks's The Mythical Man Month. It's 40 years old and still as true today as when it was written. And it's just a joy to read. Everyone should read that. The main message of the book is “adding people to a late software project makes it later,” and it's still true. But there are a lot of other important things in it.

The Mythical Man-Month by Brooks, Jr. Frederick P.

Boeing 747, Conway's law, finite state, HyperCard, Ken Thompson, machine readable, Menlo Park, Multics, no silver bullet, seminal paper, sorting algorithm, speech recognition, Steve Jobs, Strategic Defense Initiative, Tacoma Narrows Bridge, Turing machine, work culture

The Mythical Man-Month Essays on Software Engineering Anniversary Edition Frederick P. Brooks, Jr. University of North Carolina at Chapel Hill ADDISON-WESLEY Boston • San Francisco • New York • Toronto • Montreal London • Munich • Paris • Madrid Capetown • Sydney • Tokyo • Singapore • Mexico City Cover drawing: C. R. Knight, Mural of the La Brea Tar Pits. Courtesy of the George C. Page Museum of La Brea Discoveries, The Natural History Museum of Los Angeles County. Cover designer: Diana Coe. The essay entitled, No Silver Bullet, is from Information Processing 1986, the Proceedings of the IFIP Tenth World Computing Conference, edited by H.

…

Devise and maintain a career development plan for each prospect, including carefully selected apprenticeships with top designers, episodes of advanced formal education, and short courses, all interspersed with solo design and technical leadership assignments. Provide opportunities for growing designers to interact with and stimulate each other. "No Silver Bullet" Refired "No Silver Bullet" Refired Every bullet has its billet. WILLIAM III OF ENGLAND, PRINCE OF ORANGE Whoever thinks a faultless piece to see, Thinks what ne'er was, nor is, nor e'er shall be. ALEXANDER POPE, AN ESSAY ON CRITICISM Assembling a structure from ready-made parts, 1945 The Bettman Archive On Werewolves and Other Legendary Terrors "No Silver Bullet—Essence and Accidents of Software Engineering" (now Chapter 16) was originally an invited paper for the IFIP '86 conference in Dublin, and it was published in those proceedings.1Computer magazine reprinted it, behind a gothic cover, illustrated with stills from films such as The Werewolf of London.2 They also provided an explanatory sidebar "To Slay the Werewolf," setting forth the (modern) legend that only silver bullets will do.

…

We decided not to revise the original, but to reprint it untouched (except for trivial corrections) and to augment it with more current thoughts. Chapter 16 reprints "No Silver Bullet: Essence and Accidents of Software Engineering," a 1986 IFIPS paper that grew out of my experience chairing a Defense Science Board study on military software. My coauthors of that study, and our executive secretary, Robert L. Patrick, were invaluable in bringing me back into touch with real-world large software projects. The paper was reprinted in 1987 in the IEEE Computer magazine, which gave it wide circulation. "No Silver Bullet" proved provocative. It predicted that a decade would not see any programming technique that would by itself bring an order-of-magnitude improvement in software productivity.

Beautiful Architecture: Leading Thinkers Reveal the Hidden Beauty in Software Design by Diomidis Spinellis, Georgios Gousios

Albert Einstein, barriers to entry, business intelligence, business logic, business process, call centre, continuous integration, corporate governance, database schema, Debian, domain-specific language, don't repeat yourself, Donald Knuth, duck typing, en.wikipedia.org, fail fast, fault tolerance, financial engineering, Firefox, Free Software Foundation, functional programming, general-purpose programming language, higher-order functions, iterative process, linked data, locality of reference, loose coupling, meta-analysis, MVC pattern, Neal Stephenson, no silver bullet, peer-to-peer, premature optimization, recommendation engine, Richard Stallman, Ruby on Rails, semantic web, smart cities, social graph, social web, SPARQL, Steve Jobs, Stewart Brand, Strategic Defense Initiative, systems thinking, the Cathedral and the Bazaar, traveling salesman, Turing complete, type inference, web application, zero-coupon bond

Data Grows Up: The Architecture of the Facebook Platform Dave Fetterman Principles and properties Structures ✓ Versatility ✓ Module Conceptual integrity ✓ Dependency ✓ Independently changeable Process ✓ Automatic propagation ✓ Data access Buildability ✓ Growth accommodation ✓ Entropy resistance Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious. —Fred Brooks, The Mythical Man-Month Introduction Most current students of computer science interpret that Fred Brooks quote to mean “show me your code and conceal your data structures....” Information architects have a solid understanding that datarather than algorithms sit at the center of most systems. And with the rise of the Web, data that the user produces and consumes motivates the use of information technologies more than ever.

…

We have created tools and protocols that simultaneously support knowledge transfer between the leading scientific minds of the world as well as allowing our grandmothers to connect to their families and find content and communities that interest them. This is no small feat, and we would do well to consider the confluence of ideas that led to these realities. We have to live within the architectures we build, so we should build architectures that simultaneously satisfy and inspire us. * * * [11] http://en.wikipedia.org/wiki/No_Silver_Bullet Conventional Web Services Before we begin looking at a new architecture for our information-driven environments, we should take a brief look at how we have been building similar systems recently and see what might be done better. We have been pitched a dominant vision for Enterprise Architecture for the last (nearly) 10 years that is built around the notion of reusable business services.

…

It is secure. It is affordable. It conforms to legal standards. It will outlast its predecessors and its competitors. The architecture of a computer system we define as the minimal set of properties that determine what programs will run and what results they will produce. —Gerrit Blaauw & Frederick Brooks, Computer Architecture We’ve never seen a complex system that perfectly satisfies all of the preceding characteristics. Architecture is a game of trade-offs—a decision that improves one of these characteristics often diminishes another. The architect must determine what is sufficient to satisfy, by discovering the important concerns for a particular system and the conditions for satisfying them sufficiently.

Smart and Gets Things Done: Joel Spolsky's Concise Guide to Finding the Best Technical Talent by Joel Spolsky

AOL-Time Warner, Build a better mousetrap, David Heinemeier Hansson, functional programming, knowledge worker, linear programming, no silver bullet, nuclear winter, off-by-one error, Ruby on Rails, Sand Hill Road, Silicon Valley, sorting algorithm, Superbowl ad, the scientific method, type inference, unpaid internship

Introduction But there’s a silver lining, if you will: a bright side to all this meandering mathematical moroseness. And that is this: if you can eliminate one obstacle—just one!—you can double the number of people you hire. Eliminate two obstacles, and you quadruple the number that make it past the remaining obstacles. And so on, and so forth. But there is no silver bullet. There is no magical single thing you can do to solve all your hiring problems and get great developers working for you tomorrow. What you have to do is look at the whole process as an obstacle course and start to think about how to eliminate as many obstacles as possible. Work on all of them, because they’re all equally important.

…

It’s just common decency to let them move on to the next opportunity. 5. On the Web at codingslave.blogspot.com/2005/03/ q-when-is-last-time-you-behaved.html. 120 Smart and Gets Things Done The Obstacle Course, Revisited Back to the original question: how can you hire the best people? Like I said many pages ago, there’s no silver bullet: there are a whole lot of problems you’re going to have to solve and a lot of work you’re going to have to do to reorient your company to be an attractive place for great programmers. You’re going to have to focus on every single contraption on the obstacle course and work on all of them. A lot of the things you’ll have to do are beyond the power of a recruiting director, hiring manager, or even the CEO, but do them you must.

…

If the only difference between programmers were productivity, you might think that you could substitute five mediocre programmers for one really good programmer. That obviously doesn’t work. Brooks’ Law, “Adding manpower to a late software project makes it later,” is why.3 A single good programmer working on a single task has no coordination or communication overhead. Five programmers working on 3. Frederick Brooks, The Mythical Man-Month: Essays on Software Engineering (Reading, Mass.: Addison-Wesley, 1975). Hitting the High Notes the same task must coordinate and communicate. That takes a lot of time. There are added benefits to using the smallest team possible; the man-month really is mythical. But Wait, There’s Even More!

An Elegant Puzzle: Systems of Engineering Management by Will Larson

Ben Horowitz, Cass Sunstein, Clayton Christensen, data science, DevOps, en.wikipedia.org, fault tolerance, functional programming, Google Earth, hive mind, Innovator's Dilemma, iterative process, Kanban, Kickstarter, Kubernetes, loose coupling, microservices, MITM: man-in-the-middle, no silver bullet, pull request, Richard Thaler, seminal paper, Sheryl Sandberg, Silicon Valley, statistical model, systems thinking, the long tail, web application

We describe several related efforts to measure and pay down technical debt found in Google’s BUILD files and associated dead code. We address debt found in dependency specifications, unbuildable targets, and unnecessary command line flags. These efforts often expose other forms of technical debt that must first be managed. “No Silver Bullet—Essence and Accident in Software Engineering” A seminal paper from the author of The Mythical Man-Month, “No Silver Bullet” expands on discussions of accidental versus essential complexity, and argues that there is no longer enough accidental complexity to allow individual reductions in that accidental complexity to significantly increase engineer productivity.

…

Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency by Tom DeMarco Documents a compelling case for middle managers as the critical layer where organizational memory rests and learning occurs. A meditation on the gap between efficiency and effectiveness. The Mythical Man-Month by Frederick Brooks The first professional book I ever read, this one opened my eyes to the wealth of software engineering literature waiting out there. Good Strategy/Bad Strategy The Difference and Why it Matters by Richard Rumelt This book gave me permission to acknowledge that many strategies I’ve seen professionally are not very good.

…

keywords=Slack%3A+Getting+Past+Burnout%2C+Busywork%2C+and+the+Myth+of+Total+Efficiency+by+Tom+DeMarco&qid=1551585846&s=gateway&sr=8-1-fkmrnull 5. https://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959/ref=sr_1_fkmrnull_1?keywords=The+Mythical+Man-Month+by+Frederick+Brooks&qid=1551585913&s=gateway&sr=8-1-fkmrnull 6. https://www.amazon.com/Good-Strategy-Bad-Difference-Matters-ebook/dp/B004J4WKEC/ref=sr_1_fkmrnull_1?keywords=Good+Strategy+Bad+Strategy%3A+The+Difference+and+Why+it+Matters+by+Richard+Rumelt&qid=1551585977&s=gateway&sr=8-1-fkmrnull 7. https://www.amazon.com/Goal-Process-Ongoing-Improvement/dp/0884271951/ref=sr_1_1?

Chaos Engineering: System Resiliency in Practice by Casey Rosenthal, Nora Jones

Amazon Web Services, Asilomar, autonomous vehicles, barriers to entry, blockchain, business continuity plan, business intelligence, business logic, business process, cloud computing, cognitive load, complexity theory, continuous integration, cyber-physical system, database schema, DevOps, fail fast, fault tolerance, hindsight bias, human-factors engineering, information security, Kanban, Kubernetes, leftpad, linear programming, loose coupling, microservices, MITM: man-in-the-middle, no silver bullet, node package manager, operational security, OSI model, pull request, ransomware, risk tolerance, scientific management, Silicon Valley, six sigma, Skype, software as a service, statistical model, systems thinking, the scientific method, value engineering, WebSocket

Ross Ashby, “Requisite Variety and Its Implications for the Control of Complex Systems,” Cybernetica 1:2 (1958), pp. 83-99. To oversimplify, a system A that fully controls system B has to be at least as complex as system B. 3 It doesn’t work exactly this way, because the consistent hash algorithm distributes data objects pseudo-randomly across all S-D instances. 4 Frederick Brooks, “No Silver Bullet—Essence and Accident in Software Engineering,” from Proceedings of the IFIP Tenth World Computing Conference, H.-J. Kugler ed., Elsevier Science BV, Amsterdam (1986). Chapter 2. Navigating Complex Systems The previous chapter described complex systems in much the same way one would describe the water to someone who is drowning.

…

In this hypothetical simpler world, we can imagine a hyper-efficient, impersonal manager could remove all errors simply by getting rid of the bad apples who create those errors. To examine this possible solution, it is helpful to understand a few additional characteristics of complexity. Roughly speaking, complexity can be sorted into two buckets: accidental and essential, a distinction made by Frederick Brooks in the 1980s.4 Accidental Complexity Accidental complexity is a consequence of writing software within a resource-limited setting, namely this universe. In everyday work there are always competing priorities. For software engineers the explicit priorities might be feature velocity, test coverage, and idiomaticity.

…

It is often the case that writing new software to reduce accidental complexity simply creates new forms of accidental complexity. These new forms may be more acceptable than the prior, but that acceptability will expire at roughly the same rate. Large refactors often suffer from what is known as the second-system effect, a term also introduced by Frederick Brooks, in which the subsequent project is supposed to be better than the original because of the insight gained during development of the first. Instead, these second systems end up bigger and more complex due to unintentional trade-offs inspired by the success of writing the first version. Regardless of the approach taken to reduce accidental complexity, none of these methods are sustainable.

Code Complete (Developer Best Practices) by Steve McConnell

Ada Lovelace, Albert Einstein, Buckminster Fuller, business logic, call centre, classic study, continuous integration, data acquisition, database schema, don't repeat yourself, Donald Knuth, fault tolerance, General Magic , global macro, Grace Hopper, haute cuisine, if you see hoof prints, think horses—not zebras, index card, inventory management, iterative process, Larry Wall, loose coupling, Menlo Park, no silver bullet, off-by-one error, Perl 6, place-making, premature optimization, revision control, Sapir-Whorf hypothesis, seminal paper, slashdot, sorting algorithm, SQL injection, statistical model, Tacoma Narrows Bridge, the Cathedral and the Bazaar, the scientific method, Thomas Kuhn: the structure of scientific revolutions, Turing machine, web application

Key Design Concepts Good design depends on understanding a handful of key concepts. This section discusses the role of complexity, desirable characteristics of designs, and levels of design. Software's Primary Technical Imperative: Managing Complexity To understand the importance of managing complexity, it's useful to refer to Fred Brooks's landmark paper, "No Silver Bullets: Essence and Accidents of Software Engineering" (1987). Cross-Reference For discussion of the way complexity affects programming issues other than design, see Conquer Complexity. Accidental and Essential Difficulties Brooks argues that software development is made difficult because of two different classes of problems—the essential and the accidental.

…

Unfortunately, the letter-writing metaphor has been perpetuated by one of the most popular software books on the planet, Fred Brooks's The Mythical Man-Month (Brooks 1995). Brooks says, "Plan to throw one away; you will, anyhow." This conjures up an image of a pile of half-written drafts thrown into a wastebasket, as shown in Figure 2-1. Figure 2-1. The letter-writing metaphor suggests that the software process relies on expensive trial and error rather than careful planning and design Plan to throw one away; you will, anyhow. — Fred Brooks If you plan to throw one away, you will throw away two. — Craig Zerouni Planning to throw one away might be practical when you're writing a polite how-do-you-do to your aunt.

…

“"Validation, Verification, and Testing for the Individual Programmer."” Computer, December, 24–30. [bib36entry78] Brockmann,R.John. 1990. Writing Better Computer User Documentation: From Paper to Hypertext: Version 2.0. New York, NY: John Wiley & Sons. [bib36entry79] Brooks,FrederickP.,Jr. 1987. “"No Silver Bullets—Essence and Accidents of Software Engineering."” Computer, April, 10–19. [bib36entry80] Brooks,FrederickP.,Jr. 1995. The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2d ed.). Reading, MA: Addison-Wesley. [bib36entry81] Brooks,Ruven. 1977. “"Towards a Theory of the Cognitive Processes in Computer Programming."”

Culture & Empire: Digital Revolution by Pieter Hintjens

4chan, Aaron Swartz, airport security, AltaVista, anti-communist, anti-pattern, barriers to entry, Bill Duvall, bitcoin, blockchain, Boeing 747, bread and circuses, business climate, business intelligence, business process, Chelsea Manning, clean water, commoditize, congestion charging, Corn Laws, correlation does not imply causation, cryptocurrency, Debian, decentralized internet, disinformation, Edward Snowden, failed state, financial independence, Firefox, full text search, gamification, German hyperinflation, global village, GnuPG, Google Chrome, greed is good, Hernando de Soto, hiring and firing, independent contractor, informal economy, intangible asset, invisible hand, it's over 9,000, James Watt: steam engine, Jeff Rulifson, Julian Assange, Kickstarter, Laura Poitras, M-Pesa, mass immigration, mass incarceration, mega-rich, military-industrial complex, MITM: man-in-the-middle, mutually assured destruction, Naomi Klein, national security letter, Nelson Mandela, new economy, New Urbanism, no silver bullet, Occupy movement, off-the-grid, offshore financial centre, packet switching, patent troll, peak oil, power law, pre–internet, private military company, race to the bottom, real-name policy, rent-seeking, reserve currency, RFC: Request For Comment, Richard Feynman, Richard Stallman, Ross Ulbricht, Russell Brand, Satoshi Nakamoto, security theater, selection bias, Skype, slashdot, software patent, spectrum auction, Steve Crocker, Steve Jobs, Steven Pinker, Stuxnet, The Wealth of Nations by Adam Smith, The Wisdom of Crowds, trade route, transaction costs, twin studies, union organizing, wealth creators, web application, WikiLeaks, Y2K, zero day, Zipf's Law

Today this is how the largest firms like Oracle still sell their software. The leading edge of software development often sets the tone for other knowledge industries. A clear example of this is how we solved the "software crisis" of the late twentieth century. In 1987, Fred Brooks, a leading expert of the problems of the software industry, famously wrote that "we see no silver bullet. There is no single development, in either technology or in management technique, that by itself promises even one order-of-magnitude improvement in productivity, in reliability, in simplicity." Brooks listed a number of steps that might solve the software crisis.

…

It left him deeply skeptical of the software industry's capacity for self-improvement. He wrote, in his landmark 1975 book, "The Mythical Man Month" that "adding manpower to a late software project makes it later," a lesson that Microsoft would have been wise to understand when they built Windows Vista over five long years from 2001 to 2006. Fred Brooks was technically right when he said "no single element" could solve the software crisis. Yet like everyone at the time, he missed the point and failed to see the oncoming revolution in software development. History shows that two elements combined to create a thoroughly effective silver bullet. The first was the relentless pressure of cost gravity, which from 1975 to 1995 brought the cost of software development infrastructure -- computers and networks -- down by 1,000 times, and by 2015, a million times.

…

Actually it's a nonsense vision: without cost gravity, we'd not even be here. By 1995, it had become easily possible for individual programmers to buy computers and link them together using email, the file transfer protocol (FTP), and other young protocols like the hypertext transfer protocol (HTTP). So while Fred Brooks's IBM had to bring expert developers together in huge research facilities, the Internet allowed the same developers to work from anywhere, to create flexible ad hoc teams, and solve problems in much more intelligent ways. The second element is what I consider one of the key technological developments of the twentieth century digital revolution, which was a new private contract for collaborative development called the GNU General Public License, or GPL.

Ship It!: A Practical Guide to Successful Software Projects by Jared R. Richardson, William A. Gwaltney

continuous integration, David Heinemeier Hansson, Donald Knuth, index card, MVC pattern, no silver bullet, place-making, Ruby on Rails, web application

This is easier to fix with an automatic system than with a manual one, but in either case, you must take this problem into account. 102 P UTTING I T A LL T OGETHER 15 Putting It All Together Unlike more complicated, full-featured methodologies, you really can do this. You can start today and see at least some benefits right away. You’ll see more benefits over time, of course, and the more you invest in your methods of work, the more benefits you’ll see. There are no silver bullets, but the techniques we’ve presented here help prevent a large number of common disasters while staying out of your way as much as possible. Implementing these techniques will make you look like a programming gods, but really you’re just leveraging the experience of others. You’ll “stand on the shoulders of giants,” as the saying goes.

…

It should be a desktop reference for everyone who writes code for a living. Mastering Regular Expressions by Jeffrey Friedl. Regular expressions are the most powerful way to process text we’ve ever come across, but the “Here Be Dragons” factor is extremely high. This book handily slays the little beasties. The Mythical Man-Month by Frederick Brooks. Will realized after reading this book (the first edition, in college no less!) how much more there is to software development than simply coding up a program. The Art of Computer Programming by Donald Knuth. There are multiple volumes in this set. They are a comprehensive introduction to classical computer science.

Coders: The Making of a New Tribe and the Remaking of the World by Clive Thompson

"Margaret Hamilton" Apollo, "Susan Fowler" uber, 2013 Report for America's Infrastructure - American Society of Civil Engineers - 19 March 2013, 4chan, 8-hour work day, Aaron Swartz, Ada Lovelace, AI winter, air gap, Airbnb, algorithmic bias, AlphaGo, Amazon Web Services, Andy Rubin, Asperger Syndrome, augmented reality, Ayatollah Khomeini, backpropagation, barriers to entry, basic income, behavioural economics, Bernie Sanders, Big Tech, bitcoin, Bletchley Park, blockchain, blue-collar work, Brewster Kahle, Brian Krebs, Broken windows theory, call centre, Cambridge Analytica, cellular automata, Charles Babbage, Chelsea Manning, Citizen Lab, clean water, cloud computing, cognitive dissonance, computer vision, Conway's Game of Life, crisis actor, crowdsourcing, cryptocurrency, Danny Hillis, data science, David Heinemeier Hansson, deep learning, DeepMind, Demis Hassabis, disinformation, don't be evil, don't repeat yourself, Donald Trump, driverless car, dumpster diving, Edward Snowden, Elon Musk, Erik Brynjolfsson, Ernest Rutherford, Ethereum, ethereum blockchain, fake news, false flag, Firefox, Frederick Winslow Taylor, Free Software Foundation, Gabriella Coleman, game design, Geoffrey Hinton, glass ceiling, Golden Gate Park, Google Hangouts, Google X / Alphabet X, Grace Hopper, growth hacking, Guido van Rossum, Hacker Ethic, hockey-stick growth, HyperCard, Ian Bogost, illegal immigration, ImageNet competition, information security, Internet Archive, Internet of things, Jane Jacobs, John Markoff, Jony Ive, Julian Assange, Ken Thompson, Kickstarter, Larry Wall, lone genius, Lyft, Marc Andreessen, Mark Shuttleworth, Mark Zuckerberg, Max Levchin, Menlo Park, meritocracy, microdosing, microservices, Minecraft, move 37, move fast and break things, Nate Silver, Network effects, neurotypical, Nicholas Carr, Nick Bostrom, no silver bullet, Northpointe / Correctional Offender Management Profiling for Alternative Sanctions, Oculus Rift, off-the-grid, OpenAI, operational security, opioid epidemic / opioid crisis, PageRank, PalmPilot, paperclip maximiser, pattern recognition, Paul Graham, paypal mafia, Peter Thiel, pink-collar, planetary scale, profit motive, ransomware, recommendation engine, Richard Stallman, ride hailing / ride sharing, Rubik’s Cube, Ruby on Rails, Sam Altman, Satoshi Nakamoto, Saturday Night Live, scientific management, self-driving car, side project, Silicon Valley, Silicon Valley ideology, Silicon Valley startup, single-payer health, Skype, smart contracts, Snapchat, social software, software is eating the world, sorting algorithm, South of Market, San Francisco, speech recognition, Steve Wozniak, Steven Levy, systems thinking, TaskRabbit, tech worker, techlash, TED Talk, the High Line, Travis Kalanick, Uber and Lyft, Uber for X, uber lyft, universal basic income, urban planning, Wall-E, Watson beat the top human players on Jeopardy!, WeWork, WikiLeaks, women in the workforce, Y Combinator, Zimmermann PGP, éminence grise

Meanwhile, led by professor Lenore Blum, CMU began building more community participation and support groups for women studying CS, events that made them more visible to their fellow students. Admissions, too, changed; it no longer gave so much preference to students who’d been teen coders. There was no silver bullet, no single policy that improved things, Fisher notes. “There’s really a virtuous cycle,” Fisher adds. “If you make the program accommodate people with less experience, then people with less experience come in”; then faculty become more used to seeing how neophyte coders evolve into accomplished ones, and how to teach that type.

…

Yet software is also, obviously, quite different from a poem or a novel, because it wreaks such direct physical effects on how we live our lives. (This is part of why some coders think it’s been ruinous to regulate code with copyright.) Code straddles worlds, half metal and half idea. “The programmer, like the poet, works only slightly removed from pure thought-stuff,” wrote the software engineer Fred Brooks in 1975. “He builds his castles in the air, from air, creating by exertion of the imagination . . . Yet the program construct, unlike the poet’s words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself. It prints results, draws pictures, produces sounds, moves arms.

…

The software manager Bill Curtis published a paper showing a test he’d done with 54 coders, in which the best outperformed the worst by factors of 8X to 13X. A headline in the computer magazine Infosystems posed the field of programming as a star system of rare heroes looming over their mediocre colleagues: “The Mongolian Hordes versus Superprogrammer.” The legend arguably cemented into place in 1975, when Fred Brooks published The Mythical Man-Month, a book about the dark art of managing software projects. Brooks noted Sackman’s findings approvingly. “Programming managers have long recognized wide productivity variations between good programmers and poor ones,” he noted. “But the actual measured magnitudes have astounded all of us.”

Refactoring: Improving the Design of Existing Code by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts

business logic, conceptual framework, database schema, index card, MVC pattern, no silver bullet, place-making, sorting algorithm

Once you get the new function working, you realize you coded it in a way that's awkward to understand, so you swap hats again and refactor. All this might take only ten minutes, but during this time you should always be aware of which hat you're wearing. Why Should You Refactor? I don't want to proclaim refactoring as the cure for all software ills. It is no "silver bullet." Yet it is a valuable tool, a pair of silver pliers that helps you keep a good grip on your code. Refactoring is a tool that can, and should, be used for several purposes. Refactoring Improves the Design of Software Without refactoring, the design of the program will decay. As people change code—changes to realize short-term goals or changes made without a full comprehension of the design of the code—the code loses its structure.

…

Best wishes as you move forward in your software development tasks. Endnotes 1. Opdyke, William F. “Refactoring Object-Oriented Frameworks.” Ph.D. diss., University of Illinois at Urbana-Champaign. Also available as Technical Report UIUCDCS-R-92-1759, Department of Computer Science, University of Illinois at Urbana-Champaign. 2. Brooks, Fred. “No Silver Bullet: Essence and Accidents of Software Engineering.” In Information Processing 1986: Proceedings of the IFIP Tenth World Computing Conference, edited by H.-L.Kugler. Amsterdam: Elsevier, 1986. 3. Foote, Brian and William F. Opdyke. “Lifecycle and Refactoring Patterns That Support Evolution and Reuse.”

…

It is a way to restructure software to make design insights more explicit, to develop frameworks and extract reusable components, to clarify the software architecture, and to prepare to make additions easier. Refactoring can help you leverage your past investment, reduce duplication, and streamline a program. Suppose you as a developer buy into these advantages. You agree with Fred Brooks that dealing with change is one of the "essential complexities" of developing software.[2] You agree that in the abstract refactoring can provide the stated advantages. Why might you still not refactor your programs? Here are four possible reasons: 1. 2. 3. 4. You might not understand how to refactor.

Site Reliability Engineering: How Google Runs Production Systems by Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy

"Margaret Hamilton" Apollo, Abraham Maslow, Air France Flight 447, anti-pattern, barriers to entry, business intelligence, business logic, business process, Checklist Manifesto, cloud computing, cognitive load, combinatorial explosion, continuous integration, correlation does not imply causation, crowdsourcing, database schema, defense in depth, DevOps, en.wikipedia.org, exponential backoff, fail fast, fault tolerance, Flash crash, George Santayana, Google Chrome, Google Earth, if you see hoof prints, think horses—not zebras, information asymmetry, job automation, job satisfaction, Kubernetes, linear programming, load shedding, loose coupling, machine readable, meta-analysis, microservices, minimum viable product, MVC pattern, no silver bullet, OSI model, performance metric, platform as a service, proprietary trading, reproducible builds, revision control, risk tolerance, side project, six sigma, the long tail, the scientific method, Toyota Production System, trickle-down economics, warehouse automation, web application, zero day

We don’t want our programs to be spontaneous and interesting; we want them to stick to the script and predictably accomplish their business goals. In the words of Google engineer Robert Muth, “Unlike a detective story, the lack of excitement, suspense, and puzzles is actually a desirable property of source code.” Surprises in production are the nemeses of SRE. As Fred Brooks suggests in his “No Silver Bullet” essay [Bro95], it is very important to consider the difference between essential complexity and accidental complexity. Essential complexity is the complexity inherent in a given situation that cannot be removed from a problem definition, whereas accidental complexity is more fluid and can be resolved with engineering effort.

…

Maintaining a guarantee of data integrity at large scale, a challenge that is further complicated by the high rate of change of the involved software systems, requires a number of complementary but uncoupled practices, each chosen to offer a high degree of protection on its own. The 24 Combinations of Data Integrity Failure Modes Given the many ways data can be lost (as described previously), there is no silver bullet that guards against the many combinations of failure modes. Instead, you need defense in depth. Defense in depth comprises multiple layers, with each successive layer of defense conferring protection from progressively less common data loss scenarios. Figure 26-2 illustrates an object’s journey from soft deletion to destruction, and the data recovery strategies that should be employed along this journey to ensure defense in depth.

…

Brewer, “Lessons From Giant-Scale Services”, in IEEE Internet Computing, vol. 5, no. 4, July / August 2001. [Bre12] E. Brewer, “CAP Twelve Years Later: How the “Rules” Have Changed”, in Computer, vol. 45, no. 2, February 2012. [Bro15] M. Brooker, “Exponential Backoff and Jitter”, on AWS Architecture Blog, March 2015. [Bro95] F. P. Brooks Jr., “No Silver Bullet—Essence and Accidents of Software Engineering”, in The Mythical Man-Month, Boston: Addison-Wesley, 1995, pp. 180–186. [Bru09] J. Brutlag, “Speed Matters”, on Google Research Blog, June 2009. [Bul80] G. M. Bull, The Dartmouth Time-sharing System: Ellis Horwood, 1980. [Bur99] M. Burgess, Principles of Network and System Administration: Wiley, 1999.

ZeroMQ by Pieter Hintjens

AGPL, anti-pattern, behavioural economics, carbon footprint, cloud computing, Debian, distributed revision control, domain-specific language, eat what you kill, Eben Moglen, exponential backoff, factory automation, fail fast, fault tolerance, fear of failure, finite state, Internet of things, iterative process, no silver bullet, power law, premature optimization, profit motive, pull request, revision control, RFC: Request For Comment, Richard Stallman, Skype, smart transportation, software patent, Steve Jobs, Valgrind, WebSocket

Connecting computers is so difficult that creating software and services to do this is a multi-billion dollar business. So we live in a world where the wiring is years ahead of our ability to use it. We had a software crisis in the 1980s, when leading software engineers like Fred Brooks believed there was no “silver bullet” to “promise even one order of magnitude of improvement in productivity, reliability, or simplicity.” Brooks missed free and open source software, which solved that crisis, enabling us to share knowledge efficiently. Today we face another software crisis, but it’s one we don’t talk about much.

The C++ Programming Language by Bjarne Stroustrup

combinatorial explosion, conceptual framework, database schema, Dennis Ritchie, distributed generation, Donald Knuth, fault tolerance, functional programming, general-purpose programming language, higher-order functions, index card, iterative process, job-hopping, L Peter Deutsch, locality of reference, Menlo Park, no silver bullet, Parkinson's law, premature optimization, sorting algorithm

Describes the development of object-oriented systems from a management perspective. Contains extensive C++ code examples. [Brooks,1982] Fred Brooks: The Mythical Man Month. Addison-Wesley. 1982. Everyone should read this book every couple of years. A warning against hubris. It is a bit dated on technical matters, but it is not at all dated in matters related to individuals, organizations, and scale. Republished with additions in 1997. ISBN 1-201-83595-9. [Brooks,1987] Fred Brooks: No Silver Bullet. IEEE Computer, Vol. 20, No. 4. April 1987. A summary of approaches to large-scale software development, with a much-needed warning against belief in miracle cures (‘‘silver bullets’’).

…

. ________________________________________ ________________________________________________________________________________________________________________________________________________________________ 23 ________________________________________ ________________________________________________________________________________________________________________________________________________________________ Development and Design There is no silver bullet. – F. Brooks Building software — aims and means — development process — development cycle — design aims — design steps — finding classes — specifying operations — specifying dependencies — specifying interfaces — reorganizing class hierarchies — models — experimentation and analysis — testing — software maintenance — efficiency — management — reuse — scale — the importance of individuals — hybrid design — bibliography — advice. 23.1 Overview [design.overview] This chapter is the first of three that present the production of software in increasing detail, starting from a relatively high-level view of design and ending with C++ specific programming techniques and concepts directly supporting such design.

Clojure Programming by Chas Emerick, Brian Carper, Christophe Grand

Amazon Web Services, Benoit Mandelbrot, cloud computing, cognitive load, continuous integration, database schema, domain-specific language, don't repeat yourself, drop ship, duck typing, en.wikipedia.org, failed state, finite state, Firefox, functional programming, game design, general-purpose programming language, Guido van Rossum, higher-order functions, Larry Wall, mandelbrot fractal, no silver bullet, Paul Graham, platform as a service, premature optimization, random walk, Ruby on Rails, Schrödinger's Cat, semantic web, software as a service, sorting algorithm, SQL injection, Turing complete, type inference, web application

This is the basis of Clojure’s reference types, which we’ll discuss shortly. When you absolutely have no other choice—and are willing to shrug off the benefits of the semantic guarantees of Clojure’s reference types—make it straightforward to drop back to bare locks, threads, and the high-quality concurrency APIs provided by Java. Clojure provides no silver bullet that makes concurrent programming instantly trivial, but it does provide some novel and now battle-tested tools to makes it far more tractable and reliable. Shifting Computation Through Time and Space Clojure provides a number of entities—delays, futures, and promises—that encapsulate discrete use cases for controlling when and how computations are performed.

…

* * * [107] See Type Hinting for Performance for how metadata is used to provide type information to Clojure’s compiler, Vars for how metadata attached to vars can set access policy and concurrency semantics, and Annotations for how metadata is used to apply Java annotations to Clojure types. Putting Clojure’s Collections to Work Why are data structures so important? In The Mythical Man-Month, Frederick Brooks says: Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowchart; it’ll be obvious. Two decades later, Eric Raymond modernized it into: Show me your code and conceal your data structures, and I shall continue to be mystified.

Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems by Martin Kleppmann

active measures, Amazon Web Services, billion-dollar mistake, bitcoin, blockchain, business intelligence, business logic, business process, c2.com, cloud computing, collaborative editing, commoditize, conceptual framework, cryptocurrency, data science, database schema, deep learning, DevOps, distributed ledger, Donald Knuth, Edward Snowden, end-to-end encryption, Ethereum, ethereum blockchain, exponential backoff, fake news, fault tolerance, finite state, Flash crash, Free Software Foundation, full text search, functional programming, general-purpose programming language, Hacker News, informal economy, information retrieval, Internet of things, iterative process, John von Neumann, Ken Thompson, Kubernetes, Large Hadron Collider, level 1 cache, loose coupling, machine readable, machine translation, Marc Andreessen, microservices, natural language processing, Network effects, no silver bullet, operational security, packet switching, peer-to-peer, performance metric, place-making, premature optimization, recommendation engine, Richard Feynman, self-driving car, semantic web, Shoshana Zuboff, social graph, social web, software as a service, software is eating the world, sorting algorithm, source of truth, SPARQL, speech recognition, SQL injection, statistical model, surveillance capitalism, systematic bias, systems thinking, Tragedy of the Commons, undersea cable, web application, WebSocket, wikimedia commons

.: “Dynamo: Ama‐ zon’s Highly Available Key-Value Store,” at 21st ACM Symposium on Operating Sys‐ tems Principles (SOSP), October 2007. [20] Greg Linden: “Make Data Useful,” slides from presentation at Stanford Univer‐ sity Data Mining class (CS345), December 2006. [21] Tammy Everts: “The Real Cost of Slow Time vs Downtime,” webperformanceto‐ day.com, November 12, 2014. [22] Jake Brutlag: “Speed Matters for Google Web Search,” googleresearch.blog‐ spot.co.uk, June 22, 2009. [23] Tyler Treat: “Everything You Know About Latency Is Wrong,” bravenew‐ geek.com, December 12, 2015. 24 | Chapter 1: Reliable, Scalable, and Maintainable Applications [24] Jeffrey Dean and Luiz André Barroso: “The Tail at Scale,” Communications of the ACM, volume 56, number 2, pages 74–80, February 2013. doi: 10.1145/2408776.2408794 [25] Graham Cormode, Vladislav Shkapenyuk, Divesh Srivastava, and Bojian Xu: “Forward Decay: A Practical Time Decay Model for Streaming Systems,” at 25th IEEE International Conference on Data Engineering (ICDE), March 2009. [26] Ted Dunning and Otmar Ertl: “Computing Extremely Accurate Quantiles Using t-Digests,” github.com, March 2014. [27] Gil Tene: “HdrHistogram,” hdrhistogram.org. [28] Baron Schwartz: “Why Percentiles Don’t Work the Way You Think,” vividcor‐ tex.com, December 7, 2015. [29] James Hamilton: “On Designing and Deploying Internet-Scale Services,” at 21st Large Installation System Administration Conference (LISA), November 2007. [30] Brian Foote and Joseph Yoder: “Big Ball of Mud,” at 4th Conference on Pattern Languages of Programs (PLoP), September 1997. [31] Frederick P Brooks: “No Silver Bullet – Essence and Accident in Software Engi‐ neering,” in The Mythical Man-Month, Anniversary edition, Addison-Wesley, 1995. ISBN: 978-0-201-83595-3 [32] Ben Moseley and Peter Marks: “Out of the Tar Pit,” at BCS Software Practice Advancement (SPA), 2006. [33] Rich Hickey: “Simple Made Easy,” at Strange Loop, September 2011. [34] Hongyu Pei Breivold, Ivica Crnkovic, and Peter J.

Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems by Martin Kleppmann

active measures, Amazon Web Services, billion-dollar mistake, bitcoin, blockchain, business intelligence, business logic, business process, c2.com, cloud computing, collaborative editing, commoditize, conceptual framework, cryptocurrency, data science, database schema, deep learning, DevOps, distributed ledger, Donald Knuth, Edward Snowden, end-to-end encryption, Ethereum, ethereum blockchain, exponential backoff, fake news, fault tolerance, finite state, Flash crash, Free Software Foundation, full text search, functional programming, general-purpose programming language, Hacker News, informal economy, information retrieval, Infrastructure as a Service, Internet of things, iterative process, John von Neumann, Ken Thompson, Kubernetes, Large Hadron Collider, level 1 cache, loose coupling, machine readable, machine translation, Marc Andreessen, microservices, natural language processing, Network effects, no silver bullet, operational security, packet switching, peer-to-peer, performance metric, place-making, premature optimization, recommendation engine, Richard Feynman, self-driving car, semantic web, Shoshana Zuboff, social graph, social web, software as a service, software is eating the world, sorting algorithm, source of truth, SPARQL, speech recognition, SQL injection, statistical model, surveillance capitalism, systematic bias, systems thinking, Tragedy of the Commons, undersea cable, web application, WebSocket, wikimedia commons

[29] James Hamilton: “On Designing and Deploying Internet-Scale Services,” at 21st Large Installation System Administration Conference (LISA), November 2007. [30] Brian Foote and Joseph Yoder: “Big Ball of Mud,” at 4th Conference on Pattern Languages of Programs (PLoP), September 1997. [31] Frederick P Brooks: “No Silver Bullet – Essence and Accident in Software Engineering,” in The Mythical Man-Month, Anniversary edition, Addison-Wesley, 1995. ISBN: 978-0-201-83595-3 [32] Ben Moseley and Peter Marks: “Out of the Tar Pit,” at BCS Software Practice Advancement (SPA), 2006. [33] Rich Hickey: “Simple Made Easy,” at Strange Loop, September 2011