My thinking is that while it is a solid idea, it would be an uphill battle at best. There are several challenges. First, how to represent the business rules so that they are clearly communicated to and through non-technical personnel. Second, to ensure that the human readable business rules are stated in such a way as to remain materially compliant to what the code is actually doing without handicapping either. Often times the most efficient way to handle something isn't exactly the most easily translated into human readable terms; an insertion sort for example. That technique in particular also could be grouped into a discussion of practical granularity. Then there's the whole issue of compliance to the standard by a team of developers, as well as compliance to the conceptual issues by the team of non-technical people, and the bridge that must necessarily be in place between the two camps to make it all work out. And finally there is the consideration of what this might cost the business organism in time and hard coin and how to measure the return on that investment.
On Fri, Jun 14, 2013 at 4:06 PM, Wjhonson <wjhon...@aol.com> wrote: > Several times I've run into business rules that I find embedded in code, > that are so old, that no one can remember why they were implemented or what > they could possibly mean to the business. > > I'm thinking of encoding in some routines, a way to output the rules it's > using on a periodic basis (like once a month?) so that business users are > made aware of what the rules are, and can therefore comment on what they > should be, or what should be removed. > > Anyone do this? Or have thoughts about what I'm proposing? > > _______________________________________________ > U2-Users mailing list > U2-Users@listserver.u2ug.org > http://listserver.u2ug.org/mailman/listinfo/u2-users > _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
