Featured Post

Thursday, July 2, 2020

The Theory of Software Stability

Copyright © Thought Rising 2020 All rights reserved.

Abstract



Software Stability is a software engineering theory advanced by Dr. Mohamed Fayad in 2001; however, the term "stability" in the realm of software has only recently been used by a few technology companies such as Amazon.com, While not with the same methods as Dr. Fayad has documented.  Nonetheless, The notion of Stability has entered the language of corporate America through a philosophy that urges all corporations to be good corporate citizens.  When confronted with the economic benefits both in cost savings and public perception of a commitment to stability and sustainability with respect to concerns including environmental footprint/carbon footprint, the notion arises that the concept of stability might also find a foothold in software economics.  Thus we conclude that Software Stability Theory now must be examined carefully within the the academic literature pertaining to Software Engineering.  Similarly, Dr. Fayad's notion of Software Stability deserves a proper treatment and must be taught and shared with other Software Engineers for the betterment of all software engineers.

Software Stability in a Nutshell

  1. Simplicity and Elegance of Software Architecture, Design and Coding

Software Stability theory targets a renaissance in software engineering and a return to the guiding principles of simplicity and elegance in Architecture, design and coding.  Thus, we start with the mandate that simplicity and elegance of software is a desirable characteristic, which yields superior outcomes.

In a nutshell, Software stability is both a scientific theory for rapid software engineering and it is the only software engineering practice that fully embodies the desired objectives of Agile.  It achieves this objective by emphasizing simplicity and elegance of architecture, design and coding.

The core Principle of this theory of  Software Stability is that Patterns are at the core of any software that is built.  It can also be said that anti-patterns are at the core of any software that is built.    This does not mean that software is necessarily bad if it employs one or more anti-patterns.  What it does mean is that all software can be improved and should be improved as much as possible.  To wit, this is central to the agile concept of iterative development; however Software Stability takes the notion of software improvement to another level.  The objective of a software product must be that it is architected, designed and developed with the understanding that software must be maintained and improved iteratively.

As patterns are at the core of software improvement and software innovation, Software Stability targets solutions that employ stable and reusable patterns throughout the software engineering lifecycle.  By employing optimal patterns (Software Stability Patterns) within a software architecture, design and development efforts, you can greatly improve the economics of any software product.

This point is key: Every software engineer has had the experience of discovering a powerful and new approach to modeling a specific software solution and observed the following benefits:

1) Simplified and streamlined software maintenance
2) refinement of the support model for a software product.

Software stability mandates that we employ this approach holistically thereby creating simplicity and elegance of architecture, design and coding throughout all facets of software engineering.

2. Complexity is not a Friend

Software stability stands in firm opposition to the notion that a software solution must necessarily be complex and that complexity itself is inevitable.  In fact  it is central to software stability that complexity is an anti-pattern and that you must simplify relentlessly in order to build innovative software that yields high quality and remains cost effective over time.

3. Agile is not a Silver Bullet

Agile has received a great deal of hype among all technology companies.  Yet, the fact remains that Agile has failed in software engineering organizations with the same frequency that these teams have failed in non-Agile regimes.  An exhaustive analysis of project success within Agile and Non-Agile software engineering teams would reveal few insights about what exactly has gone wrong, but it  would likely fail to raise the most important point:  Namely, that Agile Methods, such as Scrum, Kanban, Lean, and XP are not software engineering methodologies.  Rather, these are Project Management Methods.  None of these approaches prescribes how software should be engineered.  This is where Software Stability is an important software engineering approach for achieving  true and reliable Agile results.  In fact, Software Stability is the only software engineering approach that embodies the same principles detailed in the Agile Manifesto.






Wednesday, July 1, 2020

Confused about Racism?

Copyright © Thought Rising 2020 All rights reserved.

I am confused by all of the rhetoric about Racism in the news and  in discussions with friends and family.  First off there is this term "White Privilege" that confuses me greatly.  Somehow because I'm  white,  I am a beneficiary of White Privilege.  Because I have White Privilege, it is concluded that I'm an institutional racist.  This simply doesn't calculate.  When White Privilege is explained to me, I do not  recognize any of the privileges that I am an alleged beneficiary of.

I raised an African-American child.  Does that mean that he has White Privilege, since White Privilege is something that is passed down from parents to their children?  What about Colin Kaepernick?  Is he White Privileged since at least one of Colin's parents if not both are white?
What about Nate McMillan, a multi-millionaire coach of the NBAs Indiana Pacers?  Is he privileged because he has spent his entire adult life within the shield of the National Basketball association either as a player or as a coach?  He decries racism in our country, but I'm confounded about how exactly it impacts him. Moreover, I've listened to and read dozens of heated comments about racism from privileged public figures who happen to be African Americans.  I understand that they feel compelled to condemn racism and I don't have a concern about their sincerity, but I'd like to know exactly how a Black man or woman who has made millions or even tens of millions or hundreds of millions over their lifetime has been harmed by racism?  When you call the shots in your life everyday and never have to wonder about where your next meal is going to come from; when you've not had to worry about having a roof over your head for decades, and when you've lived a thoroughly privileged life does the color of your skin give you some privilege to voice outrage over a White-Privileged society that has beaten you down?  I find it completely incongruent with reality., That's not to say that Black Americans of the top tier social class should not comment on racial injustice, I just would rather see the rhetoric dropped down a notch or two and the underlying issues addressed.  Systemic racism is not something that can simply be fixed; however the underpinnings of systemic racism and social justice concerns can be addressed individually.  Black lives do matter to me and, in fact, all lives matter to me; however, through my decades of political and social activism, I have learned that rhetoric tends to cloud the underlying issues that can be addressed concretely, and diverts attention from the good work that can be done to improve our society.

I protested against Apartied as a University Campus organizer in the mid-1980s.  Does this absolve me of any of this White Privilege that I am accused of?  Does it make me any less a racist that I have put my body and soul on the line for Racial Equality?

I am jewish by birth.  I was raised in a family that was not well-to-do.  We lived far beyond our means and mom and dad were perpetually bankrupt.  I had to work hard for everything that I've accomplished in my life.  Nothing was handed to me.  Does this reduce my White Privilege?

For 20 years, I have been counselling Parents of divorce or paternity-related actions involving the family Courts.  I have been emphasizing the importance of Fathers having close bonds with their children.  I have counselled Fathers, and some Mothers of every race, creed color,religion and gender including a number of LGBTQO+ parents.  Does any of this this atone for my despicable white privilege?

I have a 30+ year record of political action supporting racial  and gender equality, yet I am institutionally racist.  This is what confuses me.


Wednesday, June 24, 2020

On Capitalism vs. Socialism

Copyright © Thought Rising 2020 All rights reserved.

It seems of late that there is a rather large mobilization of socialists throughout the country.  This outcry of socialism harkens back to the Occupy Wall Street events of a few years back and rides on the heels of Bernie Sander's push to turn America into a socialist country.

However, all of this belies the fact that people in the socialist regimes of our globe are far less free and far less well off than people are in the United States.  In fact, nearly every socialist country has a miserable record with respect to human rights violations. To wit, socialism has failed miserably in most every country in which it has been tried -- notable socialist countries include:

1) the USSR, which broke up some 30 years ago -- a nation rather infamous for it's Gulags and prisons.
2) China which is notoriously famous for repressing it's own people and killing it's own people should they protest in Tianamen Square or Downtown Hong Kong
3) Czecheslovakia, which is reknowned for oppressing it's own people until the country experienced a Civil War.
4) Romania, A country which repressed even it's national heroes.
5) Cuba, which has been a disaster for most Cubans.
6) Venezuela which went from being one of the most prosperous countries in Latin America to arguably the poorest and most repressive in just a matter of 15 or 20 years.

Why is it that socialism always results in poor outcomes?

I have a theory.  The problem is that the rules of socialism are complicated.  Who makes the rules? How do you compel people to be equal without repression of voice?  In fact is there real equality in any Socialist society?  Scarcely!  There are still ruling class and proletariat class in every Socialist country in the world.  So, what is it that attracts people in this country to Socialism.  I'm baffled.

There's no such thing as a free lunch!  No country and no government is going to pay you to stay at home and sit on your duff for any period of time.  Capitalism offers "We the People" in the United States of America the central concepts  that we have valued for nearly 250 years, and it's working.

Furthermore, the rules of capitalism are much more predictable:  If I have $10, I can purchase $10 of goods or services, but no more.  Of course credit cards add some nuances to the supply and demand concepts, but ultimately, the market prices itself based on consumer tolerances and supply and demand.  Most people understand how this works even if they have not studied economic theory.  Whereas even a year-long course of study in Marxism and Socialism won't help you to understand the rules of Socialism any better than you do at this very moment!

Clearly Capitalism is not perfect and we need a strong government to keep things moving along, but ultimately, Capitalism makes sense and people demonstrably experience great liberties in the USA in part because we have a Democratic Republic rather than a Socialist State, and in part because of the Declaration of Independence.

I am deeply concerned about the Socialist agenda in the Democratic party.  In Socialism, only the ruling class has any freedoms.  So, why wouldn't the Democratic politicians want Socialism.  They can rule indefinitely and control the country at their leisure so long as the Socialist Regime Reigns.
In a nutshell, this is the end goal of the Socialists within the Democratic party, and I cannot stomach any of it.


Saturday, June 20, 2020

Software Accidents Will Happen


Copyright © Thought Rising 2020 All rights reserved.
"Agile is the process used by disciplined professionals observed in the wild."
- Robert "Uncle Bob" Martin


In December of 1992, I traveled to Snowbird ski resort.  While there, I scribbled 4 statements on a chalkboard in the conference room at the resort.  Apparently no one erased that chalkboard between December 1992 and February 2001.

The Agile Alliance met at Snowbird Ski Resort  in February 2001 and published the Agile Manifesto.  According to Robert Martin, they never met again and don't have any desire to do so.  Is it because they anticipate that they will never find writing on that chalkboard  again?

in 2016, Robert Martin, in his talk on the future of programming, he asserts: "Civilization depends on us!" He notes that many dozens of people have been killed by software (due to software in automobiles malfunctioning and the vehicles consequently running into things).  He goes on to assert, "it's just a matter of time before a software cataclysm occurs when perhaps tens of thousands of people are killed by software written poorly."  He describes the scenario of  an airplane crashing into a football stadium.  But we need to consider whether Dr. Martin's "software cataclysm" will be with a bang or a whimper!  Perhaps Dr. Martin's prediction will not be something with so much man and machine carnage as a plane crash.

In the early years of my career, I was responsible for writing programs to manage and control a ballistic testing laboratory at TRW Safety Systems in Mesa, AZ.  The program managed various interlocks, in which the ballistic test (read: explosion) could not be completed until the testbay door was locked from the outside and every member of the test team that had entered the testbay had authorized the test to proceed -- thus indicating that there was no human being in the ballistic testbay.

Thus, I learned a profound lesson about the importance of Software testing and the reality that software could be harmful to humans.

Copyright © Thought Rising 2020 All rights reserved.

Monday, March 23, 2020

The Battle of the Sexes

The Battle of the Sexes


I was eleven years old in 1973 when the whole nation watched "The Battle of the Sexes" play out on television. Never mind that a movie was made of the subject in 2017.  The original competition between Bobby Riggs and Billie Jean King was touted as the battle to end all battles. But the hype was far more interesting than the tennis match.

And years later, we are left with all of the hype and very little substance.  The battle of the sexes has played out on many levels in US culture and society.Women's liberation continues to fight for equal rights and against the male-dominated establishment, when, in fact, the male-dominated establishment retired decades ago.  Unfortunately, the gender wars have raged on. We have women in the C Suite, Women in Congress and in the Senate. Still, the equal rights amendment hasn't been passed, and some women are sincerely P-O'ed and feel victimized by a society that seemingly fails to recognize Women as equals.

I disagree.  I think that women have had a far better outcome due to the unsettled nature of the battle of the sexes.  Moreover, I believe that feminists would rather not talk about the changing roles of men and women in society.  Women have enjoyed a thoroughly free ride in the past five decades.

While American Society has evolved to the point where it is nearly impossible for a family to survive on a single income, many women still hold on to the fantasy that they can aspire to be housewives, sitting at home eating cherry Bon-Bons a la Kate Bundy, while their husbands toil away frantically trying to make ends meet, pay the bills and save some money so that the family can enjoy just one annual vacation each year -- or perhaps every other year, and so that the children might go to college one day and become self-sufficient. No thought or dollar is invested in the thought that the bread-winner himself might actually retire from work at least a few years before he's 6 feet under!

What does this all mean?  I have uncovered a blockbuster finding:  Despite all of the pomp and circumstance surrounding the infamous "Battle of the Sexes".  Nothing at all was settled.  The fact of the matter is that our nation has never had a candid dialogue pertaining to gender roles in the age that followed the battle of the sexes.  Absent that we have fumbled along quite clumsily attempting to achieve some semblance of balance in an otherwise unbalanced world.

The end result is that we have a tenuous battle for a woman's right to choose versus a fetus' right to survive.

We also have an ongoing war of words between feminists who have utterly failed to engage in a long overdue dialogue as to what gender roles look like after the equal rights amendment and after the famed battle of the sexes is finally settled.  Surprisingly, the alleged male-dominated establishment does not especially embrace the concept of Women's liberation as defined by the National Organization for Women or embraced by more militant feminist factions.  But it all comes down to the failure of the Women's Rights movement to engage in a constructive dialogue about how society functions after the battle of the sexes -- as if it were the duty of men to sit them down and ask if they might condescend to even entertain such a dialogue.

I don't pretend to know what the solution is exactly, but it won't get solved until the dialogue is happening in earnest.

Saturday, March 14, 2020

Agile pitfalls to avoid ... At all Cost

Agile Pitfalls to Avoid 
...At all Cost

Copyright © Thought Rising 2020 All rights reserved.
Working in Agile Teams over the course of more than 15 years.  We have observed some distinct benefits; however, there are some formidable pitfalls and bad habits that can doom agile teams.  This paper, classifies these pitfalls and bad habits that must be avoided at all cost to ensure a successful Agile experience for the engineering team and for the product owners and end customers

In our experience, we have observed one or more specific pitfalls or fallacies corresponding to each of the 4 principles (or Values) delineated in the Agile Manifesto as detailed in the following table:

Principle/Value
Pitfall/Anti-Principle
  • Individuals and Interactions over Processes and Tools
  • Agile is a Gateway Drug
  • The Rat's Maze / The Swarm Instinct.
  • Working Software over Comprehensive Documentation
  1. NBUA - No Big Upfront Anything
  2. Non-Agile Software Architectures
  • Customer Collaboration over Contract Negotiation
  1. Agile Obesity
  • The Fallacy of "Yes" - Over-committing leading to Under-delivery
  • High Software Defects and Brittleness
  • Excessive Rework Cycles.
  • Responding to Change over Following a Plan
  • Inadequate Testing

1) Agile is a Gateway Drug

The first agile  principle values Individuals and Interactions over Processes and Tools; however, the need to automate routine processes often leads to massive tool propagation. In this respect, Agile itself is a Gateway Drug, such that ever more tools are needed to orchestrate the agile experience.  For example, we see the following tools employed within agile teams the world over:

1) JIRA for issue tracking
2) Confluence for Just-in-time documentation
3) Junit for Java Unit Testing.
4) DB Unit for database unit testing.
5) Mockito for injection of Mock objects into JUnit Tests.
4) Selenium for Application Test Automation and regression testing.
3) GITHUB for source code management
4) Artefactory for code library management
5) Jenkins for build management
6) UDeploy for deployment automation
7) Splunk for Application Logging and log analysis.

And on and on the list grows.  It is important to note that we have not listed all of the various tools that are needed within the production support team for the overall support and trouble-shooting of applications. It might be argued that many of the tools listed above were always needed, but this is a fallacy in itself.  One might ask, "how did we build software before these tools were available?" Simply, we found ways of solving the technical needs for building software by building one-off tools and thus we were building tools from scratch over and over again.  Perhaps these tools can save us time? Yet there is a cost to all of this tooling, and in the end analysis we were supposed to value individuals and interactions over processes and tools.  Where did Agile lose it's way? It seems that Agile was always destined to become a gateway drug for so many processes and tools.  We conclude that it's a fair question to ask the founders of the Agile Alliance, "Where did we go wrong?"

2) The Rats Maze / The Swarm Instinct

The value of Individuals and Interactions over processes and tools can be undermined when the Individuals and Interactions are not governed by some structure.  Since Agile is also predicated on self-organizing teams.  There is a tendency for disarray to reign within agile teams.  Everyone is on an individual mission to find a piece of cheese within a virtual rats maze.  Thus Agile Team members may find themselves wasting cycles searching the virtual rats maze for answers to technical questions whereas someone else has already found the virtual cheese.

Another analogy is the "Swarm Instinct".  In competitive soccer, we learn that inexperienced players tend to swarm wherever the ball may be on the field of play.  Whereas experienced players, teams and coaches will exploit the swarm  instinct by playing positional play which will allow a more experienced team to exploit the inexperience of the swarming opponent.  Grady Booch famously asserted that Software Engineering is a team sport; however, there is clearly a distinction between haphazard, self-organizing teams and a team that employs a fundamentally rich game-plan, where each team member has a defined role and position on the virtual field of play.  While there is no direct opposing team  per se  within  the Agile project environment, the takeaway is that a team working to a rich gameplan will achieve far greater success and far more reliable and repeatable results versus a team that is entirely self-organizing.

3) NBUA - No Big Up-front Anything

The NBUA pitfall was first detailed by Bertrand Meyer.  Meyer's assertion is that agile projects are destined to fail when agile teams reject all forms of up-frront documentation, in consideration of the assumption that all of the documentation relating to the software will ultimately become outdated.  This is not a legitimate rationale for decrying all up-front documentation.  An important consideration is to invest the appropriate level of effort upfront in any software engineering effort to design a solution that is built for test-ability and that embodies an Agile Software Architecture.  These points are treated in more detail in the following section. But it is sufficient that the fallacy of NBUA can be the root cause of many Agile failures.

4) Non-Agile Software Architecture

Agile software development works best when there is a high degree of repeat-ability.  Software architectures that are cumbersome do not lend themselves to agile software development.  There are two flavors of the Non-Agile Software Architecture Pitfall:

a)  The Square-Peg/Round-Hole Fallacy
b)  Design without Test-ability Fallacy

The Square-Peg/Round-Hole Fallacy occurs when an existing software that was created in a non-agile ecosystem is force-fitted into an agile world.  A similar fallacy occurs when the software architecture fails to take into consideration software life-cycle concerns, and fails to employ patterns that tend to produce a durable, resilient and flexible solution.  This fallacy can quickly doom any team to fail, and experience shows that the end result is an unruly mess.

A similar concern pertaining to software architecture relates to the all important mandate to design for test-ability.  When software is not designed for test-ability from the start, it is most challenging to achieve the level of test-ability needed to ensure product quality.  In addition, it is difficult to create the comprehensive unit test suite that is necessary to support the iterative development cycles that are typical of Agile development.  Without these comprehensive unit tests, the software quickly becomes brittle, defects begin to appear with regularity, and software releases become increasingly unreliable.  This fallacy can be realized in any software that is not designed from the ground up to support agile methods.

5) Agile obesity

Agile teams may loose sight of the principles laid out in the Agile Manifesto.  Agile obesity results from various lapses in judgment.

a) The Fallacy of "Yes" - Over-committing leading to Under-delivery
b) High Software Defects and Brittleness
c) Excessive Rework Cycles.

The  Fallacy of "Yes" is an over-committing problem that invariably leads to under-delivery and in the worst case scenario leads to unacceptable software quality. 

For example, the product owner in a scrum team may have incentives to include ever more features in a release beyond the capacity of the team to engineer, and test all of the promised features.  This is a clear case of an agile fat-cat who has lost touch with reality and has adopted the fallacy that you can get something for nothing with agile.  What's one more wafer-thin feature? 

In the real world, there is a balance of features that do not introduce unnecessary risk to a software product release. In the same vein, you may have a scrum master who doesn't know how to decline a request from the product owner.  It is vital for an agile team to grapple with the risk of adding additional features to a sprint or a release with at least equal weight to the reward of delivering said new features.  The Scrum Master must be able to have a dialogue with the Product Owner relative to any such requests and determine the tangible risks and trade-offs that apply.  This must be done objectively -- emphasizing pragmatism, resource capacity and bandwidth at all times.

6) Inadequate Regression Testing

Regression testing is a mandatory activity in agile development.  Every change -- regardless of how minute -- requires comprehensive regression testing.  Without the necessary and essential test cycles, software is sure to break and exhibit defects and unreliable behavior.  This fallacy is closely related to the Non-Agile Software Architecture Pitfall; however, this fallacy may occur even when the software is designed for testability.  This may occur in the following conditions:

1.     The QA or test team fails to invest adequately in understanding the software and it's failure modes.
2.     The engineering team fails to provide adequate hand-off of the software and its features and functionality to the test team.

Here, we are not simply talking about unit test suites.  Rather, we mean full cycle regression testing.  It is difficult to anticipate the myriad unintended consequences of a small change made to even a modestly complex piece of software.  A change to one component may result in cascading behaviors that bleed over into the function of other components.  Thorough unit testing that includes testing failure modes and edge conditions will ensure that a given module does not malfunction even when presented with edge-condition values that are otherwise unexpected and even unanticipated.  As the integration of highly modular components of software becomes the norm, the cascading effects of a failure in one module may have amplifying effects on other components of the software.  These amplifying effects seldom occur in normal operational scenarios, but software engineers in agile teams, including DevOps engineers need to plan for catastrophic cascading failures that can bring a software product to it's knees.

Conclusion

Assessing many companies that have undertaken a transition to Agile methods, it is clear that Agile is massively  to be a software engineering method, when in fact Agile is not a software engineering method at all.  Agile is a management methodology with application to software engineering and other disciplines.  Most important, because Agile is not well understood by management and also has been heavily promoted as a solution that introduces efficiencies within software engineering teams, non-technical managers see it as a master key that will magically transform a software engineering organization, with little or no cost.  This perception is a tremendous disservice to Agile methods and also to software engineering as well.  Software engineering is a highly disciplined endeavor involving the management of voluminous information and technical details.  

While some managers may perceive the exacting discipline  of software engineering as overkill, it is certainly not the case that the high level of discipiline of a software engineer is excessive by any means.  If the software that is being built is a trivial web page, then perhaps less discipline may be required, but if the software is for a complex satellite network used to defend one's country from attacks from a hostile nation, then clearly the software must work reliably at least 99.99% of the time and preferrably 100%.  If the software is for a self-driving automobile, then we must demand 100% reliability as the vehicle is transporting our most precious cargo - namely ourselves, our spouses, our children and our dear friends.

In fact the most powerful aspect of Agile methods is the concept of iterative development and iterative testing.  The software must pass unit tests under a variety of common operating scenarios as well as under uncommon conditions and edge or boundary conditions.  Software must also operate predictably, and recover gracefully, from failures when invalid and even corrupt inputs or data are passed to the software.

In short, Agile works best when employed with engineers employing repeatable processes.  It can require painstaking effort to create these repeatable processes, and most companies are not patient to allow these repeatable processes to be developed by highly compensated engineers.  Such perceptions doom Agile transformations to fail.  Since the Agile Alliance was formed to formulate solutions to the challenges experienced by software engineering teams and to emphasize the value of working software, it is a fallacy to think that the discipline that fundamentally underscores Agile methods may be tossed aside as useless.

But this does not imply that we simply replace one unsatisfactory management paradigm with another unsatisfactory software engineering management paradigm.  Rather we conclude that repeatable processes are the engine for increased velocity within software engineering teams.  By developing software with discipline and building out repeatable processes, software engineers can deliver high quality working software at velocity.  We've been doing it for years and we continue to do so.  The key to delivering high quality working software at velocity is to employ tremendous discipline and create the repeatable processes that are crucial to engineering high quality working software.  Furthermore, we've uncovered some important lessons for exactly how this should be done and we refer to this concept as the Simplicity Pattern.  The simplicity pattern builds on decades of research and refining the concept of Software Stability Method (SSM)  Software Stability Method is an approach that employs stable and reusable architectural and design patterns throughout the software engineering process.  The Simplicity Pattern is summarized as follows:

Complexity is an anti-pattern

Software engineers and managers within software organizations tend to become complacent with regard to software complexity.  This complacency is dangerous.  The more complex that a software product becomes, the more likely it is to fail.  Furthermore software failures are tremendously costly to fix after delivery. Thus we must simplify relentlessly within all aspects of software engineering encompassing: 

1) Software Architecture
2) Software Design
3) Software Development
4) Software Test
5) Software Deployment and Installation.

Thus the Simplicity Pattern dictates that software must adhere to the following simplicity principles by embodying the following concepts:

1) Architectural Simplicity Pattern 

Software Architecture must be as simple as possible while still satisfying the system requirements.

2) Design Simplicity Pattern

The Design Simplicity Pattern is best understood by two popular concepts touted within strong Agile Teams:

a) Single Responsibility Principle (SRP)  - a software module should have a single responsibility.  Software designs that adhere to SRP tend to remain simple and mitigate complexity
b) Test Driven Design (TDD)  - Software must be designed to be testable, and this is most readily achieved when employing TDD in which the tests that the software must satisfy are the key artifacts of the software design

3) Build Simplicity Pattern

In short Build Simplicity means that the process of building the software need not be a complex software engineering activity unto itself.  By simplifying the build process it makes it easier to continuously build the software and this in turn is the foundation of the continuous integration that is a cornerstone of Agile methods.  Moreover, software must be designed such that the software build is not prohibitively time consuming.  If builds take a long time, then engineers will be reluctant to build the software and defects inherent in the build process may not be identified until very late.

4) Test Simplicity Pattern

Software must be architected, designed, and developed to be fundamentally testable. When software is inherently testable, it is easy to test and testing itself is more easily realized as a repeatable and iterative process.

5) Deployment and installation Simplicity Pattern

Ultimately software is of no value unless it works reliably for its intended purpose and is installed for the end user or customer's use.  Whether the software is installed on a microprocessor within the engine compartment of a car, or within the CPU of an ATM machine. or on a satellite, the software must be easily and quickly deploy-able and install-able to the target operating system.  Software that is prohibitively complex, and difficult to deploy or install is prone to experience defects within the installation process.

In short, to succeed with Agile, or any other project management methodology, we recommend that teams adhere to the Simplicity Pattern.

Copyright © Thought Rising 2020 All rights reserved.

Wednesday, August 29, 2018

Succeeding with Agile.

Abstract

Agile has been all the rage for a decade.  Some organizations have been more successful than others in adopting agile methods.  Agile has been marketed very heavily both by software developers and by the members of the agile alliance; therefore, it is important  to separate the wheat from the chaff. To be certain, agile is not a silver bullet.  Merely, adopting agile ceremonies will not ensure that an organization will reap benefits from adoption of agile practices  Simply stated: an organization cannot expect a stellar transformation in software engineering outcomes by proclaiming "We are an agile shop."  Nor will the goal be achieved by overlaying scrum ceremony on top of a broken software engineering approach.

To place agile in the proper context, we raise four germane questions:

1)Why should an organization adopt agile?
2) How can agile benefit an organization?
3) What decisions can aid in successful agile adoption and ensure that an organization reaps the  intended benefits of agile?
4) What software products are good candidates for agile?


Why Agile? How can Agile benefit an organization?

These are the two most important questions when contemplating agile, and they are clearly reciprocal to one another.  An organization should adopt agile if it is very firmly committed and resolved to long-term improvement in software engineering cost controls and overall improvement of software quality  This is precisely how agile can benefit an organization; however, Agile does not come with this guarantee.  Agile must be adopted with pragmatic expectations and a willingness not only to disrupt traditional conventions and practices, but to embrace the foundational changes that are necessary for a successful agile practice.


What decisions can aid in successful agile adoption and ensure that an organization reaps the  intended benefits of agile?
There are many changes that are necessary and proscribed for any organization adopting agile.  There are no shortcuts here, all of the proscribed tooling and practices are essential to getting agile right. All of these proscribed elements are necessary and, in fact, crucial to employing agile successfully, and thereby achieving the outcomes that underpins the question "Why Agile?"  These prerequisites for agile success are as follows:
  1. An organization must possess the willingness to part with brittle or failed software architectures that do not adapt well to Agile practice.  In short Agile will not work with any old software and there is no way to evolve a brittle or unwieldy architecture through iterative development to arrive at a viable agile architecture.  Consider the following realities:
    • One of the most fundamental paradigm shifts that is vital for Agile software development is test-ability and test-driven development.  Software that is not designed for test-ability is not well-suited for agile teams. 
      • Experience shows us that organizations who try to superimpose agile on software that is not designed to be testable are prone to fail at agile adoption.  
    • Similarly, certain software architectures fundamentally lend themselves to agile development where as others do not.  
      • An organization must be pragmatic about whether it's underlying software architecture is sufficiently agile and understand that an unwieldy architecture will invariably lead to a failure to succeed with agile.  A governing maxim: software that is failing without agile practices will almost certainly yield the same results in an agile regime.
    • Agile doesn't just happen because it's proclaimed.  It takes a great amount of discipline at all levels within an organization to successfully employ agile practices.  Furthermore, there are fixed costs for successfully managing agile development which cannot be overlooked.  The organization needs to have a reliable and efficient platform and tooling to manage it's agile deliverables.  This goes far beyond SCM. products such as JIRA,HP ALM and similar ticket management technologies are prerequisites for a successful agile implementation, simply because there must be transparency and line-of-site visibility of every in-progress activity solution at any point in time for agile to work.  Tooling alone does not achieve the discipline.  There is a need to devote time and resources to triage status, activities and iterations on a burn-down list.
    • Agile is essentially a gateway drug for Continuous Integration.
      • In fact you cannot realistically implement agile development methods without having a comprehensive set of tooling for build and release automation that are needed to adhere to the agile cadence.
      • SCM is a given, Build Automation with a tool such as Jenkins is also essential and automated deployments are needed.  These in turn are commonly gateway drugs for tools such as Artefactory and a variety of other software products that are commonly found within agile teams.
    • Agile is also a gateway drug for DevOps and most agile teams cannot succeed without a strong DevOps team supporting the work. 
      • DevOps greases the skids for Agile development teams and effectively clears the path for innovation by the Development Team by validating key platform decisions and verifying that the technologies that are proposed in a given Epic will function reliably within the release environment.  DevOops also serves as the gate-keepers of the environments so that each environment within the release cycle can be certified for use before developers introduce newly released sofware in the environment that may be faulty and may have side-effects that destabilize the entire release environment.
In short, it is important for decision-makers to avoid getting sold on the hype of agile.  It is also important to firmly grapple with the realities of agile and the importance of agile planning and deliberate and measured implementation of agile.  Most of all it is imperative that decision-makers not allow themselves to make the mistake of trying to superimpose agile on a brittle and failed software architecture, nor can it be expected to transform legacy code in even a few short years, much less the few short months that management would like to see results.