At Don’t Panic Labs, we have a pretty well thought out philosophy of software development. Philosophy is the combination of two Greek words philo (or “lover”) and sophia (or “wisdom”). So philosophy could be considered “love of wisdom.” Software development is what we do every day. We want to be wise software developers.
We didn’t invent most of what we talk about. We do have some of our own inventions, but in most cases we have our own synthesis of existing best practices.
The starting point for our wisdom comes from the father of software engineering, David Parnas. His paper, “On the Criteria To Be Used in Decomposing Systems into Modules” describes a lot of things in software we are still trying to achieve. David’s paper dates all the way back to 1972, and it is just as relevant today as it was then. Another classic paper by David is “Designing Software for Ease of Extension.”
Another thing from 1972 is the concept of the Software Crisis. This term relates to the problem of reining in the complexity of these solutions. Edsger Dijkstra talked about this in his 1972 ACM lecture. This Software Crisis continues today, and as an industry, we still don’t have it under control.
There are a few graphs that show up in a lot of our presentations. One of those graphs is all the way from 1979, Structured Design (Yourdon). This graph shows the relation between module cost and integration cost. This graph visually shows that you need to right-size your solutions. Too many modules and your integration costs are too high. Too few modules and your module costs are too high.
Another graph that makes it into a lot of our presentations is the “Design Stamina Hypothesis” from Martin Fowler. With this graph, he shows that spending some upfront design time might cost us a little bit of time initially but will allow us to continue developing software at a good pace over time.
When people think of software engineering, I am sure they think of Robert Martin (Uncle Bob). We are fans of Uncle Bob at Don’t Panic Labs. We do occasionally talk SOLID software. One of our favorite books is his Agile Principles, Patterns, and Practices in C#. Robert Martin has another excellent book, Clean Architecture.
Maybe the most influential external person upon our organization is Juval Lowy. He is a proponent of his architecture method “The IDesign Method,” or “The Method.” His approach is a very particular architecture with a very particular taxonomy. Once you start developing using the IDesign taxonomy, you won’t be able to build software any other way.
We’ve taken both inspiration and guidance from myriad sources. What we’ve listed here is just a sampling of what has helped us get to where we are today. I think lists are a great way to spur discussion, so let us know what books or papers have influenced you. Respond in the comments below or tag me on Twitter where I’m @chadmichel.