> Surely there must be some sort of canonical form to implementation, > otherwise we are not software makers and just duct taping hodge podge > together.
So there is a canonical form to bridge implementation. That explains why all bridges look the same. No? I studied both Computer Science and Civil Engineering and for Structural Engineering in second year we had to design and build a bridge to support 1 tonne over a 1m span using steel L-section and plate of various sizes. During the design stage one student asked the lecturer what the "right" answer was. He got a scathing reply that there is no right (canonical) answer in engineering. Rather, there are endless possible solutions, some are better than others, some are not fit for purpose, and all trade off different things. I think software engineering is exactly the same, although with much less history and consequently a less mature body of knowledge. To say software should have a canonical solution like building or bridge engineers is to misunderstand the nature of both software and civil engineering IMO. Regards, Ben -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Arjang Assadi Sent: Friday, 26 February 2010 9:05 AM To: [email protected]; ausDotNet Subject: Re: Business Rules , what are the Tools/Methodologies to categorise/Implement them in .net? I wish I could agree with that, but how does what we as software engineers do differs from the building or bridge engineers, surely they don't build bridges or building on what "they" perceive to be the right way. Surely there must be some sort of canonical form to implementation, otherwise we are not software makers and just duct taping hodge podge together. Every (software) system will gravitate towards maximum entropy and minimum order and the programmer's job is to stablised it by imposing order and decreasing the entropy. Having a structure for defining how a system should be implemented would reduce the number of possible permutation and hence decrease the entropy. I believe a systematic approach to defining and implementation is necessary other wise we are just adding to total sum of junk in the world. Regards Arjang On 26 February 2010 11:21, silky <[email protected]> wrote: > On Fri, Feb 26, 2010 at 11:07 AM, Arjang Assadi <[email protected]> > wrote: >> what are the Tools/Methodologies to categorise/Implement business >> rules in .net? > > Honestly, isn't *every* rule a business rule? > > Shouldn't you just handle it via, you know, development?! And then > test it via unit testing? I don't understand all this timewasting > rubbish about spec'ing it out in some language that you then need to > test in-and-of-itself and then have that generate it in yet another > lower language. > > You haven't solved anything with that approach anyway. You've just > shifted your problem. It's good sometimes, it's bad sometimes, it's > not an answer to the underlying issue that to implement "Business > Rules" you need to: > > 1. Understand them > 2. Know how to program them > 3. Test them > > This is our job - this is the purpose of programming. Converting ideas > into things, and things into useful things, working things, correct > things, and fun things. > > >> There are just too many combinations / degrees of freedom in >> translating business rules into implementation, but surely by now a >> more holistic has come to being, anyone knows where or how to find >> them ? > > Yes - your brain. It is the translation mechanism. > > >> Regards >> >> Arjang > > -- > silky > > http://www.programmingbranch.com/ > This email is intended for the named recipient only. The information it contains may be confidential or commercially sensitive. If you are not the intended recipient you must not reproduce or distribute any part of this email, disclose its contents to any other party, or take any action in reliance on it. If you have received this email in error, please contact the sender immediately and delete the message from your computer.
