Ann All had a post on Agile development brings IT, business together that had the great phrase “application development 2.0″. In the article she mentioned some very worthy objectives for this 2.0 version of application development. Here they are, paraphrased slightly.

• Encourage close collaboration between developers and end users
• Involve users in quality assurance processes
• Don’t use traditional programming languages
• Stress simplicity
• Emphasize frequent releases
• Users, not developers, should determine new features

I will come back to the bit about “Use dynamic scripting languages like Ruby, Python and Perl” in a moment. Back to the list.

I am struck by the inherent contradiction between this list and traditional development technologies - code, to be blunt. How can we expect close collaboration between developers and end users if the developers are using a language (Java, C#, Perl) that the end users cannot read? How can users do quality assurance on code they can’t read? Perhaps users can be the drivers for new features, but wouldn’t it be better if they could actually so something about the features they want? How frequent can releases be if the code must go through the usual QA/test/deploy sequence?

The answer, I think, lies in “Don’t use traditional programming languages” though it is not “Use dynamic scripting languages like Ruby, Python and Perl”. As I noted before, this very focus on programming and programmers is a barrier to progress and replacing one procedural language with another won’t help because, as Ira Fuchs put it:

Programming languages today remain syntactic, abbreviated, and procedural, as opposed to semantic, verbose, and declarative

Instead of continuing to use procedural gobbledegook that no user is going to understand, it is time to move the business logic that drives our systems in to something more useful - business rules. Looking at Ann’s list in this context we see a different perspective:

• Encourage close collaboration between developers and end users
  CHECK - users can actually read and write business rules, allowing them to be equal participants in the specification of business logic.
• Involve users in quality assurance processes
  CHECK - ditto for checking that the rules really do what is needed because users can look at the rules and say things like “Yup, that’s what the regulation says” or “That’s our policy”.
• Don’t use traditional programming languages
  CHECK - use a declarative, verbose and semantically rich business rules language instead
• Stress simplicity
  CHECK - the ratio of business rules to lines of code is often very high, making the same functionality much simpler to specify
• Emphasize frequent releases
  CHECK - business users can make changes to rules that can be tested in isolation and rapidly deployed, enabling “releases” of business logic daily if necessary.
• Users, not developers, should determine new features
  CHECK - in fact users, not developers, BUILD the new features when those features are about the business logic in the system.

So, a business rules approach should be part of Application Development 2.0. Stop writing code, start specifying business rules.

Lastly Ann correctly highlights Agile techniques as a component in Application Development 2.0 and this is entirely compatible with the use of business rules. Indeed, I wrote an article for InfoQ on this topic - rules and agile - some time ago but it is still worth a read. It is also interesting to consider the point at which Application Development 2.0 might not really be application development any more.