"Because it so often takes ages before a new piece of software is ready for anyone to use, programmers often test their assumptions against 'use cases' hypothetical scenarios about how imaginary people might need or want to use a program." (Scott Rosenberg, "Dreaming in Code", 2007)
"Communicating abstractions unambiguously - from programmer to machine, from programmer to programmer, and from program to user - is the single most challenging demand of software development." (Scott Rosenberg, "Dreaming in Code", 2007)
"Despite the odds - despite complexity and delay and unpredictable change - a lot of software somehow does get written and delivered and, finally, used. Occasionally, it’s even good. Rarely, it actually does something new and valuable. And in a handful of cases, it achieves all of that on schedule." (Scott Rosenberg, "Dreaming in Code", 2007)
"Ending up somewhere entirely different from where you expected to go is the norm in this world. Software projects are prime illustrations of the law of unintended consequences, and their innovations and breakthroughs are more often side effects than planned outcomes." (Scott Rosenberg, "Dreaming in Code", 2007)
"Engineering is, of course, all about bridging the gulf between art and science. Engineering is often defined as the application of scientific principles to serve human needs. But it also brings creativity to bear on those scientific principles, dragging them out of pristine abstraction into the compromised universe of our frustrations and wants." (Scott Rosenberg, "Dreaming in Code", 2007)
"Every software project in history has had its loose wires. Every effort to improve the making of software is an effort to keep them tight." (Scott Rosenberg, "Dreaming in Code", 2007)
"For programmers, just as for writers and artists and everyone whose work involves starting with a blank slate, the 'funnest' time of a project often falls at the very beginning, when worlds of giddy possibility lie open, and before painful compromises have shut any doors." (Scott Rosenberg, "Dreaming in Code", 2007)
"[…] in software development, as in all things, plans get dodgier the farther into the future one looks. Any developer who has been around the block will admit that the cavalcade of methodologies over three decades of software history has left the field richer and given programmers useful new tools and ways of thinking about their work. But finding a developer or team that actually subscribes to a particular methodology isn’t easy." (Scott Rosenberg, "Dreaming in Code", 2007)
"In software management, coordination is not an afterthought or an ancillary matter; it is the heart of the work, and deciding what tools and methods to use can make or break a project. But getting sidetracked in managing those tools is a potent temptation." (Scott Rosenberg, "Dreaming in Code", 2007)
"In the binary digital world of computers, all information is reduced to sequences of zeros and ones. But there’s a space between zero and one, between the way the machine counts and thinks and the way we count and think." (Scott Rosenberg, "Dreaming in Code", 2007)
"In the world of software, integration means taking a body of code that works fine by itself and connecting it to the other existing parts of a program that have in turn been working fine. The integration point is typically where a software project hits big trouble. Chunks of code that worked well enough separately often balk when asked to work together; they fail to hook together correctly, send messages that can’t be interpreted, or stubbornly refuse to start or stop." (Scott Rosenberg, "Dreaming in Code", 2007)
"It’s difficult not to have a love/hate relationship with computer programming if you have any relationship with it at all." (Scott Rosenberg, "Dreaming in Code", 2007)
"It’s tempting to view the multitude of monster projects gone bad as anomalies, excrescences of corporate and government bureaucracies run amok. But you will find similar tales of woe emerging from software projects big and small, public and private, old and new. Though details differ, the pattern is depressingly repetitive: Moving targets. Fluctuating goals. Unrealistic schedules. Missed deadlines. Ballooning costs. Despair. Chaos." (Scott Rosenberg, "Dreaming in Code", 2007)
"Late binding is a term in computer science that refers to programming languages’ capacity to provide programmers with more flexibility. Late-bound programs can be changed on the fly, while they’re running; you can even build them so that they change themselves while they’re running." (Scott Rosenberg, "Dreaming in Code", 2007)
"Life is harder without a 'source of truth'. For programmers as for other human beings, a canonical authority can be convenient. It rescues you from having to figure out how to adjudicate dilemmas on your own."
"Like a black hole or any similar rent in the warp and woof of space-time, a singularity is a disruption of continuity, a break with the past. It is a point at which everything changes, and a point beyond which we can’t see." (Scott Rosenberg, "Dreaming in Code", 2007)
"Mathematically speaking, 'recursion' describes a function that calls itself; in computer science, recursion refers to defining a function in terms of itself. The logic of recursion allows simple, compact statements to generate complex and elaborate output." (Scott Rosenberg, "Dreaming in Code", 2007)
"No programmer will want to build something from scratch if he can grab something that is already written and adapt it to new ends." (Scott Rosenberg, "Dreaming in Code", 2007)
"Object-oriented techniques organize programs not around sequential lines of commands but instead around chunks of code called objects that spring to life and action when other objects call on them. Objects relate to other objects via strictly defined inputs and outputs, so that programmers writing code that must interact with them need not concern themselves with what’s happening inside them." (Scott Rosenberg, "Dreaming in Code", 2007)
"Old code rarely offers trendy graphics or flavor-of-the-month features, but it has one considerable ad - vantage: It tends to work. A program that has been well used is like an old garden that has been well tended or a vintage guitar that has been well played: Its rough edges have been filed away, its bugs have been found and fixed, and its performance is a known and valuable quantity." (Scott Rosenberg, "Dreaming in Code", 2007)
"One great irony inherent in the management of software projects is that despite the digital precision of the materials programmers work with, the enterprise of writing software is uniquely resistant to measurement." (Scott Rosenberg, "Dreaming in Code", 2007)
"People write programs. That statement is worth pausing over. People write programs. Despite the field’s infatuation with metaphors like architecture and bridge-building and its dabbling in alternative models from biology or physics, the act of programming today remains an act of writing - of typing character after character, word after word, line after line." (Scott Rosenberg, "Dreaming in Code", 2007)
"Programmers are motivated and led toward their best work by a desire to accomplish something that pleases them or fulfills a personal need." (Scott Rosenberg, "Dreaming in Code", 2007)
"Silos are everywhere. […] Silos are common because they are simple, reliable, and unambiguous." (Scott Rosenberg, "Dreaming in Code", 2007)
"So if programmers are optimists by nature, they also have a keen eye for the downside. A hyper-active imagination for disaster scenarios is a professional asset; they have to think through everything that can go wrong in order to practice their craft." (Scott Rosenberg, "Dreaming in Code", 2007)
"Software is abstract and therefore seems as if it should be infinitely malleable. And yet, for all its ethereal flexibility, it can be stubbornly, maddeningly intractable, and it is constantly surprising us with its rigidity." (Scott Rosenberg, "Dreaming in Code", 2007)
"Software is different; it has no core. It is onionlike, a thing of layers, each built painstakingly and precariously on the previous one, each counting on the one below not to move or change too much. Software builders like to talk about laying bricks; skeptics see a house of cards. Either way, there’s a steady accumulation going on. New layers pile on old. Programmers call these accretions 'layers of abstraction', because each time a new one is added, something complex and specific is being translated into something simpler and more general." (Scott Rosenberg, "Dreaming in Code", 2007)
"Software is easy to make, except when you want it to do something new. And then, of course, there is a corollary: The only software that's worth making is software that does something new." (Scott Rosenberg, "Dreaming in Code", 2007)
"The names programmers adopt for their abstractions are, as geeks like to say, 'nontrivial'. In software, labels and names matter; they are the handles by which you grab things." (Scott Rosenberg, "Dreaming in Code", 2007)
"The picture of digital progress that so many ardent boosters paint ignores the painful record of actual programmers’ epic struggles to bend brittle code into functional shape. That record is of one disaster after another, marking the field’s historical time line like craters. Anyone contemplating the start of a big software development project today has to contend with this unfathomably discouraging burden of experience. It mocks any newcomer with ambitious plans, as if to say, What makes you think you’re any different?" (Scott Rosenberg, "Dreaming in Code", 2007)
"The spec is the programmer’s bible, and, typically, the programmer is a fundamentalist: The spec’s word is law. Programmers are also, by nature and occupational demand, literal-minded. So the creation of specs calls for care and caution: You need to be careful what you wish for, as in a fairy tale." (Scott Rosenberg, "Dreaming in Code", 2007)
"There is almost always something you can pull off the shelf that will satisfy many of your needs. But usually the parts of what you need done that your off-the-shelf code won’t handle are the very parts that make your new project different, unique, innovative - and they’re why you’re building it in the first place." (Scott Rosenberg, "Dreaming in Code", 2007)
"There is no reliable relationship between the volume of code produced and the state of completion of a program, its quality, or its ultimate value to a user." (Scott Rosenberg, "Dreaming in Code", 2007)
"To programmers, refactoring means rewriting a chunk of code to make it briefer, clearer, and easier to read without changing what it actually does. Refactoring is often compared to gardening; it is never finished." (Scott Rosenberg, "Dreaming in Code", 2007)
"Users may be annoyed by bugs, and software developers may be disappointed by their inability to perfect their work, and managers may be frustrated by the unreliability of their plans. But in the end, none of that matters as much as the simple fact that software does not work the way we think, and until it does, it is not worth trying to perfect." (Scott Rosenberg, "Dreaming in Code", 2007)
"Well-commented code is one hallmark of good programming practice; it shows that you care about what you’re doing, and it is considerate to those who will come after you to fix your bugs. But comments also serve as a kind of back channel for programmer-to-programmer communication and even occasionally as a competitive arena or an outlet for silliness." (Scott Rosenberg, "Dreaming in Code", 2007)
"When people dream of streamlining the work of making software, most often they dream of standardized plug-in parts." (Scott Rosenberg, "Dreaming in Code", 2007)
"When we move some aspect of our lives into software code, it’s easy to be seduced by novel possibilities while we overlook how much we may be giving up. A well-designed program will make the most of those new capabilities without attempting to go against the grain of the physical world orientation that evolution has bequeathed us." (Scott Rosenberg, "Dreaming in Code", 2007)
"Writing the spec, a document that lays out copiously detailed instructions for the programmer, is a necessary step in any software building enterprise where the ultimate user of the product is not the same person as the programmer. The spec translates requirements - the set of goals or desires the software developer’s customers lay out - into detailed marching orders for the programmer to follow." (Scott Rosenberg, "Dreaming in Code", 2007)
No comments:
Post a Comment