Why Software Methodology does not matter

Author's Note:

The title of this short paper is an awfully bold statement, which I’m sure will be disputed by many, which is great, as I believe obtaining many different perspectives makes us continuously better. This is an opinion-based article, based on both business, technical experience and good ole’ fashioned implementations of multiple methodologies. It’s an easy read, and I hope, minimally, it gets you thinking about the relevance of software methodology.

Updated 7/10/2022

The premise of this paper is predicated upon the authors opinion, that software development and system development is considered an artistic form of expression, with scientific, logical elements. In software development and system development, we are juxtaposing, science and artistic expression. While, on one hand, we apply obserability and stimuli, through logical elements applying them as function of the system, the logical aspects behind, the implementation of the system in which those scientific observations can be foreseen are indeed, artistic. Therefore, it is the assertion of this paper, that Software Methodology is nothing but a construct in which organizations have created in order to measure investment, towards profitability, with an attempt to harness or rather, channel, artistic freedom into a money making machine.

---------------------------------------------------------------------------------------------------------------

When building a software product, regardless of what it is, Software Methodology does not matter. Yes, I said it! It does not matter…at all.

In an engineering organization, building software, have you ever found yourself asking, “Why are you building software this way…?” This is a question I found myself asking repeatedly over the past 20 years. 

What I have found is that many, many organizations latch onto what they believe will be a “silver bullet” methodology for software based on the methodology “working” under certain circumstances. Those circumstances are so specific to an organization, circumstances like, culture and product type. 

I’d even go as far to say that a methodology can intersect with a certain product architectural pattern!

This begs the question, should organizations stop trying to adopt blanket software development methodologies or even modifications of these blanket software methodologies and rather focus on adoption of specific software philosophies and terminologies instead?

I have found software development practices to be much more effective when adopting software development philosophies along with specific terminology rather than a specific software methodology that the essence of an organization’s culture does not believe in. 

Software development philosophy is NOT Software development methodology. These are mutually exclusive and in fact, there should be no intersection between the two.   

As an example, take the Agile Manifesto, those are a series of beliefs that an organization must cultivate, however, this begins with getting the right people, to first believe in the general philosophy of “Individuals and Interactions over processes and tools”.  

Which I fundamentally believe in, however, isn’t following a scrum methodology, and having an enforced 15 minute daily stand-up meeting 100% contrary to that philosophy? Or even peer programming and enforcing two engineers to work together continuously? 

I think it is, in-fact, I believe that communication between engineers is absolutely critical in order to build a product, however, building a process around those interactions goes against the philosophic nature of what was intended by “Individuals and interactions over process and tools”.

I’m not specifically picking on any type of Agile development, it’s just a simple example to outline the philosophical and cultural aspects of an organization along with standard methodologies can contradict each other. Which is a struggle that I have observed across many organizations, interacting with many hundreds of engineers.  

Therefore, I believe that philosophies along with specific terminology realized through processes, which are unique to how an organization operates serves as the most effective mechanism of a successful software development within an organization.  

Defining a consistent set of philosophies in which your engineers believe in, is the first step. As an example, take the philosophy that “software development is continuous”, which I like to refer to as, “Continuous X”. Adoption of this as a generalized philosophy, means the organization facilitates a culture in which engineering teams adopts continuous improvement, continuous integration, continuous deployment, and continuous testing. The processes which facilitate the above should be implemented and supported by the organization.

Now, along with this philosophy, terminology is much more effective than methodology. Get your engineers speaking the same language as they communicate towards each other and towards the business. In larger businesses, terminology over methodology becomes critically important, as the more product groups you may have in an organization, the more critical terminology the alignment needs to be. 

As a simple example, imagine you have a cloud-based product and a hardware-based product in which your organization is responsible for producing. The term, “Deployment” means two different things to those products. The cloud-based product might deploy multiple times a day to their customers, whereas the hardware-based product might deploy once every 6 months.  

Now, you might be saying, “But terminology is DEFINED by methodology!!”, and you are right! It is! The catch is that, along with the terminology as outlined by the methodology, the terminology is dictated through the realization of the methodology. 

This *may* work for some engineering groups, however, in many cases, you’ll find your engineering teams asking themselves, “Why are we building software this way….?”

Software Development Philosophy and Terminology are much more powerful, efficient, and effective way to develop software than blanket methodology.

Feel free to leave me your thoughts!