tag:blogger.com,1999:blog-311550892563951795.post8464384970841604890..comments2023-04-29T11:35:42.458+01:00Comments on Adrian Mowat on Agile Data Integration: It's much more than throwing out the documentsAdrian Mowathttp://www.blogger.com/profile/09845126205768113190noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-311550892563951795.post-48761052569338014752008-05-05T09:40:00.000+01:002008-05-05T09:40:00.000+01:00If the code and tests aren't readable, it's better...If the code and tests aren't readable, it's better to work on making them more readable before deciding to maintain two sets of parallel specifications.<BR/><BR/>Especially for code, ideally, the specification is the code. This can often be done for certain areas of the program by creating a DSL.<BR/><BR/>If you documents for regulatory purposes, well, that's fair enough, but these then become part of the output of the system that produces your product. And, ideally, if something other than the document actually implements the regulatory constraints, you should try to generate the document from that (or vice versa, if that's easier).Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-311550892563951795.post-32188661721558946862008-05-01T20:36:00.000+01:002008-05-01T20:36:00.000+01:00Don't confuse throwing out documents with throwing...Don't confuse throwing out documents with throwing out documentation (i.e., information). What if an executable specification happened to describe a risk mitigation. And what if the executable specification was indeed readable by most. It's quite possible to do this using FIT or FitNesse. The result is a single virtual artifact that documents the risk, the mitigation strategy, and the effectiveness of the mitigation. Furthermore, this eliminates the wasteful practice of early baselining the software to insure a mitigation hasn't been compromised when the software is changed - instead you just add the mitigation tests to the regression suite.<BR/><BR/>Agile is not about avoiding important things. It's about accomplishing that which is important in a leaner, and often far superior way.Anonymoushttps://www.blogger.com/profile/10593020933322726670noreply@blogger.comtag:blogger.com,1999:blog-311550892563951795.post-2659822484355308262008-04-28T10:35:00.000+01:002008-04-28T10:35:00.000+01:00What is interesting however is the assumption that...What is interesting however is the assumption that the documentation on tests, risks and requirements are waste though. What if you can show that they do add value? For instance in many regulated environments those document provide assurance to the regulators that you have mitigated the risks, tested the important stuff and met the regulatory requirements. Also the documents are readable by most whereas the code and tests aren't always.Vertuehttps://www.blogger.com/profile/13606425236899694930noreply@blogger.com