Here are 95 books that 201 Principles of Software Development fans have personally recommended if you like
201 Principles of Software Development.
Shepherd is a community of 12,000+ authors and super readers sharing their favorite books with the world.
I’ve spent most of my life writing code—and too much of that life teaching new programmers how to write code like a professional. If it’s true that you only truly understand something after teaching it to someone else, then at this point I must really understand programming! Unfortunately, that understanding has not led to an endless stream of bug-free code, but it has led to some informed opinions on programming and books about programming.
A thoroughly fascinating (and fascinatingly thorough) look at engineering practices at Google.
It’s an encyclopedia written by a bunch of authors, so some of the chapters are a little dry, but for those of us who aren’t on teams with 25,000 engineers it’s spell-binding to see what programming at that sort of scale looks like. Some of the chapters prompted us to think really hard about the way we do things at Sucker Punch.
Today, software engineers need to know not only how to program effectively but also how to develop proper engineering practices to make their codebase sustainable and healthy. This book emphasizes this difference between programming and software engineering.
How can software engineers manage a living codebase that evolves and responds to changing requirements and demands over the length of its life? Based on their experience at Google, software engineers Titus Winters and Hyrum Wright, along with technical writer Tom Manshreck, present a candid and insightful look at how some of the world's leading practitioners construct and maintain software. This book covers…
I first learned to program in college in 1970. Since then I’ve spent much time as a software developer, manager, tester, process improvement leader, consultant, trainer, author, and, of course, a user. I quickly learned that I didn’t have time to make all the mistakes that every software developer before me had already made. My training and writing career has involved sharing what I and others have learned with audiences to help them quickly become more effective software development team members, regardless of their project role. This book distills insights and observations both from my own experience and from what I’ve heard from thousands of students and consulting clients.
Robert Glass is one of the foundational leaders of the discipline of software engineering. He’s done it all and seen it all. This book includes 55 facts and 10 fallacies about many aspects of software engineering, grouped into the major categories of management, the life cycle, and quality. Based on my own experience, I can vouch for the validity of all the points Glass makes.
These timeless truths can help you avoid going down an ineffective path, wasting time only to rediscover the same facts on your own. There’s no need to retrace the missteps from the past. Books like this can keep your energies focused where they will provide the most value to your customers.
The practice of building software is a "new kid on the block" technology. Though it may not seem this way for those who have been in the field for most of their careers, in the overall scheme of professions, software builders are relative "newbies."
In the short history of the software field, a lot of facts have been identified, and a lot of fallacies promulgated. Those facts and fallacies are what this book is about.
There's a problem with those facts-and, as you might imagine, those fallacies. Many of these fundamentally important facts are learned by a software engineer, but…
I first learned to program in college in 1970. Since then I’ve spent much time as a software developer, manager, tester, process improvement leader, consultant, trainer, author, and, of course, a user. I quickly learned that I didn’t have time to make all the mistakes that every software developer before me had already made. My training and writing career has involved sharing what I and others have learned with audiences to help them quickly become more effective software development team members, regardless of their project role. This book distills insights and observations both from my own experience and from what I’ve heard from thousands of students and consulting clients.
Most books about lessons learned and good practices tell you what you ought to be doing. AntiPatterns warns you about things you should not be doing. It points out a wide range of software project approaches that the authors believe are not advisable. The antipatterns have whimsical titles such as Poltergeists, Golden Hammer, Spaghetti Code, Stovepipe System, and Design by Committee. Each pattern describes the symptoms, causes, and consequences of that particular behavior, as well as offering a restructured approach that’s likely to yield better results. As with other lessons-learned books, this book lets you learn from the pain suffered by others to avoid stepping into the same traps on your own projects.
"The AntiPatterns authors have clearly been there and done that when it comes to managing software development efforts. I resonated with one insight after another, having witnessed too many wayward projects myself. The experience in this book is palpable." -John Vlissides, IBM Research "This book allows managers, architects, and developers to learn from the painful mistakes of others. The high-level AntiPatterns on software architecture are a particularly valuable contribution to software engineering. Highly recommended!" -Kyle Brown Author of The Design Patterns Smalltalk Companion "AntiPatterns continues the trend started in Design Patterns. The authors have discovered and named common problem situations…
I first learned to program in college in 1970. Since then I’ve spent much time as a software developer, manager, tester, process improvement leader, consultant, trainer, author, and, of course, a user. I quickly learned that I didn’t have time to make all the mistakes that every software developer before me had already made. My training and writing career has involved sharing what I and others have learned with audiences to help them quickly become more effective software development team members, regardless of their project role. This book distills insights and observations both from my own experience and from what I’ve heard from thousands of students and consulting clients.
One way to craft lessons learned is in the form of recommended best practices (or, as I prefer, “good practices”). Best practices represent collected and distilled wisdom from many observers, many projects, and many years of experience. Rapid Development includes 27 best practices for software development, with one chapter devoted to each. Although the book was published more than 25 years ago, most of these are still relevant. Indeed, several of them have been incorporated into routine contemporary practices: evolutionary delivery, designing for change, timebox development, and requirements scrubbing. Techniques such as inspections, miniature milestones, principled negotiation, and reuse are perennially pertinent.
Corporate and commercial software-development teams all want solutions for one important problem-how to get their high-pressure development schedules under control. In RAPID DEVELOPMENT, author Steve McConnell addresses that concern head-on with overall strategies, specific best practices, and valuable tips that help shrink and control development schedules and keep projects moving. Inside, you'll find:
A rapid-development strategy that can be applied to any project and the best practices to make that strategy work Candid discussions of great and not-so-great rapid-development practices-estimation, prototyping, forced overtime, motivation, teamwork, rapid-development languages, risk management, and many others A list of classic mistakes to avoid for…
I’ve been a professional software engineer and maintaining open-source software for 16 years. My work on open source has been heavily informed by industry best practises and my work on proprietary software has been heavily informed by open source best practises. Without these books, I’d be a worse engineer on many dimensions. Some of them may feel antiquated but all are still full of relevant wisdom for every open-source (and proprietary) software engineer today.
I was lucky enough to read an early draft of this book and it’s simply the best analysis of the open-source software ecosystem around today.
The writing style is friendly and not formal despite the academic-level research that went into this book. It made me think differently about the open-source projects I maintain and how I interact and chose those I use.
An inside look at modern open source software development and its influence on our online social world.
Open source software, in which developers publish code that anyone can use, has long served as a bellwether for other online behavior. In the late 1990s, it provided an optimistic model for public collaboration, but in the last 20 years it’s shifted to solo operators who write and publish code that's consumed by millions.
In Working in Public, Nadia Eghbal takes an inside look at modern open source software development, its evolution over the last two decades, and its ramifications for an internet…
I’ve been doing large-scale software development at great US businesses from the introduction of the PC to the cloud explosion. From my earliest successes (online banking at US Bank in 1985!) to my biggest failures (Wells Fargo “Core” disaster in 2006), I’ve always sought better ways of doing things. These five books all were important to my learning and remain highly relevant, and I hope you find them useful as well.
This book helped me set my initial approach to software development and I still periodically return to it for grounding.
An MIT project theorized that new-fangled PC software developers knew something mainframe and mini-computer makers didn’t. MIT’s research revealed something else entirely: Microsoft had uniquely effective ideas on how to build complex products in rapidly evolving competitive markets. Here is “agile” before it was put into the Manifesto in 2001, in a more complete form. Ever wonder where the idea of a team comprising functional specialists with overlapping roles, united by a common goal, came from? Or incremental feature evolution with periodic synchronization and constant testing? Early brilliance still of foundational relevance, in a coherent and engaging form.
Drawing on observation, interviews, and confidential data, the authors reveal Microsoft's product development, marketing, and organizational strategies.
I've been in the software engineering profession for over 40 years, working at companies as diverse as Bank Leumi, Jet Propulsion Laboratory, Graftek (a CAD startup), Silicon Graphics, Boeing, and Microsoft. As an architect, lead, manager, director, writer, and now career coach, I've been obsessed with finding practical ways to make my work easier, my staff and clients more productive, and our products more delightful. These five books (along with my book and blog) provide proven, time-tested techniques. Each is written clearly with real-life examples, so it is easy to reap the benefits. Smile as you learn to avoid the missteps made by those who coded before you.
Not only does this book provide insight into the planning and development of one of the first visual IDEs, it’s overflowing with hilarious, profound, and pragmatic real-life lessons for how to manage a software team and deliver a complex project.
As a product of its time, the writing isn’t always politically correct. However, many of the lessons and memes are still part of our vernacular today: Don’t flip the bozo bit; If you build it, it will ship; and [Love] the customer.
Some of its lessons should be memes: Beware of [an engineer] in a room, Be an authority, not an authority figure, and Don’t trade a bad date for an equally bad date.
Some sections show their age in our current world of continuous delivery, but few current books have the humor and concise insight of this remarkable work.
Shipping great software can be done, insists McCarthy, and charts, in five sections, the progress from initial design to successful product. McCarthy is a software industry veteran and the director of the Microsoft Visual C++ development group.
Defining and managing the requirements for a software system is hard! I’ve been interested in improving how projects handle their requirements for more than 35 years. I realized how important this was when I saw how many projects—including my own—struggled and failed when they neglected to build a solid foundation of well-understood and clearly communicated requirements. I’ve personally used nearly all of the techniques described in my book Software Requirements, and I got always better results when I applied those techniques. My books, articles, training courses, presentations, and videos on requirements have been helpful to thousands of business analysts worldwide for many years.
Many agile projects employ user stories as a way to represent requirements rather than a more traditional approach combining use cases and functional requirements. I favor the latter approach for several reasons. Nonetheless, user stories are well established in the agile development world, and if you wish to learn about them, there’s no better author to read than Mike Cohn. Cohn describes how to craft user stories well and how they fit into the agile development process.
Thoroughly reviewed and eagerly anticipated by the agile community, User Stories Applied offers a requirements process that saves time, eliminates rework, and leads directly to better software.
The best way to build software that meets users' needs is to begin with "user stories": simple, clear, brief descriptions of functionality that will be valuable to real users. In User Stories Applied, Mike Cohn provides you with a front-to-back blueprint for writing these user stories and weaving them into your development lifecycle.
You'll learn what makes a great user story, and what makes a bad one. You'll discover practical ways to gather…
Markus Gärtner works as Organizational Design Consultant, Certified Scrum Trainer, and Agile Coach for it-agile GmbH, Hamburg, Germany. Markus, author of ATDD by Example - A Practical Guide to Acceptance Test-Driven Development, a student of the work of Jerry Weinberg, received the Most Influential Agile Testing Professional Person Award in 2013 and contributes to the Softwerkskammer, the German Software Craft movement. Markus regularly presents at Agile and testing conferences all over the globe, as well as dedicating himself to writing about agile software development, software craft, and software testing, foremost in an Agile context.
“Good agile testing is good context-driven testing applied in an agile context.”
The authors of this book summarize their decades of experience in software testing in over 100 lessons they learned. Follow them along different aspects of the tester’s job, as they re-tell various stories collected over the years with some clear guidance to surviving and testing project.
These software testing industry leaders have some timely contextual advice in here – whether you work as a tester on an agile team or in a more traditional fashion.
Decades of software testing experience condensed into the most important lessons learned.
The world's leading software testing experts lend you their wisdom and years of experience to help you avoid the most common mistakes in testing software. Each lesson is an assertion related to software testing, followed by an explanation or example that shows you the how, when, and why of the testing lesson. More than just tips, tricks, and pitfalls to avoid, Lessons Learned in Software Testing speeds you through the critical testing phase of the software development project without the extensive trial and error it normally takes to…
Computers have fascinated me since my childhood, having fond memories of my dad's ZX81, but even so I played around I was never truly captured by the programming until I recognized it as a way of writing rather than raw engineering. Through my studies of media sciences I found my fascination with how language can shape perception, and through my work in developer advocacy, I found how communities are shaped as well. Now I am fascinated with how different programming languages can shape thinking, having had the opportunity to solve problems at large companies in nonmainstream languages.
Distributed systems are everywhere now, but long before there were telephony switches, and Erlang was built to make those work.
Reading this book gave me not only an understanding about Erlang, but the language and understanding to talk and think about systems which are distributed from the beginning, not as an afterthought. For me personally Erlang/OTP is the DSL for dystributed system and the patterns implemented have applications every time I think about distributed systems now.
