The Mythical Man-Month: Essays on Software Engineering

This book was originally published in 1975, 16 years before the very first web site. This was the earliest days of software developement, and this was one of the earliest books on the subject. The world could have saved centuries of wasted effort and billions of dollars if the axioms in this book had been taken to heart from the beginning.

For example, one of the axioms is that "adding people to a late project makes it later." I've seen this play out myself many times: throwing more people at a problem usually doesn't work.

Another is "Plan to throw one away." (In case you were wondering where that came from.) This is the straight forward acknowledgement that no matter how much planning you do, you will probably not get it right, because there are always unforseen circumstances and changing requirements. You are most likely worried about all the wrong things because the value in the system isn't what you think it is. It is amazing how often afterthoughts become a system's main selling point, and many previously thought must-haves turn out to be unnecessary.

Many of these axioms form the basis of Agile methodology. In 1975 it was clear to the author that you cannot plan your way to a viable system. The title theses is that you can't count up man-months of effort in advance and arrive at an accurate estimate of how much a software system will cost or how long it will take to build it. Yet for decades, organizations insisted on creating a complete design, and "throwing it over the wall" to the development team to build it. That was the "waterfall" development process. And it didn't work.

There are still plenty of people in positions of authority who don't understand how software development is different from buildings and highways. Logically, it should not be different, but it is. If you want to understand why, read this book.

Code Complete: A Practical Handbook of Software Construction

This is another book that is as old as rocks, but it is still relevant today. It has been updated over time, but the latest edition from 2004 is still relevant.

This book is famous for for its comprehensive guidance on software development, offering a wealth of best practices and practical advice. It teaches how to enhance code quality, ensuring code is readable, maintainable, and robust. Its language-agnostic approach makes it a timeless resource for developers across various programming languages. The book is designed to serve both beginners and experienced programmers, providing foundational knowledge and deeper insights into improving coding practices. It promotes critical thinking and continuous improvement in coding decisions. Updated editions, like the second edition from 2004, keep the content relevant to modern software development trends. "Code Complete" remains an essential read for developers keen on refining their craft and producing high-quality software.

Design Patterns: Elements of Reusable Object-Oriented Software

This book is a great introduction to the concept of "patterns", with great examples. It is a little bit dated, having been written in 1994, which was before the widespread adoption of cloud computing platforms like Azure.

Patterns are useful as guidelines to software design, but they serve a particularly important role for architects. Established patterns form a vocabulary with which to describe an architecture that legitimize the design from an objective perspective. This helps protect the design from ill-advised revisions that are not consistent with the overall architecture. It is easier to defend an architecture that is based on well established patterns rather than the idiosyncratic habits of one architecture.

The biggest threat to any particular system's architecture is the devolution into team politics and contests among team members over who's idea wins in some controversy, instead focusing which ideas are most consistent with the overall architecture. To the extent that well established patterns are invoked in an architectural definition, it is easier to maintain those over the long term.

Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation

Continuous Integration / Continuous Delivery (CI/CD) is rising in popularity, but it is not always implemented appropriately. Taking incremental development to the unlimate level is only possible with the right amount of emphasis on the "TEST" part. This book has "Test" right in the name. You cannot deploy untested software to production, and you cannot manually test every aspect of the system every day. Testing must be thorough, automated, and intrinsic to the process.

Historically, software development has been been done in well defined cycles with a goal of producing well defined versions. For many kinds of systems, release cycles are important for coordinating across the entire business process. Users lose confidence when things are constantly changing, especially when something changes and then later changes back. Often, system changes must be coordinated with marketing campaigns or changes in regulatory requirements.

Agile methodologies, particulary "scrum", have shortened version cycles from many months to weeks, or even days. In theory, CI/CD is a way to eliminate version cycles alltogether. The degree to which such a thing is possible varies widely among different kinds of systems. Even when production releases have to be versioned for whatever reason, it is still possible to adopt continuous methods for pre-release versions (or "regions", such as DEV or QA.)

This book explores many of the issues that CI/CD raises.