2017-10-15

2017-10-15 Sunday - Rabid Agile, A Gentle Criticism

One dictionary includes this definition for "Rabid": "Having or proceeding from an extreme or fanatical support of or belief in something."

This posting is intended to be a placeholder for collecting what I view as examples of fanatical Agile viewpoints held (or promoted) by others - based on my own frame of reference.


Signs You Might Be A "Rabid Agilist":


1. You Believe "The Source Code is The Design | The Documentation"

2. Every Project Team Makes All Architecture Decisions Locally - No Governance

3. You Think Every Project Can Be Forced to Fit Agile
I find the most rabid proponents of Agile (ready-fire-aim for every size project) have no appreciation for scale of when that is appropriate (perfect example of when NOT: fixed price contracts with vendors, massive development coordination between dozens of service providers, fixed deadlines - driven by market and regulatory forces) 
To an untrained eye, and based purely on that external person's observation, one might conclude that the Rabid Agilist revels in flagrant waste. 
Assuming an budget - they fail to recognize that the business has little tolerance for  rework.

4. You Promote #NoEstimates Nonsense
 



You are not being tasked with building a "warp drive" - most software development isn't breaking new theoretical ground - this isn't rocket science - many systems (of similar kinds) have been built (and rebuilt, and rebuilt) over many decades - so it is a poor excuse to whine it has never been done before. 

5. You Believe That The Only Participants That Matter are Developers and Customers

Fred George's "Programmer Anarchy" seems to hit all of the above, and then some:

Caveat: Agile is a goodness, but certain practices/applications of it are not appropriate for every type/size of project.


Finally, I offer you: Meeks Software Architecture Conjecture #1:

The source code may (or may not) be a full implementation of the desired capability needed by the business - but is more likely just an approximation (constrained by permitted time, allocated budget, and available skills/talent of the team involved). Therefore it should not be confused with the actual or desired (or envisioned) design - that may require multiple years to achieve - of which the current source code may only reflect a partial (and incomplete, or inaccurate) representation.

 

Updates:

2024-05-15 Friday

An interesting 2023 post by Michael Küsters


 

2017-10-15 Sunday - Self-Organized Criticality - and Cycles of Corrective Collapse

In my reading this weekend - I happened upon the concept of "Self-Organized Criticality" - and that led me to consider the possible implications for evolutionary constraints on the design of some complex software systems.  The idea of "ongoing cycle of corrective collapse" resonates well with my casual observations of software needing to be refactored / rewritten - to simply make it maintainable and testable.

The point here is that organizations, generally, do not plan for such rework - they wait until the "corrective collapse".

"In 1987 a Danish physicist named Per Bak released a landmark paper introducing the concept of self-organized criticality. Bak observed that complex systems draw stability through an ongoing cycle of corrective collapses that keep the overall system from becoming too over-extended."

https://en.wikipedia.org/wiki/Self-organized_criticality



I've created this posting as a reminder to come back and revisit this idea in the future - I would like to explore it further in some white papers, when I have more time to write.

Copyright

© 2001-2021 International Technology Ventures, Inc., All Rights Reserved.