no silver bullet

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

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
Published 2 Jan 2006

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
Published 17 Mar 2021

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
Published 22 Sep 2003

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
Published 22 Jun 2009

(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.
Published 1 Jan 1975

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 and Georgios Gousios
Published 30 Dec 2008

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
Published 1 Jun 2007

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
Published 19 May 2019

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 and Nora Jones
Published 27 Apr 2020

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
Published 8 Jun 2004

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
Published 11 Mar 2013

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 and William A. Gwaltney
Published 15 Mar 2005

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
Published 26 Mar 2019

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 and Don Roberts
Published 9 Mar 2012

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 and Niall Richard Murphy
Published 15 Apr 2016

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
Published 12 Mar 2013

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
Published 2 Jan 1986

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 and Christophe Grand
Published 15 Aug 2011

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
Published 17 Apr 2017

.: “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
Published 16 Mar 2017

[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