In the the time that I’ve spent developing software so far in my life, I’ve seen a tendency for folks to create a false dichotomy – a dualism – between accomplishing goals (“pragmatism”) and desiring to accomplish them in the theoretical ‘best way’ (“idealism”). Alas, logic abhors a dualism and it’s my experience that as soon as you begin creating such a dichotomy, you’ve fallen into a trap. In fact, I’m about to tell you that who you are (the way you do things and your motivation) is inextricably connected to the things you produce (goals you achieve).

Let’s look at this first through the lens of organizations and the products they produce. I’ve often seen that when a cultural problem exists in a company (selling things before they exist, not allowing employees to balance their work and life appropriately, favoring results above all else, etc) there is a desire to deliver and fix the cultural problems later. What many do not realize though is that the products produced by a culture are born in that context and bear the mark of their origin. In the same way that Conway taught us that the shape of an organization impacts the architecture of a system, we can learn that an organization’s motives shape its methods, and those methods produce a product that resembles its maker.

Step back for a moment and consider this at the personal level. We often are driven to set goals for ourselves with the hope that once we accomplish said goal, we will have proof that we have become the person that we want to be (a marathon runner, someone with impecible hygiene, etc). James Clear, in his recent book Atomic Habits, goes to great lengths to show that it is the journey towards a goal that shapes us, not the completion of a goal. One golden quote from the book is:

Every action you take is a vote for the type of person you wish to become.

The way you do things shapes who are you, and your identity – your heart – is what drives your actions.

Now consider this from the software development point of view. Those who buy into the false dichotomy between ideals and results will say things like “we don’t need TDD, we need to ship software” or more perversely “Let’s wait to start using TDD until we get this first release out.” (You can exchange “TDD” in those phrases for other methods such as Continuous Delivery or Evolutionary Database Design) Those who understand that picking only ideals or results is a false choice will realize that “we can only deliver our first release and respond to change if our software can be safely modified”. In fact, favoring results over ideals is itself an ideal. There is no escaping the fact that your value system breeds a culture which births your products. Methods will always come out of ideals or vision, it’s just a matter of what ideal you choose to embrace.

Once an individual developer, team, or organization understands this, there is a freedom that will arise. They will realize that they can take time to think about how they do things, in fact, they must think about the how. There are times when it is profitable to slow down and reason about something out of your organization vision rather than a desire to achieve a goal by a certain date.

Don’t agree? Let me know in the comments.