Over a million developers have joined DZone.


DZone's Guide to


· DevOps Zone ·
Free Resource

Is the concept of adopting a continuous everything model a daunting task for your fast moving business? Read this whitepaper to break down and understand one of the key pillars of this model in Continuous Governance: The Guardrails for Continuous Everything.

Or everything you should know about building software!

While in London last year I met up with Dave Ingram, author of Design-Build-Run. It's subtitled "Applied Practices and Principles for Production-Ready Software Development" but I like to think of it as "Everything you should know about building software". I've been working as a software developer since 1996 and during that time I've worked on a number of different projects for different customers. Some have been big, while others have been small. Some have been desktop applications, while others have been deployed on the web. Some have been very structured, while others have been less formal. I've had relative freedom on some and been restricted on others.

While the overall goal of all these projects was to develop software, each project brought its own challenges and experiences. One of the things that I most like about working in a consulting environment is that it can genuinely give you a very wide variety of work and this means that you tend to learn a lot in a comparatively short amount of time. You obviously get to learn lots of major things (new technologies, new ways to design software, etc) but there are a number of other things that you learn about too, particularly around some of the nuances of software development and the actual process of building software.

Design-Build-RunIf you can imagine somebody sharing this sort of experience through a book about software development, then basically you have Design-Build-Run. Want to know about the sort of things that you should do in order to run a serious, high quality software project? No problem, chapter 3, Preparing for "Production", has the answers (including things like understanding architectural drivers and constraints). Want to know how to build software that operations staff can actually monitor? No problem, chapters 8 and 20 have information about logging, event logs, performance counters and so on. Want to know what sticky sessions are? Turn to page 207, where you'll also find information about a number of load balancing algorithms too. Want to know how to catch exceptions in your code and retry the transaction? Turn to page 550 where you'll find explanations of the various ways in which transactions can fail and some sample code that illustrates a "wait-retry" pattern.

The breadth of knowledge in this book is immense but the technical depth backing it up is there too; covering everything from planning and running projects through to designing, building and testing software. The book doesn't focus on particular technologies, frameworks or fashions; instead it explores and explains the important stuff that software developers really should know. The only niggles I have with the book are that it's pretty hefty at 650 pages and I think that some of the content may have worked better if it was collocated. For example, there's some excellent content about alerting and monitoring, but it's broken across a couple of chapters at opposite ends of the book. When you look at the breadth and depth of content in the book, these really are minor things though and the content is still very easy to find.

If you're a software developer looking for a way to fast-track your experience, you should definitely take a look at Dave's book. It really does contain everything that you should know about building software.

Are you looking for greater insight into your software development value stream? Check out this whitepaper: DevOps Performance: The Importance of Measuring Throughput and Stability to see how CloudBees DevOptics can give you the visibility to improve your continuous delivery process.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}