I’m seeing a lot of talk online about agile software development – what it is, what it used to be, what it’s supposed to be, whether it’s dead or alive, how we can design better agile frameworks, etc. Maybe the subject isn’t being discussed broadly, but I’m connected with so many “agile” people that it gets a lot of play in my feeds. I get the feeling people are beating up a rag doll, or flogging a dead horse, if you like old sayings.
I think there are three converging trends that are quickly making the whole subject moot.
Trend #1: Event Modeling
One of the key benefits of agile software development is that it helps us build habitable code bases. There is a high cost of delay in making changes and correcting errors when code is difficult to understand and to modify safely. Among other things, the Clean Code book, the Software Craftsmanship movement, and development methods such as Extreme Programming are/were responses to the need for habitable code.
I’ve long thought the best way to solve a problem is to change the realities that generate the problem so that the problem simply ceases to exist, rather than accepting the existence of the problem and trying to patch it or work around it, adding more and more complexity to our work processes to achieve that. Of course, it’s often impossible to make problems disappear in that way; but what if we could eliminate the need to maintain code bases? Then the solution – habitable code – would no longer be necessary.
Adam Dymitruk thought about this, and a raft of other issues most of us had considered “the nature of the beast” in software development, and came up with the idea of Event Modeling and Event Sourcing. In an online meeting with him, he kindly took the time to explain the basics of Event Modeling and to demonstrate a tool his company uses to deliver application software to clients.
This post isn’t the place to go into the details about all that, but for my immediate purposes the take-away is that units of code are produced to a spec defined through a model of the solution, and delivered for a fixed price. If the client wants changes to the application, new units of code are produced to replace the original ones. The source code in a unit that has been delivered is never modified; never maintained. When application functionality must change, the unit of code is replaced with a new one.
As this approach to application software delivery gains traction in the industry, the need for code maintenance will decrease. Many of the techniques, methods, and tools we struggle to implement, teach, coach, and use effectively will simply become unnecessary. Several of the issues we’ve come to accept in the software development world will disappear in a puff of logic.
I don’t expect software of all kinds to be done in this way, but conventional application software can definitely be done in this way; and the vast majority of software-related jobs pertain to application software. The other two trends will act to make this shift more realistic.
Bottom line: We don’t need code to be habitable. We need it to be easy to generate and replace.
Trend #2: AI-generated code
The current capabilities of AI-based coding assistants are not sufficient to replace well-qualified humans in the software development process. They generate a lot of junk that has to be reviewed and tweaked by knowledgeable humans. In the hands of less-qualified programmers these tools actually do harm. But people are working hard to improve the capabilities of AI coding assistants.
When Adam was showing me the development tool his company uses to support Event Sourcing, he demonstrated the use of an integrated AI assistant to generate the code for a unit that performs a common function in many applications (the exact function is not relevant here). In the demo, the AI assistant generated code that covered 100% of the specifications for the code unit. Adam indicated the assistant usually produces code that covers between 80% and 100% of specs.
This is possible because we’re talking about conventional application software, and not anything esoteric or groundbreaking. The LLMs have ingested plenty of examples of this kind of code.
A competent programmer – not necessarily an expert – can complete the functionality of the AI-generated code in minutes. With improvements in the technology that we will probably see within a year, a person who is not a programmer at all will be able to specify the solution they need at the level of the model, and let the code fall out automatically.
That code may not be pretty, but as long as it performs the required function it’s good enough. After all, the code will never be inspected or modified by a human. And if it doesn’t do the job, then the interested person can prompt the AI assistant again and again until something pops out that “works.” (That is, it “works” well enough in view of Trend #3, described below.) I think we are not far from that point.
This observation pertains to conventional application software, not necessarily to every kind of software. Someone has to work on the AI code. We just don’t need 25 million people to do that. A few thousand will be enough. And there goes the job market.
Adam’s current business model is profitable for now, but it’s temporary – we’re in a transitional period now, when we urgently need a cure for the masses of poorly-qualified human programmers but the AI coding assistants are not quite ready for prime time. Once the quality of AI coding assistants reaches a slightly higher level than today, humans will not be needed to deliver the solutions his company delivers.
Well, not humans who write software for a living, anyway. Humans who know how to request output from an AI assistant will be sufficient. The clients will be able to handle it on their own, without hiring people like us.
This change in the labor market strikes me as similar to the change that occurred when the automobile became widely used. Many who had specialized in work such as changing horseshoes and making saddles, bridles, and stirrups suddenly found themselves unemployable. Sure, artisans today still do that work, but there is no longer a large job market for those skills.
With the advent of AI-generated code, a similar change in the job market is occurring. Some highly-skilled people will still be needed to develop and maintain the AI code itself, and possibly for a short list of specialized or niche solutions for which few code examples are available for LLMs to ingest, but the job market for general-purpose application software development will evaporate.
Trend #3: Reduced expectations and lowered standards
Starting around 2000, there’s been a steady increase in the demand for rapid delivery of software solutions. A great deal of emphasis has been placed on “going faster” in software development. Many people who have not experienced “agile” software development assume its only purpose is to enable us to “go faster.”
At the same time, the number of people entering the field of programming has mushroomed. Twenty years ago software development was an attractive occupation that paid well compared with many other white-collar jobs. That remained true until pay rates declined to 1980s levels while the cost of living did not. Many millions of barely-qualified individuals have been spewing out code as rapidly as possible for the past 25 years.
The result is a general decline in the quality of software products. When I’ve written about this previously, the majority of responses have been along the lines of denial (“There’s nothing wrong with software quality!”) or self-defense (“Our team always meets its Definition of Done!”)
Testers are more willing than programmers to admit software quality is poor, but even they tend to be defensive, as they’re the ones who’ve been the proud gatekeepers of quality. Granted, it would have been nearly impossible for them to stem the tide, but in the end the tide wasn’t stemmed, so here we are.
It seems as if current generations of adults (except the oldest) are so accustomed to shoddy software that they have come to regard it as normal. Despite the dependency of our society on software, hardly any applications fully work as they should and relatively few offer a reasonable user experience. Most of the time, we have to work around issues in the products in order to get anything useful to happen. Even when the software more-or-less “works,” we are constantly interrupted with targeted advertising. Tasks that technology should simplify become more time-consuming and frustrating instead.
Instead of taking the (simple) steps needed to produce high-quality code (you know, all that “agile” stuff), it seems as if most programmers want to deny the value of good software engineering practices and continue to hack up solutions quickly, with little attention to quality.
Convergence
When the trend of Event Sourcing combined with improved AI coding assistants converges with the trend of low expectations and low standards for software products, the job market for application programmers will disappear.
AI will generate throw-away code that performs, clumsily, perhaps 80% of the functionality users need at the moment and that gets replaced in a matter of weeks. The users won’t complain because that’s the level of quality they’ve come to expect.
The billionaires who own everything don’t understand software quality and don’t care about it any more than they care about healthcare or climate change. They will always go for the cheapest-in-the-short-term alternative. We can explain the business value of high-quality software until we’re blue in the face, and it won’t matter.
I think that time is not far off, and it makes the passionate discussions of things like Pair Programming and Test-Driven Development and whether we’re doing Scrum correctly and whether LeSS is better than SAFe seem rather pointless.