Before we can write truly agile code, and create the next generation of complex and truly magnificent software, we must have taken care of the basics. Before that glorious day, we will have to take care of a few little things to open the door.

The term "Framework" must be fully defined.

We are currently using Frameworks, and all we know is that they are something in between components and libraries, something between whitebox and blackbox, something architectural, something with domain knowledge. We have to define what it is, provide it with a "language" and "life" of its own. We have to do it, to get Frameworks, easier to "build", easier to "USE" and easier to "extend", and consistent across languages and platforms.

How we use Frameworks must be defined.

Hotpoints, extensions, config/metadata, settings, code generation), must all become standardized and tools built on top. Is Oslo going to help us?
For example a visual tool that shows the relationships between classes and code from Design Patterns and architectural pattern views.
We need the "plug-in" mechanism for Frameworks to be defined and how we create these plug-ins. We need an Architectural Constraints Language.

How Frameworks communicate with Frameworks

A Framework would multiply in value if it could plug into other Frameworks. Objects are too small a unit. By defining Frameworks, we can also define how they interact. The Architectural Constraints Language can be used to refine a Framework's context, execution and visibility.

Code Generation must reach critical mass.

Developers will need to look at the "Same Code" in "Different Ways". ie. formatting, visual vs text, hierarchical, call contexts and so on.

CodeGen must be reverse engineered as well as generated. We must be able to go back and rerun the code generation, and have it merge and understand our changes since the last run. CodeGen needs to be included within even the smallest of tasks, not just the entire layer or tier.

For example, having a teh code for a Singleton generated, but afterwards it still understanding itself, so I can extend the Singleton to lets say FlyWeight, with a click of a refactoring menu.
We will only achieve this with the next step (MetaData)

Code MetaData and Semantics

We need our code files to split out and contain multiple layers of understanding.
We have code-behinds in Visual Studio.NET and thats the kind of thing I mean. Each code file, should have an associated file containing the metadata and understanding of it, providing tools with context and detail to act on.

For example: Using Annotations (Java) or Attributes (.NET) to define interfaces, as [HotSpot], [TemplateMethod], [Factory(creates typeof(BaseClass))] and it also requires more information regarding the Expression portions of code.
understanding that public string [Property], can be changed anytime and refactored automatically, rather than separate code to trudge through the code tree. The second I click on [Property] it should highlight and understand what to do. In the same way, if I click within a generated portion of code (such as a Code Snippet in VS.NET) it should still understand the Expressions, and always allow it to be changed.

Part of this, I believe should abstract the Code File, from the actual code visualization. The visual display of code, should be rendered in any language, syntax, formatting of my choice, and not be the actual code file.

Also MetaData for understanding the degree of differences between interfaces will be needed. (See Contract Agents)

Contract Agents

Instead of us declaratively defining explicit contracts, a more fuzzy, discovery agent.

For example:
Consider a Delivery arrives at your office. The hand-held device may query the network for a IDeliveryService on which it may have a simple method called Find(string name) returning some sort of helpful data for the Delivery Person.
Now consider that the service is actually called IDeliveryService2 and the method is actually called GetPerson(string name, string surname). So the client will break, it will not know anything about the other interface, as it is bound by contract to IDeliveryService not IDeliveryService2, nor does it understand the method as the signature is different.

What has to Grow up, is this notion of Contracts as an explicit, unchanging thing. You can look at those two Interfaces and spot the easy transition. It is a simple change, and it is such a shame, that we do not have smart enough mechanisms to realize that.

For software to grow up, we need "Contract Agents" and/or "Agile Interfaces".