Even AI Cannot Kill The SDLC

In chapter 6 of the book “Peopleware” by Tom DeMarco and Timothy Lester prophetically discuss the situation we now face with AI generated coding:  “…even if coding and testing went away entirely, you couldn’t expect a gain of 100%.  There’s still all the analysis, negotiation, specification, training, acceptance testing, conversion and cut-over to be done.”

This is really the crux of the problem facing us today.  AI has reduced the coding time to next to nothing, but all of these other parts of the Software Development Life Cycle (SDLC) were developed for a reason, at the cost of decades of failed projects. Even though code can now be produced fast, this does not mitigate the need for a good set of requirements.  If one doesn’t define success they can’t achieve it.  Negotiation is an important part of the process of the requirements development process.  The Stingley Principle of Uncertainty states that the process of writing software changes the software.  It also changes the developer.  It also changes the customer.  These changes begin in a project’s Requirements Gathering Phase when the developer and the user discuss the requirements.  As the developer learns what the user wants, the user learns about the art of the possible along with a somewhat deeper knowledge of their own goals, assumptions and aspirations.  These won’t go away with AI.  Even when the developer is an LLM and the customer is the person writing the prompts, the same processes are occurring.  The LLM learns from the user and the user learns from the LLM and a negotiation takes place.

As the software is developed, the prompts effectively become the software specification.  These prompts and their resultant code cycle through iterations typical of an agile development and testing process until the project runs out of time, money or patience and deployment is declared.  As we have learned over the last 80 years, deployment is actually an arbitrary point in time along the lifespan of a system.  The product continues to cycle through development, well after deployment, until either the business process is abandoned or the code is replaced.

The problem we are beginning to emerge is: Who is responsible for cut-over and continuing support?  Some products that are written in computer languages that can be read can reassign these responsibilities, and thus effect a support and succession capability.  Though, there can still be problems in transferring security keys which many of these systems rely on.  Low-code approaches exacerbate this problem, as often these systems are inextricably tied to the author or their domain, making transferring support to a successor difficult if not impossible.

When code is generated by Artificial Intelligence, the prompts combined with that code essentially become the software specification and they become Configuration Items (CIs).  AI tools can easily reverse engineer the code so it is possible to simply re-examine the code to determine what it does. but computers do not do well at grasping context, so retaining the prompts could be helpful in documenting the intent of the system.  Low code systems are more problematic because often the only way to document how a system was developed is with a collection of screen snaps and associated documentation explaining what these images represent.

The conclusion, therefore is:  Even though AI based systems development can make bespoke programs widely available across the enterprise, which would seem to scuttle the SDLC practices developed over decades, in fact the Software Development Life Cycle is intrinsic to software development regardless of who (or what) is developing it.