Beyond AI - a path to automated software creation

What do the owners and end-users want from their software systems? A good starting point is:

• Reliable: bug-free software with no downtime

• Effective: meets the needs of the end-users

• Secure: safe from lock-in, program bugs, malware, hacking, unauthorised access

• Current: can be maintained in parallel with changing end-user needs

• Understandable: stakeholders can access and understand documentation that is always consistent with the running system

• Efficient: developed, deployed and executed using optimal resources

• Scalable: user numbers and other application limits can be adjusted dynamically

We can make a neat acronym RESCUES from this.

I want to add a further desirable and transformative quality to the above RESCUES set:

• Quotable: enables a fixed cost and delivery quote

Vendors of software development tools and current practitioners of software development may feel that they meet the RESCUES requirement but I know of no current combination of methods, tools and people that does. If you throw enough of the right resources at a project it can be delivered to achieve the reliable, effective, secure and scalable requirements but not efficiently and not in a form that is understandable to all stakeholders and/or maintains its portability and currency throughout its life. Fixed price and delivery quoting of software development is virtually unheard of for any serious project.

These quality objectives can only be achieved consistently across the software industry by the use of automation. Automation is necessary to guarantee our quality objectives but it should also invite human intuition, experience and creativity which remain irreplaceable.

Current AI offerings are not capable of automating the development of software systems. Equally current development software development methods are not suited to using future AI advances to optimise automation. Program code assistance can be helpful to programmers but will not provide the transformative efficiencies and certainties that an automated software system development and delivery method promises.

The key to the promised land lies in the use of a standard system specification structure and language that provides a single source of truth for all stakeholders.

No software development project can begin without a stated requirement and no software development project can be advanced without first specifying the deliverables to meet the requirement. It doesn’t matter if it is a large formal document or a discussion with an end-user, specification is always required.

Given that we need specification, why not create a specification document that that can be comfortably signed-off by all stakeholders and has a structure that enables automated building and deployment.

The basic requirement for such a specification is to provide a clear and intuitive document that contains natural language to specify system functionality with sufficient precision to enable a computer to transform it into an executable software system that complies with all of our RESCUES+Q quality objectives.

This is a challenge but has been proven to be both possible and effective in complex real-world exercises and is well within the capabilities of current software development and productivity tool builders.

The running application must be generated directly from the approved specification. This provides truly transformative benefits to software developers and their clients:

- a clear unambiguous contract between developer and client

- certainty of cost and delivery time

- documentation that is accessible and understandable by all stakeholders

- documentation that is always consistent with the running system

- ease of change

- consistent reliability, security, scalability, portability and efficiency

- focus on system functionality instead of program code

- very large cost reductions over the application lifecycle

I call this a "specification-only” method or environment because the specification is the only authoritative document that describes the functionality of the subject software system and is the single source of truth for all stake-holders.

This specification-only method does not rely on the use of generative or general AI but it does provide great potential to benefit from future development of machine learning models based on specification-only systems. In the future, it could be possible for a complete system specification to be generated from requirement statements.

The specification-only method is conceptually simple but its implementation entails complex underpinnings. The technology and skills to implement it are all currently available in abundance, however, the secret of success will not be found in the technological underpinnings but in the faithful adherence to the basic requirements for the specification:

1. The use of natural language that can be understood by all stakeholders

2. Sufficient precision to be transformed by a computer into a running application

There are, of course, many other requirements that must be met by the specification structure and language. It needs to cater for the whole of a software system including UX, data management and the processing of business rules and algorithms. It needs to be extendable so that approved new language can be added to a curated core and to enable libraries of standards-based domain-oriented language. It needs to enable integration with legacy systems, unique custom coded software and physical devices.

A fully implemented specification-only environment should be able to cope with any software system project of any size and complexity.

This concept is not just theoretical, it was first used in manual form to provide complex turn-key enterprise resource planning systems, ie. the core business systems for manufacturers, wholesalers, retailers, finance providers etc. The systems specification was created in a proprietary structure using natural language, signed-off by the client and then the specification sections were distributed unchanged to programmers for coding without preparing separate program specifications. This method obviously carried risk within the program coding phase but it still enabled fixed cost quoting and faster delivery.

The success of the manual specification-only method led to an ambition to automate the build phase in order to eliminate the risk posed by manual program coding and to accelerate delivery time.

Over a period of more than a decade, a specification language was developed for automated building of the specified systems; run-time engines for desktops, phones and the internet were built; and a number of challenging projects were successfully implemented.

For example, a tactical intelligence system for the Department of Defence that integrated third party vendor software, military messaging systems and embedded military software algorithms.

This system automatically parsed relevant military messages to extract objects of interest (people, organisations, locations, events, weapons etc) and data related to those objects (names, addresses, phone numbers, images, dates, times etc) for inclusion into a repository. A typical use of the repository would be a preparatory report showing activity in a patrol area including mapped hotspots; people of interest (with photos); relationships between people, organisations and events; and time-of-day and day-of-week patterns of activity.

Incumbent providers were not able to demonstrate a solution nor were they willing to take on the project within an acceptable budget. We were able to provide a clear specification and demonstrate its functionality. We were able to quote a fixed price and delivery time. The specification could be embedded within a contractual DoD document. The clients were comfortable in signing it off. The executable application was generated directly from the specification ensuring it was always compliant with the approved contract.

Another challenging problem was solved for a large taxation agency. Targeted entities were identified for further research which could take a month or more for a single entity. The proposed system dramatically shortened this process by providing all relevant data in a single chart at appropriate points in an analyst’s workflow. Data from disparate sources were selectively merged into a single view. The client could understand exactly what would be delivered and the system used the client’s preferred charting technology. A fixed price and delivery time was quoted to fit within their budget constraints.

More conventional information management systems such as Case Management and WholeSale/Retail collaboration systems were also successfully developed using the specification-only method.

The opportunities to deliver the projects were entirely dependent on the specification-only method. Without the specification-only method we were nothing, the competition were typically heavy hitters with very deep pockets (eg. IBM). We were successful because of the understandable specification, the clarity of the contract that could be signed off, the fixed price quote and the speed of delivery.

Some examples of what a specification-only project might look like can be seen on this site www.specificationonly.com . The examples are small but range from very simple to quite complex. They optimise automation while demonstrating the tension between the need to be understandable and the need to be precise.

Don’t be fooled by the brevity and simplicity of the specifications. An infinite variety of software systems of any size can be delivered using the same method.

Experienced developers will see language in the specification that looks a bit like program code or scripting. This is because specifications need to be specific and these statements have proven over time to be the most efficient and natural way of specification, eg:

AmountToPay = Price + VAT

AmountToPay = Price - Discount if Customer.Type = ‘govt’

In all of the specification-only projects we have implemented, no-one has pushed back against the structure and language of the specification. Each stakeholder has been able to understand the relevant sections of the specification and comfortably approve them.

A recommended development method that goes hand-in-hand with the specification-only infrastructure works back from the specified deliverables (a similar concept to Amazon’s much vaunted process of “working backwards”). Each deliverable data item must be identified and sourced (it must come from somewhere). This is a simple process and can be assisted by tools to ensure that identifiers are unique and sources are valid. Database requirements fall out of this process so that where database schema creation or change is required it can be automatically generated using the provided tools.

The automated specification-only method provides a clear competitive advantage because of ease of contracting, lower costs and faster delivery. Fixed prices can be quoted with certainty of delivery while still retaining high profit margins. Support responsibilities are clear; the application always operates in accordance with the approved specification.

So we have a proven concept and successful implementation projects! Why hasn’t the

whole software development world adopted this to the benefit of their clients and themselves? One thing:

- support of a major software tools and platforms provider

The committed support of at least one major software industry player is a must My preference is for an open system specification standard, however, the commitment of a trusted and influential leader is the more important element.

There are compelling arguments to be the first mover. The first successful mover into this space can create a defacto standard and become “the" software development company. The specification-only method is a conceptually simple change to the software development process but it will have a profound impact on the software industry.

There is further work to be completed to enable industrial strength language, tools and platforms. The responsibility and capability for that work lies where it should; with the trusted industry experts, ie. proven software development tool and platform providers.

Developers will find that their existing skills transfer easily to a more creative, productive and satisfying process. Software system consumers will experience a more consistent, professional process that gifts them genuine control of their software applications and budgets from initial contract through to ongoing maintenance of the running systems.

I have written this article as an introduction to the development of software systems using the specification-only method. After spending many years working with a wide variety of software development tools and methods, I know that the specification-only method provides a huge competitive advantage and can bring a new level of professionalism and simple efficiency to the production and maintenance of software systems.

I don’t claim to have built the ultimate specification-only system but I have gained a wealth of knowledge from experimentation failures and implementation successes. Our proof-of-concept specification language and enabling tools have proven to be effective, however, an expert tool and platform provider could build something really wonderful provided they stay faithful to the two basic principles:

1. The use of natural language that can be understood by all stakeholders

2. Sufficient precision to be transformed by a computer into a running application

and respect our RESCUES + Q quality objectives.

Courteous and thoughtful commentary is welcome.