05 October 2006

Steve C McConnell - Collected Quotes

"An algorithm gives you the instructions directly. A heuristic tells you how to discover the instructions for yourself, or at least where to look for them." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"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." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"Because successful programming depends on minimizing complexity, a skilled programmer will build in as much flexibility as needed to meet the software's requirements but will not add flexibility - and related complexity - beyond what's required." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"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."(Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"Complexity in all forms - complicated algorithms, large data sets, intricate communications protocols, and so on - is prone to errors. If an error does occur, it will be easier to find if it isn't spread through the code but is localized within a class. Changes arising from fixing the error won't affect other code because only one class will have to be fixed - other code won't be touched. If you find a better, simpler, or more reliable algorithm, it will be easier to replace the old algorithm if it has been isolated into a class. During development, it will be easier to try several designs and keep the one that works best." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"Design is sloppy because a good solution is often only subtly different from a poor one." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"Encapsulation says that, not only are you allowed to take a simpler view of a complex concept, you are not allowed to look at any of the details of the complex concept. What you see is what you get - it's all you get!" (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"From time to time, a complex algorithm will lead to a longer routine, and in those circumstances, the routine should be allowed to grow organically up to 100–200 lines. (A line is a noncomment, nonblank line of source code.) Decades of evidence say that routines of such length are no more error prone than shorter routines. Let issues such as the routine's cohesion, depth of nesting, number of variables, number of decision points, number of comments needed to explain the routine, and other complexity-related considerations dictate the length of the routine rather than imposing a length restriction per se." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"If you're passing a parameter among several routines, that might indicate a need to factor those routines into a class that share the parameter as object data. Streamlining parameter passing isn't a goal, per se, but passing lots of data around suggests that a different class organization might work better." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"In software, consultants sometimes tell you to buy into certain software-development methods to the exclusion of other methods. That’s unfortunate because if you buy into any single methodology 100 percent, you’ll see the whole world in terms of that methodology. In some instances, you’ll miss opportunities to use other methods better suited to your current problem." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"[...] inheritance is a powerful tool for reducing complexity because a programmer can focus on the generic attributes of an object without worrying about the details. If a programmer must be constantly thinking about semantic differences in subclass implementations, then inheritance is increasing complexity rather than reducing it." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"Inheritance is the idea that one class is a specialization of another class. The purpose of inheritance is to create simpler code by defining a base class that specifies common elements of two or more derived classes. The common elements can be routine interfaces, implementations, data members, or data types. Inheritance helps avoid the need to repeat code and data in multiple locations by centralizing it within a base class. When you decide to use inheritance, you have to make several decisions: For each member routine, will the routine be visible to derived classes? Will it have a default implementation? Will the default implementation be overridable? For each data member (including variables, named constants, enumerations, and so on), will the data member be visible to derived classes?" (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"Modularity's goal is to make each routine or class like a 'black box': You know what goes in, and you know what comes out, but you don't know what happens inside." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"The concept of modularity is related to information hiding, encapsulation, and other design heuristics. But sometimes thinking about how to assemble a system from a set of black boxes provides insights that information hiding and encapsulation don't, so the concept is worth having in your back pocket." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"The underlying message of all these rules is that inheritance tends to work against the primary technical imperative you have as a programmer, which is to manage complexity. For the sake of controlling complexity, you should maintain a heavy bias against inheritance." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"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." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"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." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"Testing by itself does not improve software quality. Test results are an indicator of quality, but in and of themselves, they don't improve it. Trying to improve software quality by increasing the amount of testing is like trying to lose weight by weighing yourself more often. What you eat before you step onto the scale determines how much you will weigh, and the software development techniques you use determine how many errors testing will find. If you want to lose weight, don't buy a new scale; change your diet. If you want to improve your software, don't test more; develop better." (Steve C McConnell, "Code Complete: A Practical Handbook of Software Construction", 1993)

"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." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"The most challenging part of programming is conceptualizing the problem, and many errors in programming are conceptual errors." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"The source code is often the only accurate description of the software. On many projects, the only documentation available to programmers is the code itself. Requirements specifications and design documents can go out of date, but the source code is always up to date. Consequently, it's imperative that the code be of the highest possible quality." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"The words available in a programming language for expressing your programming thoughts certainly determine how you express your thoughts and might even determine what thoughts you can express." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"Watch for coupling that's too tight. 'Coupling' refers to how tight the connection is between two classes. In general, the looser the connection, the better. Several general guidelines flow from this concept: Minimize accessibility of classes and members. Avoid friend classes, because they're tightly coupled. Make data private rather than protected in a base class to make derived classes less tightly coupled to the base class. Avoid exposing member data in a class's public interface. Be wary of semantic violations of encapsulation. Observe the 'Law of Demeter' [...]. Coupling goes hand in glove with abstraction and encapsulation. Tight coupling occurs when an abstraction is leaky, or when encapsulation is broken." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"A typical software project can present more opportunities to learn from mistakes than some people get in a lifetime." (Steve McConnell, "Rapid Development", 1996)

"Even when you have skilled, motivated, hard-working people, the wrong team structure can undercut their efforts instead of catapulting them to success. A poor team structure can increase development time, reduce quality, damage morale, increase turnover, and ultimately lead to project cancellation." (Steve McConnell, "Rapid Development", 1996)

"Motivation is undoubtedly the single greatest influence on how well people perform. Most productivity studies have found that motivation has a stronger influence on productivity than any other factor."  (Steve McConnell, "Rapid Development", 1996)

"It's better to wait for a productive programmer to become available than it is to wait for the first available programmer to become productive." (Steve McConnell, "Software Project Survival Guide", 1997)

"Software projects fail for one of two general reasons: the project team lacks the knowledge to conduct a software project successfully, or the project team lacks the resolve to conduct a project effectively." (Steve McConnell, "Software Project Survival Guide", 1997)

"The default movement on a software project should be in the direction of taking elements of the software away to make it simpler rather than adding elements to make it more complex." (Steve McConnell, "Software Project Survival Guide", 1997)

"The job of the average manager requires a shift in focus every few minutes. The job of the average software developer requires that the developer not shift focus more often than every few hours." (Steve McConnell, "Software Project Survival Guide", 1997)

"Trying to apply formal methods to all software projects is just as bad as trying to apply code-and-fix development to all projects." (Steve McConnell, "After the Gold Rush: Creating a True Profession of Software Engineering", 1999)

"A brute force solution that works is better than an elegant solution that doesn't work." (Steve C McConnell, "Code Complete: A Practical Handbook of Software Construction" 2nd Ed., 2004)

"Building software implies various stages of planning, preparation and execution that vary in kind and degree depending on what's being built." (Steve C McConnell, "Code Complete: A Practical Handbook of Software Construction" 2nd Ed., 2004)

"Design patterns provide the cores of ready-made solutions that can be used to solve many of software’s most common problems. Some software problems require solutions that are derived from first principles. But most problems are similar to past problems, and those can be solved using similar solutions, or patterns." (Steve C McConnell, "Code Complete: A Practical Handbook of Software Construction" 2nd Ed., 2004)

"In addition to their complexity-management benefit, design patterns can accelerate design discussions by allowing designers to think and discuss at a larger level of granularity." (Steve C McConnell, "Code Complete: A Practical Handbook of Software Construction" 2nd Ed., 2004)

"In software, the chain isn't as strong as its weakest link; it's as weak as all the weak links multiplied together." (Steve C McConnell, "Code Complete: A Practical Handbook of Software Construction" 2nd Ed., 2004)

"Design is heuristic. Dogmatic adherence to any single methodology hurts creativity and hurts your programs." (Steve C McConnell, "Code Complete: A Practical Handbook of Software Construction" 2nd Ed., 2004)

"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." (Steve C McConnell, "Code Complete: A Practical Handbook of Software Construction" 2nd Ed., 2004)

"Simplicity is achieved in two general ways: minimizing the amount of essential complexity that anyone's brain has to deal with at any one time, and keeping accidental complexity from proliferating needlessly." (Steve C McConnell, "Code Complete: A Practical Handbook of Software Construction" 2nd Ed., 2004)

"A good estimate is an estimate that provides a clear enough view of the project reality to allow the project leadership to make good decisions about how to control the project to hit its targets." (Steve McConnell, "Software Estimation: Demystifying the Black Art", 2006)

"Be sure you understand whether you're presenting uncertainty in an estimate or uncertainty that affects your ability to meet a commitment." (Steve McConnell, "Software Estimation: Demystifying the Black Art", 2006)

"Don't expect better estimation practices alone to provide more accurate estimates for chaotic projects. You can't accurately estimate an out-of-control process." (Steve McConnell, "Software Estimation: Demystifying the Black Art", 2006)

"Don't intentionally underestimate. The penalty for underestimation is more severe than the penalty for overestimation. Address concerns about overestimation through planning and control, not by biasing your estimates." (Steve McConnell, "Software Estimation: Demystifying the Black Art", 2006)

"Not all estimation methods are equal. When looking for convergence or spread among estimates, give more weight to the techniques that tend to produce the most accurate results." (Steve McConnell, "Software Estimation: Demystifying the Black Art", 2006)

"Treat estimation discussions as problem solving, not negotiation. Recognize that all project stakeholders are on the same side of the table. Everyone wins, or everyone loses." (Steve McConnell, "Software Estimation: Demystifying the Black Art", 2006)

"The primary purpose of software estimation is not to predict a project's outcome; it is to determine whether a project's targets are realistic enough to allow the project to be controlled to meet them." (Steve McConnell, "Software Estimation: Demystifying the Black Art", 2006)

No comments:

Related Posts Plugin for WordPress, Blogger...

About Me

My photo
Koeln, NRW, Germany
IT Professional with more than 24 years experience in IT in the area of full life-cycle of Web/Desktop/Database Applications Development, Software Engineering, Consultancy, Data Management, Data Quality, Data Migrations, Reporting, ERP implementations & support, Team/Project/IT Management, etc.