The Forgotten
Methodology

📖 Once Upon a Time in Singapore...

The year was 1997. In Singapore, a massive banking project was in crisis. The United Overseas Bank had hired developers from around the world, but something wasn't working. The business people couldn't understand the developers. The developers couldn't understand the requirements. Sound familiar?

Enter Jeff De Luca and Peter Coad, two software veterans who looked at this chaos and asked a radical question:

They called it Feature-Driven Development (FDD), and it was beautiful. The banking project was saved. A book was written. The methodology was documented.

✨ The Magic Formula

At the heart of FDD was a deceptively simple idea: every feature should be expressed as an action performed on a result for a business object.

This wasn't just a naming convention. It was a language. A way for product managers, business analysts, and developers to speak the same tongue. When a PM wrote "Calculate the total for the shopping cart," the developer knew exactly what to build.

Feature Sets: The Bigger Picture

Individual features were grouped into Feature Sets—collections of related functionality that together delivered a business capability. Think of a Feature Set as a chapter in your application's story.

A "User Management" feature set might contain:

• Create the account for the user
• Validate the credentials for the user
• Update the profile for the user
• Reset the password for the user

Parking Lots: Where Features Wait Their Turn

FDD introduced the concept of Parking Lots—visual dashboards showing the status of all feature sets. At a glance, anyone (yes, even the CEO) could see what was done, what was in progress, and what was coming.

The parking lot made invisible work visible. No more "it's 90% done" for six months straight. Progress was real, measurable, and understandable by everyone.

💨 So What Happened?

FDD should have taken over the world. It had everything: clarity, structure, business alignment. But then came Agile. Then Scrum. Then Kanban. The industry moved on, chasing the next methodology like a dog chasing squirrels.

The action-result-object pattern was brilliant for documentation. But developers still had to translate those features into Python, Java, C#. The gap remained.

🤖 Why AI Changes Everything

Here's the thing about Large Language Models: they're really good at understanding structured natural language. When you write:

(createUser: User API) {
    <Extract> the <data> from the <request: body>.
    <Validate> the <data> against <user-schema>.
    <Store> the <user> into the <database>.
    <Return> an <OK: status> with <user>.
}

An AI doesn't have to guess what you mean. The structure is the specification. There's no translation gap, no ambiguity, no "oh, I thought you meant..."

The Bridge Between Worlds

For decades, we've had two separate languages: business-speak and code. Product managers write user stories. Developers translate them. Information is lost. Bugs are born.

ARO eliminates this gap entirely:

• The PM describes a feature → That's the code
• The AI understands the intent → No translation needed
• The feature set executes → Exactly as described

This is what FDD was trying to achieve in 1997. They just didn't have an AI that could make features executable.

Now we do.

🚀 The Future is Features

ARO isn't just a new programming language. It's the realization of a 25-year-old dream: a world where business and code speak the same language.

Every ARO statement follows the Action-Result-Object pattern. Every feature set maps to a business capability. Every application tells a story that anyone can read.

And with AI as your coding partner, that story writes itself.