Steve McConnell
Author of Code Complete: A Practical Handbook of Software Construction
About the Author
Steve McConnell is CEO and chief software engineer at Construx Software, where he oversees their software engineering practices, teaches classes, and writes books and articles
Image credit: DotNetRocks
Works by Steve McConnell
Professional Software Development: Shorter Schedules, Higher Quality Products, More Successful Projects, Enhanced Careers (1997) 153 copies, 1 review
Rapid Development 4 copies
We Delight 1 copy
Software Project Survival Guide How to Be Sure Your First Important Project Isnt Your Last (1997) 1 copy
More Effective Agile 1 copy
Tagged
Common Knowledge
- Legal name
- McConnell, Steven C.
- Birthdate
- 1962-09-03
- Gender
- male
- Education
- Seattle University (MS)
Whitman College (BS|magna cum laude) - Organizations
- Construx Software
- Nationality
- USA
- Map Location
- USA
Members
Reviews
Software estimation is a somewhat undefined craft. Most coders simply "go with their gut" in estimating a project, and that gut is often wildly off. Alternative techniques involve intense calculations that take a lot of time, but rarely yield enough accuracy to help, especially for smaller projects. Unlike, say, construction or mechanical tasks, software builds represent a creative process where new territory is tread with each project. There's a learning curve involved, and it's hard to show more determine what that learning curve might be for each individual coder. Steve McConnell, an award-winning author about software development, throws out a series of ideas that might help.
Although the book is twenty years old, the human practices are eerily familiar. It references more agile techniques, which at the book's writing would have been cutting edge, but it makes a strong case that traditional practices might better estimate each agile sprint's time than newer techniques (like powers-of-two estimation or Fibonacci estimation) that aren't bound to any reality-based measure.
My takeaways are that estimation should always involve a confidence interval, and that confidence interval will tighten over time as shown by the "cone of uncertainty." Programmers should always be heavily consulted when making estimates, but their estimates tend to be overly optimistic. Estimates should never be viewed as commitments by the software business community. Going with one's gut should first be supplemented by counting tasks and historical analyses of past results. That is, count, then compute, then judge. Finally, hitting the bull's eye of +/- 10% is a noteworthy accomplishment.
Anyone studying software estimation should also consult more recent books on the topic, but Steve McConnell's thoroughness should not be avoided. Obviously, some of what he reports here has gone the way of history, but the human practice of software estimation has not evolved that much in twenty years to make his erudite treatment irrelevant. This book should still be consulted on a software development manager's reading list. I, for one, am glad I consulted it as I educate myself about my personal weaknesses of estimating software times for my team. show less
Although the book is twenty years old, the human practices are eerily familiar. It references more agile techniques, which at the book's writing would have been cutting edge, but it makes a strong case that traditional practices might better estimate each agile sprint's time than newer techniques (like powers-of-two estimation or Fibonacci estimation) that aren't bound to any reality-based measure.
My takeaways are that estimation should always involve a confidence interval, and that confidence interval will tighten over time as shown by the "cone of uncertainty." Programmers should always be heavily consulted when making estimates, but their estimates tend to be overly optimistic. Estimates should never be viewed as commitments by the software business community. Going with one's gut should first be supplemented by counting tasks and historical analyses of past results. That is, count, then compute, then judge. Finally, hitting the bull's eye of +/- 10% is a noteworthy accomplishment.
Anyone studying software estimation should also consult more recent books on the topic, but Steve McConnell's thoroughness should not be avoided. Obviously, some of what he reports here has gone the way of history, but the human practice of software estimation has not evolved that much in twenty years to make his erudite treatment irrelevant. This book should still be consulted on a software development manager's reading list. I, for one, am glad I consulted it as I educate myself about my personal weaknesses of estimating software times for my team. show less
Steve McConnell is one of the best writers about software practices in our generation. Over decades, each of his books pushes the field forward, and each new book updates his thought with oodles of new data. This book, an evidence-based look at Agile, is no exception. Agile has become a catch-all term for a lot of software practices, but McConnell recenters his study about Agile on what's most important in a business - getting results.
His book addresses many layers of an organization: teams, show more work, and organization-wide dynamics. Again, he's grounded not in the latest fads but in a historical approach to software development. In previous books, he's looked a bit wary of Agile methodologies, but this book represents a full embrace. He's no purist, though, in search of a universally applicable perfect form of Agile. He's focused on getting practical results for any business. That combination makes this book excellent.
I especially appreciate the bibliography at the end of each chapter and have found a few new books to add onto my reading list. Agile techniques have transformed the software industry, yet many elements remain incompletely adopted. McConnell seeks to complete the system so that the business can benefit fully from Agile's innovations. He wants to bring adoption rates even higher so that businesses will move from partial adoption to fuller implementation of Agile's benefits.
I recommend this book to anyone involved in leading software efforts or ambitious to lead such efforts in the future. Like the rest of McConnell's literary corpus, this book represents one of the key works that leaders should read in order to lead their businesses effectively. It should stand as a seminal work in the field for a generation and thus deserves attention by software leaders. show less
His book addresses many layers of an organization: teams, show more work, and organization-wide dynamics. Again, he's grounded not in the latest fads but in a historical approach to software development. In previous books, he's looked a bit wary of Agile methodologies, but this book represents a full embrace. He's no purist, though, in search of a universally applicable perfect form of Agile. He's focused on getting practical results for any business. That combination makes this book excellent.
I especially appreciate the bibliography at the end of each chapter and have found a few new books to add onto my reading list. Agile techniques have transformed the software industry, yet many elements remain incompletely adopted. McConnell seeks to complete the system so that the business can benefit fully from Agile's innovations. He wants to bring adoption rates even higher so that businesses will move from partial adoption to fuller implementation of Agile's benefits.
I recommend this book to anyone involved in leading software efforts or ambitious to lead such efforts in the future. Like the rest of McConnell's literary corpus, this book represents one of the key works that leaders should read in order to lead their businesses effectively. It should stand as a seminal work in the field for a generation and thus deserves attention by software leaders. show less
For decades, the classic project-management challenge has been to produce software quicker with more features and less bugs. Software, however, has its revenge because scheduling it accurately and precisely is a highly inexact science. Even the best, seasoned estimators struggle at first attempt. This book by Steve McConnell, though written 30 years ago, gives communal sympathy towards development teams who can seemingly never meet a deadline. Further, he actually provides some answers on show more how to mitigate those human problems distracting from developing code quickly.
This book is not nearly as paradigm-shifting as McConnell's Code Complete, but it does provide an overview of management scenarios that a tech lead or manager will encounter in their professional lifetime. Though the technologies change, the human side shifts more slowly. Many managers still don't understand many details of what it takes to develop software, and this book provides strategies to engage in that dialogue.
In the past 30 years, some of the problems have been subsumed by other paradigm shifts, like agile development. The problems remain, but the language is different. In fact, I struggled to find his entire section on Best Practices relevant today since modern strategies use different terminologies to address the same problems. But for the most part, the identified problems present similarly today. It's helpful to think through these classical situations - and the classical missteps attempting to address those situations.
Readers who always want "the latest and the greatest" out of a technology book will be disappointed, but those seeking relatively timeless wisdom out of a classic book will benefit. McConnell was one of the greatest software writers of his era, and this book hits home on the perpetual need for rapid software development. At over 600 pages, it's more comprehensive, especially on the human side, than even more recent books addressing similar themes. It's well worth a technological leader's time to understand how to avoid pitfalls ahead of time in a software project. show less
This book is not nearly as paradigm-shifting as McConnell's Code Complete, but it does provide an overview of management scenarios that a tech lead or manager will encounter in their professional lifetime. Though the technologies change, the human side shifts more slowly. Many managers still don't understand many details of what it takes to develop software, and this book provides strategies to engage in that dialogue.
In the past 30 years, some of the problems have been subsumed by other paradigm shifts, like agile development. The problems remain, but the language is different. In fact, I struggled to find his entire section on Best Practices relevant today since modern strategies use different terminologies to address the same problems. But for the most part, the identified problems present similarly today. It's helpful to think through these classical situations - and the classical missteps attempting to address those situations.
Readers who always want "the latest and the greatest" out of a technology book will be disappointed, but those seeking relatively timeless wisdom out of a classic book will benefit. McConnell was one of the greatest software writers of his era, and this book hits home on the perpetual need for rapid software development. At over 600 pages, it's more comprehensive, especially on the human side, than even more recent books addressing similar themes. It's well worth a technological leader's time to understand how to avoid pitfalls ahead of time in a software project. show less
A must-read for any programmer. Although I don't agree with everything in the book and a few parts feel out of date, it provides an excellent framework for how to think about programming and software engineering. It can help programmers of all experience levels to focus on the right things: that code is harder to read than to write, that managing complexity is the main goal of programming, and so on.
The book is filled with nuggets of wisdom. Some of my favorite quotes, some from McConnell, show more some from other writers that he includes in the book:
One downside to the book is that it seems to largely focus on OO languages (C , Java) and even older imperative ones (C, Ada, etc). There is virtually no consideration given to functional programming. This is a shame, as immutable variables, pure functions, and lack of side effects inherently solve or mitigate MANY of the code complexity and readability problems he discusses in the book. I chuckled at a line in the book where he says "Recursion isn't useful often...", which is true in the languages he used, which don't support tail call optimization.
The book also pre-dates the open source explosion, github, cheap/free access to amazing tools and cloud services, and the growth of continuous integration/deployment. These have had some pretty profound impact on software development that are not taken into account in the book. show less
The book is filled with nuggets of wisdom. Some of my favorite quotes, some from McConnell, show more some from other writers that he includes in the book:
Managing complexity is the most important technical topic in software development. In my view, it's so important that Software's Primary Technical Imperative has to be managing complexity.
A "wicked" problem is one that can be clearly defined only by solving it.
It's OK to figure out murder mysteries, but you shouldn't need to figure out code. You should be able to read it.
Eighty percent of the errors are found in 20 percent of a project's classes or routines.
Don't document bad code - rewrite it.
Jackson's Rules of Optimization: Rule 1. Don't do it. Rule 2 (for experts only). Don't do it yet - that is, not until you have a perfectly clear and unoptimized solution.
No programmer has ever been able to predict or analyze where performance bottlenecks are without data. No matter where you think it's going, you will be surprised to discover that it is going somewhere else.
The Fundamental Theorem of Formatting says that good visual layout shows the logical structure of a program. Making the code look pretty is worth something, but it's worth less than showing the code's structure.
Build one to throw away; you will, anyhow.
One downside to the book is that it seems to largely focus on OO languages (C , Java) and even older imperative ones (C, Ada, etc). There is virtually no consideration given to functional programming. This is a shame, as immutable variables, pure functions, and lack of side effects inherently solve or mitigate MANY of the code complexity and readability problems he discusses in the book. I chuckled at a line in the book where he says "Recursion isn't useful often...", which is true in the languages he used, which don't support tail call optimization.
The book also pre-dates the open source explosion, github, cheap/free access to amazing tools and cloud services, and the growth of continuous integration/deployment. These have had some pretty profound impact on software development that are not taken into account in the book. show less
Lists
Awards
You May Also Like
Statistics
- Works
- 15
- Members
- 5,229
- Popularity
- #4,768
- Rating
- 4.1
- Reviews
- 35
- ISBNs
- 44
- Languages
- 11
- Favorited
- 13