74 books like Rapid Development

Many of the most significant principles of effective software development are timeless. They’re independent of the development life cycle or model, programming language, application type, and so forth. Although this book is quite a few years old now, nearly all of its contents are still valid. The 201 principles cover the full spectrum of software engineering: general principles, requirements engineering, design, coding, testing, management, product assurance, and evolution. The descriptions of each principle are concise, whereas my 60 lessons in Software Development Pearls go into a great deal more detail and offer many practical techniques.

There’s an unfortunate tendency among young software people to disregard knowledge from the past as irrelevant to them. That’s not correct. This book can help close significant gaps in any practicing software developer’s knowledge.

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.

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.

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.

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.

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.

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.

“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.

During the early years of my career as a software developer, I regularly developed very small programs that would exercise parts of the system that I was working on back then. I realized very quickly that those small programs would save me a lot of time figuring out whether the changes that I made would actually work or not. Until at some point a colleague mentioned the concept of Test-Driven Development. I first did some experimentation, dipping a toe into the water to feel the temperature. It wasn’t until the first time I picked up this book that I jumped right in. From then moment on, it all made sense. Although this book was published back in 2002, for me it still is the book when it comes to the subject of Test-Driven Development.      

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.