In my opinion, there two (2) approaches to software development methodologies and resultant architectures.
In the beginning: Monolithic Complexity
I call the first approach: "Monolithic Complexity" which I characterize by the following:
- Grand Visions,
- Marketing defines Software Architecture,
- Significant Development Budgets,
- Attempt to Eliminate Constraints,
- Requirement to Accommodate Infinite Future Scope,
- Feature Sets based on Target Customer, Price Points, and Release Schedule,
- Divergent and Expanding Functionality,
- Related Teams Worked on Most Components,
- Minimum Utilization of External Components,
- Software Comprised of Complex and Highly-Coupled Components,
- Most Components Built to Specifically Support Application,
- Data and Configuration Stored in Highly Optimized Binary Format,
- Brute Force Development Processes,
- Constantly Extended Release Dates,
- Installation, Operation, and Extension Requires Exactness, and
- Planned Upgrade Cycle.
Microsoft is a master of Monolithic Complexity. One only need to see, use, develop for, and study the history of Windows, Visual Studio, SQL Server, and Exchange to understand just how much Microsoft fits this category. However, most modern software companies emulate this same approach regardless if they do or do not execute as well as Microsoft has.
Then came: Lots of Little Layers
Moving on, I call the second approach: "Lots of Little Layers." I characterize this software development methodology and resultant architecture by the following:
- Modest Visions,
- Developer defines Software Architecture,
- Little or No Development Budgets,
- Nothing but Constraints,
- Moderate Consideration of Future Scope,
- Feature Sets planned based on Developer’s Needs,
- Cohesive and Focused Functionality,
- Unrelated Teams Worked on Many Components,
- Maximum Utilization of External Components,
- Software Comprised of Simple and Minimally-Coupled Components,
- Most Components Useable in Other Contexts,
- Data and Configuration Stored in Poorly Optimized Text Format,
- Minimization of Development Effort,
- Frequently Released on Schedule,
- Installation, Operation, and Extension Accommodates Sloppiness, and,
- Upgrade Cycle an Artifact of Reality.
Anyone involved in software development in the past half decade will immediately recognize the latter: open-source development. Yes these include Linux, Apache, MySQL, and PHP as well as Ruby on Rails. But open source also includes software that Microsoft-centric developers probably know well including NUnit, NAnt, CruiseControl.NET, SharpDevelop, and dasBlog.
All in Life is Gray
Of course nothing in life is really black and white, and that applies here. Some open-source development follows the second approach less than others and it is inversely proportional to the extent with which the open-source project is shepherded by a corporate entity versus a passionate group of individuals.
A Uniter not a Divider
Now I’m not arguing against corporate entities in this short essay as I ran one for the previous twelve years and plan to again in the near future. Instead I am merely indicating differences and then drawing attention to the benefits of a specific aspect of the latter.
Paper covers Rock
I am writing this not to discredit commercial software companies but because I want you to see how by its very nature open-source development results in lots of little layers of software. But more importantly, I want you to understand that this approach has significant benefits. Just as scissors cut paper and rock breaks scissors, paper covers rock.
And finally, I want to encourage commercial software companies, especially Microsoft, to emulate this approach.
And in the future, as I have time, I plan to drill down to different aspects of the "Lots of Little Layers" approach to identify why the approach is so valuable complete with examples and counter examples. In the mean time I look forward to your comments and questions on this
1 - It has also been said there are two types of people in the world; those who believe there are two types of people in the world and those who don’t.
2 - Okay yes, I used a ternary metaphor to describe a binary choice. So sue me. ;-)