This page is intended to discuss the question

Is Domain Engineering compatible with Agile Software Development?

Given the current popularity of agile methodologies in the general software development community it is worthwhile to position DomainEngineering appropriately in order to avoid being dismissed as an unworkable, high-ceremony approach. Highly automated software development and the principles of the agile alliance don't have to be exclusice. In practice I found that using model-driven generators naturally leads to agile ApplicationEngineering?, opening up possibilities of domain exploration to application engineers that would be completely impractical in traditional, manually driven software development. Using advanced model-driven generators allows to react to most user requirements changes within hours and days rather than weeks or months, allows to shorten iteration times, and speeds up the user feedback cycle.

The mainstream attitude to generation is reflected in the otherwise excellent book SurvivingObjectOrientedProjects? by AlistairCockburn?:

... my colleages and I estimated that perhaps 5 percent of the total system code could have been generated from the business object model. ... The problem comes when you must add some computation that cannot be generated automatically. At that moment, the drawing of the object model, which moments before was an asset, becomes a liability ...

In short, the state-of-the-art of generative techniques is often judged by what is provided in the better known UML tools such as Rose, Together, and others. Needless to say that this makes it harder to convince traditional development teams that there is something to be gained by DomainEngineering and domain-specific techniques. To counter the simplistic arguments against generative techniques I have compared manual development, "traditional" development with a UML tool, and model-driven development with a modern generator in http://www.softmetaware.com/mda-implementationandmetrics.pdf. The comparison concentrates on the gains achievable by generation, and consciously relies largely on UML-based notations, with only a few domain-specific elements.

DomainEngineering leads to agile ApplicationEngineering?, but what about DomainEngineering itself? Does it make sense to talk about agile DomainEngineering?

JornBettin


Agile DomainEngineering requires a lot of flexibility from the tools that are used to build generators. I am aware of a few papers that address this issue, albeit in different terminology:

JoostVisser


In my feeling, DomainEngineering has a strong big-design-upfront feeling, which is at odds with, e.g., ExtremeProgramming. Discussing this with Howard Goodell, we also observed that

  • The explicit customer involvement of agile methods feels like a good combination with end-user programming as made possible by DomainSpecificLanguages
  • XP talks about letting end-users do acceptance testing via a DomainSpecificLanguage

-- ArieVanDeursen

Revision: r1.3 - 02 Mar 2003 - 12:51 - ArieVanDeursen
Transform > GenerativeProgrammingWiki > DomainEngineeringAndAgileSoftwareDevelopment
Copyright © 1999-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback