My name is Dan Coleman. I have been writing software since I was 12 years old, and professionally since 2011. I quickly became fascinated with the problems of code design, especially in object-oriented code. After reading the book Design Patterns by the Gang of Four, I began focusing my work on redesigning application code to be easily adaptable, maintainable and resilient. Every feature assignment I received became an opportunity to restructure older or more brittle areas of the code base, and building a rich set of reusable libraries that made feature development quicker and easier. This was before I learned the industry standard term for this practice of refactoring. I became a leading voice in my team for emphasis on design in all stages of software development. When my organization adopted agile practices and expressed a desire for a rapidly changeable application, with small iterations of features and updates released at least as frequently as two weeks, I saw it as a design challenge. How do we engineer a software system that can be quickly modified and redeployed? What design practices must we follow to make this possible?

I have also, for many years, been an avid fan of philosophy and economics. As I became more involved in the industry challenges, I saw many opportunities to bring the lessons of these disciplines to bear. This blog is a place to discuss the problem of designing a highly agile software system in a philosophical and analytical fashion. The topics can range anywhere from detailed discussion of specific code design problems, to issues of how to run a software shop, the interactions between the engineers and product owners of an organization, how software engineering relates to engineering in general, how the lessons of the past can teach us how to build better software, and the underlying philosophical principles of software design.

I consider myself part of the Software Craftsmen movement: a movement that emphasizes that software engineers are expert specialists, who are most effective when they exhibit a passionate interest in the highly technical elements of their profession. This is in direct contradiction to the idea that software architects and software developers can be meaningfully separated, either as roles or especially as organizations. All software developers are architects. Design is what we do, it is all we do, and we are most productive when we embrace this role, and are given the appropriate space by our organizations to fulfill it. For this reason, we ought to create spaces for ourselves to discuss and develop our craft. Software engineers should make learning and intellectual growth a central component of their careers.

This is a place for us to learn and grow as craftsmen.