Steve McConnell Quotes & Sayings

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

In software, the chain isn't as strong as its weakest link; it's as weak as all the weak links multiplied together. — Steve McConnell

A brute force solution that works is better than an elegant solution that doesn't work. — Steve McConnell

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

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

A typical software project can present more opportunities to learn from mistakes than some people get in a lifetime. — Steve McConnell

Eighty percent of the errors are found in 20 percent of a project's classes or routines — Steve McConnell

Building software implies various stages of planning, preparation and execution that vary in kind and degree depending on what's being built. [ ... ]
Building a four-foot tower requires a steady hand, a level surface, and 10 undamaged beer cans. Building a tower 100 times that size doesn't merely require 100 times as many beer cans. — Steve McConnell

The only way to reduce the variability in the estimate is to reduce the variability in the project. — Steve McConnell

You can do anything with stacks and iteration that you can do with recursion. — Steve McConnell

Reduce complexity. The single most important reason to create a routine is to reduce a program's complexity. Create a routine to hide information so that you won't need to think about it. — Steve McConnell

There are no secrets on an successful software project. Both good and bad news must be able to move up and down the ptoject hierarchy without restriction. — Steve McConnell

it's done by creating 25 times as many dirty tests — Steve McConnell

Hurrying to solve a problem is one of the most time-ineffective things you can do. — Steve McConnell

complicated code is a sign that you don't understand your program well enough to make it simple. — Steve McConnell

You save time when you don't need to have an awards ceremony every time a C statement does what it's supposed to. Moreover, — Steve McConnell

Engineering is the application of scientific principles toward practical ends. If the engineering isn't practical, it's bad engineering. — Steve McConnell

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. — Steve McConnell

11 years is a long time in this industry. — Steve McConnell

Copy and paste is a design error — Steve McConnell

Implement "is a" through public inheritance. When a programmer decides to create a new class by inheriting from an existing class, that programmer is saying that the new class "is a" more specialized version of the older class. The base class sets expectations about how the derived class will operate and imposes constraints on how the derived class can operate (Meyers 1998). — Steve McConnell

developers insert an average of 1 to 3 defects per hour into their designs and 5 to 8 defects per hour into code — Steve McConnell

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 McConnell

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. — Steve McConnell

Good code is its own best documentation. As you're about to add a comment, ask yourself, "How can I improve the code so that this comment isn't needed?" Improve the code and then document it to make it even clearer. — Steve McConnell

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

95% on content and the computer language remains the same. — Steve McConnell

It's hard enough to find an error in your code when you're looking for it; it's even harder when you've assumed your code is error-free. — Steve McConnell

the road to programming hell is paved with global variables, — Steve McConnell

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

Heuristic is an algorithm in a clown suit. It's less predictable, it's more fun, and it comes without a 30-day, money-back guarantee. — Steve McConnell

Favor read-time convenience to write-time convenience. Code — Steve McConnell

One of the paradoxes of defensive programming is that during development, you'd like an error to be noticeable - you'd rather have it be obnoxious than risk overlooking it. But during production, you'd rather have the error be as unobtrusive as possible, to have the program recover or fail gracefully. — Steve McConnell

In my experience, you either have encapsulation and abstraction or you have neither. There is no middle ground. — Steve McConnell

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. — Steve McConnell

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

defect corrections have more than a 50 percent chance of being wrong the first time — Steve McConnell

A blanket attempt to avoid mistakes is the biggest mistake of all. — Steve McConnell

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

in the vast majority of systems, efficiency isn't critical. — Steve McConnell

Avoid duplicate code. Undoubtedly the most popular reason for creating a routine is to avoid duplicate code. Indeed, creation of similar code in two routines implies an error in decomposition. Pull the duplicate code from both routines, put a generic version of the common code into a base class, and then move the two specialized routines into subclasses. — Steve McConnell

Programming requires more concentration than other activities. It's the reason programmers get upset about 'quick interruptions' - such interruptions are tantamount to asking a juggler to keep three balls in the air and hold your groceries at the same time. — Steve McConnell

Make interfaces programmatic rather than semantic when possible. Each interface consists of a programmatic part and a semantic part. The programmatic part consists of the data types and other attributes of the interface that can be enforced by the compiler. The semantic part of the interface consists of the assumptions about how the interface will be used, which cannot be enforced by the compiler. The semantic interface includes considerations such as "RoutineA must be called before RoutineB" or "RoutineA will crash if dataMember1 isn't initialized before it's passed to RoutineA." The semantic interface should be documented in comments, but try to keep interfaces minimally dependent on documentation. Any aspect of an interface that can't be enforced by the compiler is an aspect that's likely to be misused. Look for ways to convert semantic interface elements to programmatic interface elements by using Asserts or other techniques. — Steve McConnell

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" (discussed in Design and Implementation Issues of this chapter). Coupling goes hand in glove with abstraction and encapsulation. Tight coupling occurs when an abstraction is leaky, or when encapsulation is broken. — Steve McConnell

developer testing should probably take 8 to 25 percent of the total project time. — Steve McConnell

It's OK to figure out murder mysteries, but you shouldn't need to figure out code. You should be able to read it. — Steve McConnell

If the derived class isn't going to adhere completely to the same interface contract defined by the base class, inheritance is not the right implementation technique. Consider containment or making a change further up the inheritance hierarchy. — Steve McConnell

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

Be critical of classes that contain more than about seven data members. The — Steve McConnell

Programmers working with high-level languages achieve better productivity and quality than those working with lower-level languages. Languages such as C++, Java, Smalltalk, and Visual Basic have been credited with improving productivity, reliability, simplicity, and comprehensibility by factors of 5 to 15 over low-level languages such as assembly and C (Brooks 1987, Jones 1998, Boehm 2000). You save time when you don't need to have an awards ceremony every time a C statement does what it's supposed to. — Steve McConnell

once gotos are introduced, they spread through the code like termites through a rotting house. — Steve McConnell

Mature testing organizations tend to have five dirty tests for every clean test. — Steve McConnell

Use locking to control access to global variables. Similar to concurrency control in a multiuser database environment, locking requires that before the value of a global variable can be used or updated, the variable must be "checked out." After the variable is used, it's checked back in. During the time it's in use (checked out), if some other part of the program tries to check it out, the lock/unlock routine displays an error message or fires an assertion. — Steve McConnell

Spend your time on the 20 percent of the refactorings that provide 80 percent of the benefit. — Steve McConnell

Study after study has shown that motivation probably has a larger effect on productivity and quality than any other factor — Steve McConnell

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 McConnell

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. — Steve McConnell

Good visual layout shows the logical structure of a program. — Steve McConnell

Inheritance adds complexity to a program, and, as such, it's a dangerous technique. As Java guru Joshua Bloch says, "Design and document for inheritance, or prohibit it." If a class isn't designed to be inherited from, make its members non-virtual in C++, final in Java, or non-overridable in Microsoft Visual Basic so that you can't inherit from it. — Steve McConnell

The trouble with quick and dirty is that dirty remains long after quick has been forgotten. — Steve McConnell

Immature testing organizations tend to have about five clean tests for every dirty test. — Steve McConnell

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 McConnell

Be sure that the names you choose favor read-time convenience over write-time convenience. — Steve McConnell

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 McConnell

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 McConnell

Choose your battles. If rapid development is truly top priority, don't shackle your developers by insisting on too many priorities at once. — Steve McConnell

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. — Steve McConnell

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

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 McConnell

Another good reason to create a class is to model an abstract object - an object that isn't a concrete, real-world object but that provides an abstraction of other concrete objects. A good example is the classic Shape object. Circle and Square really exist, but Shape is an abstraction of other specific shapes. — Steve McConnell