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.

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.

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.

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	NBUA - No Big Upfront Anything Non-Agile Software Architectures
Customer Collaboration over Contract Negotiation	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.

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.

What's Next in Software Engineering?

In recent years, I have become disenchanted with the java community and also most software engineering practiced in businesses throughout the country.  The most commonly practiced approaches in software engineering have produced little more than prohibitively expensive approaches to developing software and approaches that far too often result in unpredictable and unexpected outcomes, including systems integration mismatches, software that is not readily adaptable to the constantly changing information security landscape and software that simply doesn’t work as desired.  These problems are compounded such that increasingly, software is delivered that simply doesn’t work and fails to meet the solution requirements as defined in any manner that resembles the reason that the software project was undertaken in the first place.  Furthermore modern software solutions are delivered with utterly convoluted user interfaces and such utter lack of documentation that no one really can tell you how the software is designed to function.  The end result is a prohibitively costly model of doing business.  This paper looks at a variety of the causes contributing to this new software engineering crisis and poses the question: “What is next in Software Engineering?”

Frankly speaking, the Java ecosystem has become needlessly cumbersome and developers spend absurd amounts of time working around the bloated technology that is Java with Spring Framework plus 100 or so alphabet soup libraries that are needed to make java useful for solving real-world problems then add to that 7 or more flavors of JavaScript libraries needed to build Web UIs, plus an assortment of scaffolding tools, build and test frameworks and more alphabet soup needed to make javascript useful.  All of this rather than creating software solutions that address real needs.  Call me dense or foolhardy, but when too much technology is getting in the way of building solutions that actually accelerate the construction of reliable software, it causes me to question the decision-makers and others who influenced the technology choices in the first place.

Perhaps I'm too critical of the Java Community.  Perhaps at the end of the day it's really the fault of Systems Architects who are far too wrapped up in jargon, buzzwords and bleeding edge frameworks and cutting edge technology to see the forest through the trees.

What attracted me to Software Engineering in the first place was the ability of engineers to build functional, full-featured software solutions by employing a programming language in a very elegant manner.

Once upon a time I was especially attracted to the C programming language due to the elegance of the language, it's syntax and the various constructs that were present in the language and supported by C compilers.

As a professional developer, I also experienced some of the limits of the C programming language in the real world.  In time, Java caught my attention as it added the object-oriented constructs that were missing from the conventional C programming language without introducing a lot of bloat or inelegant features to the language, which I perceived as a failing of C++.

I was also attracted to functional programming languages such as LISP and PROLOG, and I found the list-processing abilities within LISP particularly inspiring so much so that to this day, I find myself building and/or employing parsers that are very similar to techniques that are found in LISP.  I also find myself building semantic constructs such as those found in PROLOG, and use these to craft solutions for complex domains with rich semantic-oriented knowledge.  But of course I typically try to reuse what is there in the stack and the libraries, but Java has lost much of it's luster for me.

I have been more impressed with the .NET stack than the Java stack.  Perhaps .NET benefits from the fact that it has mostly been a closed-source platform until recent years, whatever the case, it is far more elegant in my opinion than it's SUN-come-Oracle counterpart technology.  But .NET is showing some signs of bloat too.

My mind is always looking for or building short-cuts that enable highly maintainable software that exhibits high reuse and high-reliability.  My philosophy: "Why build a solution with 1 million lines of code if it can be done in 7500 lines?  Not only is the 7500 line solution going to be less brittle and have fewer points of failure, but it will be orders of magnitude more maintainable.  I was particularly pleased when command line compilers gave way to GUI-based Development Environments.  In my opinion, if I was building slick GUIs for my applications, why wasn't I working within a development environment that came with a slick GUI?  In my assessment Software Engineering as a science has failed to lead the profession in the  proper direction.  We've lost sight of the principle that making the construction of rich software more accessible to all of the best and brightest will inspire them to build software with greater functionality, flexibility, portability, maintainability, reuse and security.  That is not to say that this doesn't happen today, but I've been frequently disappointed in the cumbersome techniques that are employed in building software products and solutions -- within both the largest companies in the world as well as the smallest companies.  Why  would anyone deliberately place so much red tape in the way of building useful software?  Perhaps when building for the DOD or NASA, it is unavoidable, but for most software built today, it seems that the programming languages and the tooling that is used gets in the way.

Is the software crisis any better than it was 30 years ago? Arguably it is not.  Perhaps there are a greater handful of successful projects, but these are almost assuredly offset by a greater number of failed projects.  Just because we have first-hand evidence of software from Google, Amazon.com, Microsoft, Facebook, and countless other technology companies that is used every day, with some measure of reliability and functionality doesn't mean that there aren't thousands of other products that died within the software engineering organization.

So, too, I've learned that Agile is little more than a gateway drug.  As anyone who has transitioned to Agile understands, to do agile properly requires the procurement of a vast soup of tools that are needed to properly administer Agile teams and also tools that are needed to achieve continuous integration (CI), which after all is the premise of most Agile methods, Don't get me wrong, I appreciate the idea that iterative development is at the heart of building working software   But CI tooling today requires far too much cumbersome work, and even more ingredients in its soup to employ properly.  It seems that a leap is needed to achieve CI more seamlessly.

Perhaps in time that is what will evolve, but i don't imagine that happening through a community process or any of the approaches that have brought the state of the art of Software Engineering or Java development to the place that we are at today.  To improve upon software development methods, we need to think about software engineering and Continuous Integration differently.  I firmly believe that this is precisely what is next in software engineering.  By thinking about the complexity of modern software engineering methods differently, we will find methods and technologies that enable software engineers to do more engineering in shorter amounts of time and there is great goodness in such a vision.  I am confident that this vision will soon be a reality thanks to the work of like-minded software engineers, researchers and innovators.

Is a Lack of Diversity Equivalent to Racism?

If you listen to Liberals and Conservatives you get a strikingly different characterization of our country.  Liberals want you to think that the country has never been more divided and that a divisive narrative is playing out in this country that threatens to doom our democracy; whereas Conservatives will have you think that the Liberal narrative is little more than sour grapes over the fact that Hillary Clinton lost the

2016 presidential election.

I have a theory which is different from the message that we hear from the President, from the Republican leadreship or from the Democratic leadership.  Let's take a look at the makeup of the leadership of the two parties.

Democrats have been preaching diversity for over 40 years.  The topmost leadership of the Democratic party are people who primarily come from New York and California, Michigan and Illinois.  These are states  where every day you are confronted with  diverse people and diverse mindsets, especially within the most populous cities in those states.  In Los Angeles, San Francisco, New York City, Chicago and Detroit, you are exposed to people of all races on a daily basis.  You are literally surrounded by every color of the Rainbow Coalition constantly.  Acceptance of diversity is not a question, it is an imperative.  You either accept diversity or you are out of step with  your community in a most profound manner.  However, even for liberals in Middle America, the daily exposure to a diverse population is less common. you may hold old fashioned attitudes and not be out of step with your community.

Democrats and liberals, in genera,l would have you believe that failure to accept every modality of diversity including every category within the LGBTQO+ continuum is racist and intolerant.  Perhaps this is true and perhaps the liberal leadership is correct, but is it not equally intolerant to call out everyone in the country who is not awake to the LGBTQO+ continuum as racists. Is it evil to be unenlightened?  I think not!  Rather, I think that it is wrong to label middle Americans as racists and anti-diversity solely because they have not been exposed to diversity.  This would be akin to labeling all sea life as alien simply because we cannot survive in a salt water ecosystem!  A fish is no more evil simply because it is a fish.  No more is a farmer in Iowa or a rancher in Wyoming a racist simply because they do not have the same concept of diversity as someone from San Francisco or Chicago.  They may not be tolerant or enlightened, but they are also not racists.

Liberals do not accept that there is a difference between lack of tolerance or lack of accepting diversity.  All are lumped into the efficient catchphrase "racist". It seems to me a rather intolerant perspective to classify everyone who doesn't think the way you do as intolerant, opposed to diversity and racist.  Clearly not all who do not think the same as the liberal establishment are not intolerant racists.  Moreover, isn't it hypocritical to label people who don't think the way that you do? Isn't that a lack of diversity itself?