"Agile is the process used by disciplined professionals observed in the wild."
- Robert "Uncle Bob" Martin
The state of software engineering is in tremendous disarray. The root cause of this disarray: Academia forfeited the stewardship of Software Engineering over 40 years ago. Corporations are the only stewards of software engineering, today. Corporations need to maximize the profits of their intellectual property.. Software engineering is not the domain of practitioners. It is the domain of profit-driven corporations. with a primary interest in fame and fortune. rather than benefitting humanity.
Each contributor to a software solution must simplify a complex mess. They must do so in the smallest amount of time. In short, the ship of the majority of Software Applications is on a collision course with failure
Enter Agile practices
Agile mandates that we embrace software that is on a collision course with failure. Then, take that software and force highly-skilled, well-compensated engineers to do everything all at the same time, and make certain that it works. Why?
1) Because the members of the Agile Alliance said it was a better way of building software.
2) Because employers bought a bill of goods, and they insist on a sizable return on investment.
Many challenges emerge
1) Agile is the antithesis of inclusivity. It teaches engineers a notion of survival of the fittest.
Agile creates silos of experts rather than teams of collaborators. Sure, Agile emphasizes teamwork. But, Agile teams observed in the wild seldom exhibit teamwork. Agile is little more than a race to the finish line, underscored by mediocrity. Gone is any notion of disciplined project management. Instead, we have SCRUM Masters who avoid project management at all cost. Software engineers function as clerks, production typists, janitors and project managers. On occasion, they wear a code-monkey hat. None of this resembles software engineering, much less computer programming.
2) It is nearly impossible to agilify legacy software or commercial software.
- Agile methods work best when there is 100% code coverage and the engineers understand the inner workings of every facet of the software product.
- 100% code coverage is costly, but it is far easier to achieve if you own every line of code. The engineer who profoundly understands the code is needed to produce thorough code coverage. You cannot delegate this work to another member of the team.
- Few commercial software vendors embody this deep level of ownership of code. It is unlikely that a software vendor will deliver a 100% coverage test suite with their software. This is due to fear of reverse engineering.
- Legacy software suffers from a lack of test coverage by definition. Legacy software is not built using a test-first methodology. How can you justify the cost to build required test suites for a sizeable application? Hence, it is common to see organizations concede that 50% or 70% code coverage is better than 0%.
Even new software solutions fail at a high rate under Agile
- Software projects fail under an Agile Regime at a higher rate than Waterfall methods. Agile methods strive to keep projects moving forward. Waterfall methods also strive to keep projects moving forward. Regardless, we expect that this will lead to successful completion. At the turn of the century, software projects failed at an unacceptable rate. Today, software failures are trending in the wrong direction. In response, Agile practitioners adopt a new lexicon to explain their failures. "We failed the regression test, but we isolated the error and we corrected the code." Is this acceptable? No!
3. "Fail Fast," shout the Agilists, but take caution - Managers are not so tolerant of failure.
- It is not a manager's nature to praise a team's ability to fail.
- Moreover, "Fail Fast" often morphs into "Fail at Velocity". There you have it: a perfect recipe for failure -- Breaking Software Wholesale!
Storm-clouds on the horizon
Most companies throughout the world are trying to migrate to Cloud-based solutions. Executives repeat the mantra:
"We feel that the more modern our applications get through migration to the cloud, the more stable they will become."
You cannot achieve software stability in this way. Lifting and shifting a failed, and overly complex application to the cloud won't fix the problem. You must re-architect, re-design and rewrite. It doesn't happen as a by-product of migration. This is a recipe for turning the Cloud into a Storm-cloud.
