By aalmiray
via testearly.com
Published: Jul 15 2008 / 17:20
The notion of executable documentation, where a stakeholder’s language is leveraged as a means for decreasing the impedance mismatch between what they want and what they ultimately receive, has, for some time, been ambition of many a development team (and corresponding stakeholders!). While executable documentation proves to be an effective means in assuring customers get what they actually want, this technique also proves to facilitate a deeper level of collaboration between all parties because everyone is using the same language.
SaveShareSend
Tags: frameworks, groovy, java, open source
-
Float vs Position in Layout: My Gripe with Andy Clarke
-
Generating Friendly URLs using mod_rewrite from Apache HTTP Server
-
Monday C++ Quiz: We Are All Confused
-
Integrating Agile Practices With a Global Delivery Model
-
Team up TeamCity with Fluid and Google Chrome
-
Extract alphabetical sequences from a string
Comments
willcode4beer replied ago:
This always makes me smile.
The fundamental idea is, try to structure the language of a specification so that it can be "compiled" or "executed". The issue is, once your language has that much structure, and the specification specified to that level of detail, you've created a new programming language (and the cycle continues anew).
:-)
Remember, COBOL was originally intended for non-programmers to write programs.
The reasons these posts of how Perl/Python/Ruby/Groovy will get us there always miss the fundamental issue.
The hard part of programming is not the language we use (anybody can learn a programming language).
The hard part is identifying the real problems and engineering solutions to those problems.
A programming language is simply the tool we use to specify that solution.
Voters For This Link (12)
Voters Against This Link (1)