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.
Tweet
SaveShareSend
Tags: frameworks, groovy, java, open source
-
Grails hip tip: optional URL parameters
-
An Introduction to MVC - Server-Side Magazine
-
Use a classpath resource or kill your application’s portability
-
Control Your NAS Like You Control Your SAN.
-
Autoboxing pitfalls when comparing numbers with "=="
-
Announcement of Google Chrome OS: New idea of providing operating system in a browser
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 (13)
Voters Against This Link (1)