Code Complete Quotes

9,456 ratings, 4.30 average rating, 446 reviews
Code Complete Quotes
Showing 91-120 of 130
“The more independent the subsystems are, the more you make it safe to focus on one bit of complexity at a time. Carefully defined objects separate concerns so that you can focus on one thing at a time. Packages provide the same benefit at a higher level of aggregation.”
― Code Complete
― Code Complete
“At the software-architecture level, the complexity of a problem is reduced by dividing the system into subsystems. Humans have an easier time comprehending several simple pieces of information than one complicated piece.”
― Code Complete
― Code Complete
“One symptom that you have bogged down in complexity overload is when you find yourself doggedly applying a method that is clearly irrelevant, at least to any outside observer. It is like the mechanically inept person whose car breaks down—so he puts water in the battery and empties the ashtrays. — P. J. Plauger”
― Code Complete
― Code Complete
“Dijkstra pointed out that no one's skull is really big enough to contain a modern computer program (Dijkstra 1972), which means that we as software developers shouldn't try to cram whole programs into our skulls at once; we should try to organize our programs in such a way that we can safely focus on one part of it at a time.”
― Code Complete
― Code Complete
“the automatic computer confronts us with a radically new intellectual challenge that has no precedent in our history." Of course software has become even more complex since 1989, and Dijkstra's ratio of 1 to 109could easily be more like 1 to 1015 today.”
― Code Complete
― Code Complete
“Computing pioneer Edsger Dijkstra pointed out that computing is the only profession in which a single mind is obliged to span the distance from a bit to a few hundred megabytes, a ratio of 1 to 109, or nine orders of magnitude (Dijkstra 1989).”
― Code Complete
― Code Complete
“Design is also sloppy because it's hard to know when your design is "good enough." How much detail is enough? How much design should be done with a formal design notation, and how much should be left to be done at the keyboard? When are you done? Since design is open-ended, the most common answer to that question is "When you're out of time.”
― Code Complete
― Code Complete
“Design is sloppy because a good solution is often only subtly different from a poor one.”
― Code Complete
― Code Complete
“Programming assignments in school are devised to move you in a beeline from beginning to end. You'd probably want to tar and feather a teacher who gave you a programming assignment, then changed the assignment as soon as you finished the design, and then changed it again just as you were about to turn in the completed program. But that very process is an everyday reality in professional programming.”
― Code Complete
― Code Complete
“One of the main differences between programs you develop in school and those you develop as a professional is that the design problems solved by school programs are rarely, if ever, wicked.”
― Code Complete
― Code Complete
“The picture of the software designer deriving his design in a rational, error-free way from a statement of requirements is quite unrealistic. No system has ever been developed in that way, and probably none ever will. Even the small program developments shown in textbooks and papers are unreal. They have been revised and polished until the author has shown us what he wishes he had done, not what actually did happen. — David Parnas Paul Clements”
― Code Complete
― Code Complete
“Design Is a Wicked Problem Horst Rittel and Melvin Webber defined a "wicked" problem as one that could be clearly defined only by solving it, or by solving part of it (1973). This paradox implies, essentially, that you have to "solve" the problem once in order to clearly define it and then solve it again to create a solution that works.”
― Code Complete
― Code Complete
“On small, informal projects, a lot of design is done while the programmer sits at the keyboard. "Design" might be just writing a class interface in pseudocode before writing the details. It might be drawing diagrams of a few class relationships before coding them. It might be asking another programmer which design pattern seems like a better choice. Regardless of how it's done, small projects benefit from careful design just as larger projects do, and recognizing design as an explicit activity maximizes the benefit you will receive from it.”
― Code Complete
― Code Complete
“Error processing is turning out to be one of the thorniest problems of modern computer science, and you can't afford to deal with it haphazardly. Some people have estimated that as much as 90 percent of a program's code is written for exceptional, error-processing cases or housekeeping, implying that only 10 percent is written for nominal cases (Shaw in Bentley 1982). With so much code dedicated to handling errors, a strategy for handling them consistently should be spelled out in the architecture.”
― Code Complete
― Code Complete
“Programmers who program "into" a language first decide what thoughts they want to express, and then they determine how to express those thoughts using the tools provided by their specific language.”
― Code Complete
― Code Complete
“One key to successful programming is avoiding arbitrary variations so that your brain can be free to focus on the variations that are really needed.”
― Code Complete
― Code Complete
“One effective approach is to determine a range of accuracy that is acceptable and then use a boolean function to determine whether the values are close enough.”
― Code Complete
― Code Complete
“Too much of anything is bad, but too much whiskey is just enough. — Mark Twain”
― Code Complete
― Code Complete
“Classes and routines are first and foremost intellectual tools for reducing complexity. If they're not making your job simpler, they're not doing their jobs.”
― Code Complete
― Code Complete
“By far the most common project risks in software development are poor requirements and poor project planning, thus preparation tends to focus on improving requirements and project plans.”
― Code Complete
― Code Complete
“Quicksort a few times, but what are the odds that your custom version will be fully correct on the first try?”
― Code Complete
― Code Complete
“On their way to America, the Pilgrims argued about the best maximum length for a routine. After arguing about it for the entire trip, they arrived at Plymouth Rock and started to draft the Mayflower Compact. They still hadn’t settled the maximum-length question, and since they couldn’t disembark until they’d signed the compact, they gave up and didn’t include it. The result has been an interminable debate ever since about how long a routine can be.”
― Code Complete
― Code Complete
“There is no code so big, twisted, or complex that maintenance can't make it worse.”
― Code Complete
― Code Complete
“developers' estimates tend to have an optimism factor of 20 to 30 percent”
― Code Complete
― Code Complete
“Hurrying to solve a problem is one of the most time-ineffective things you can do.”
― Code Complete
― Code Complete
“defect corrections have more than a 50 percent chance of being wrong the first time”
― Code Complete
― Code Complete
“the error rate in manual testing is comparable to the bug rate in the code being tested.”
― Code Complete
― Code Complete
“Eighty percent of the errors are found in 20 percent of a project's classes or routines”
― Code Complete
― Code Complete
“it's done by creating 25 times as many dirty tests”
― Code Complete
― Code Complete
“Mature testing organizations tend to have five dirty tests for every clean test.”
― Code Complete
― Code Complete