Steve McConnell

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

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

Code Complete is a 850-page tome which might serve as Computer Science guru-author Steve McConnell's magnum opus. His presentation addresses an audience that spans programmers at the beginning level, intermediate level, and advanced level. With its wide-ranging scope, it fills in any computer scientist's holes of knowledge.

Units are filled with a handful of chapters each and consist of foundations, producing high-quality code, variables, statements, improvements, systemic issues, and show more craftsmanship. McConnell aims and succeeds at addressing core issues of how software is actually constructed.

I appreciate how much he addresses the team aspect of computer science. For me, this has been lacking in my education. I've worked hard at developing computer programming as a mathematical exercise. McConnell seems to conceptualize the practice more as a sports team, with individuals at varying degrees of core competencies and varying types of skills. As such, he puts forth ideas as computer code as communication in a forceful (again, 850 pages, 35 chapters) approach that I have not read or seen before.

The book is well-researched with frequent citations of studies, books, and papers. It attempts to bring its recommendations with hard facts, not simply sage advice. Further, it provides bibliographies at the end of every chapter with recommendations for further reading. I find that computer scientists are traditionally weak when it comes to reading the literature, and this type of book-list is hard to find. As one who learns best by close, quiet reading, I appreciate the well-commented references. 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