Elizabeth.J.Doering at wellsfargo.com
Elizabeth.J.Doering at wellsfargo.com
Mon May 7 10:21:38 CDT 2007
Thanks, Shamil and all, for the education. I will be reading up on INSTEAD OF triggers. This list is amazing! Liz Liz Doering elizabeth.j.doering at wellsfargo.com 612.667.2447 "This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation" -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Shamil Salakhetdinov Sent: Sunday, May 06, 2007 5:08 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Lazy,or Agile: that is the question... - Was Re:When to Use aJunctionTable Hi Gustav, The point is agile development - to implement and to deliver ASAP requested *functionality*. Customers most of the time do not care how you achieve the result: there are exceptions but these are few - these *exceptional^ customers who force you to use this or that *development method(ologies)* are another subject and we can discuss it in another thread not here. <<< ... the client may call on others to judge your quick'n'dirty delivery... >>> No problem with that at all, Gustav. I can find many arguments to "defend" my agile position/approach: you know I'm a professional "old-school BDUF" developer with rich experience in this BDUF forcing a developer to foresee all the future change requests and requests for new functionality. Yes, I do know that customers change their mind often and I'm ready and I do know what to do to promptly convert/refactor "quick'n'dirty" solution to the "right" one... Therefore no problem with my customer calling other developers to check - if he will decide he needs "right" solution from the very beginning I will try to explain him that he will get it promptly when his business will urge for this "right" solution but currently, I will tell him, "quick'n'dirty" solution is all he needs.... Yes, my approach is risky but USD100 vs. USD300 for other solutions should make the difference for customer to charge me with this project. And this my sample case is just a sample and of course USD200 not a big difference but in real life case that could be EUR10,000 vs. EUR30,000 and one month of work until delivery vs. three months of work until delivery - that bigger financial and time difference, I expect you agree, will "play on my side"... <<< Second, programming should be fun >>> Agile development is a lot of fun, Gustav. Much more fun than BDUF or "right" development are. (I know what I'm saying having spent most of my development carrier working on projects using BDUF or "right" development methodologies) And agile development needs a good portion of courage - and when you see how you "refactor" this courage into useful delivered on time and on budget applications then you get even more fun from that software development business activity... And agile development is not easy. And it needs a lot of experience to be effective. I'm leaning it by doing my customers' projects. And it works. Still there are a lot to learn - in a nutshell agile is a natural for software development trial'n'error procedure but unlike traditional BDUF or "right" approaches agile constantly gives "perceivable" results and these "perceivable" results feedback is a fun also: everybody who worked on large projects could remember months (and years?) of design and development before delivery and who experienced such projects do remember that the more months (years) a project takes before delivery the less is the team and customers' optimism, the higher is the probability that the finally delivered software will not satisfy customers' business needs... And "right" solutions are also constantly changing - that is the fact, and the more "right" is the solution delivered using traditional development methodologies the less easier to refactor such "right" solutions into "proper" ones and then again to the "right" one and so on... Agile gives you experience and courage (and fun from this courage) I mentioned above to react promptly on change requests delivering new functionality when it's needed. And "right" and BDUF approaches do not give/do not develop in you this experience and courage. I know that Gustav and I know you know that too of course - the more complex software you develop becomes the less courage you have while fixing bugs in it or implementing new functionality, which results in changing existing code - "don't touch it when it works well to not make it broken" mantra is far from being called a "courageous developer slogan" :) And modern development needs a lot of courage because modern software is becoming more and more complicated and because change requests are becoming "a never ending storm" around you and a developer has to work in that "stormy environment" and deliver useful functionality in time and on budget... <<< Personally I hate when I have to make "quick" solutions - it happens - and such work may even tend to take longer time than it should. >>> Yes, Gustav - "been there seen that", well, I must say I'm still "one leg there and one leg here": I think this "hatred of quick'n'dirty solutions", which is still living in hearts of experienced software developers as you and me and many developers here are - this hatred comes from fear to fail to deliver "right" software on *fixed* time and budget, resulting in many hours of overwork, badly affecting private life and finances... But when "right" solution is getting fallen as "playing cards home" a few hours, days, months after delivery this sad picture results in even more hatred and fear not fun... I can be wrong, but I guess I'm not - this is what happened many times in the past with me and still happens, this is what described in many books on agile software development I read, this is what should happen with everybody except a few genius developers who I have never met/seen - have you? As for the subject and my proposal to use INSTEAD OF triggers for "agile database design and development" - I have searched Internet and as far as I see I'm not alone :) - well, of course I'm not talking about "silver bullet" - and I asked, dear all, in my first posting what weak positions you see in this approach: could it result in less reactive application system - very slow system reaction compared to the traditional "right" development/database design practices? I think that from financial point of view proposed agile approach is (much) more attractive or that point is also questionable? I assume that being experienced an agile developer will not fail to refactor his "quick'n'dirty" solution into the "right" one when needed on the same or slightly higher but in long run for sure considerably less time and budget. Less in long run because agile will deliver only what is needed not what "could be needed in the future". My search on Internet has returned these useful links - I did do this search after my first posting here: VIEWS: THE KEY TO DATABASE AGILITY http://www.tdan.com/i034ht03.htm Chapter 37 - Extending Triggers with INSTEAD OF http://www.microsoft.com/technet/prodtechnol/sql/2000/reskit/part10/c376 1.ms px?mfr=true Exploring SQL Server Triggers http://msdn.microsoft.com/msdnmag/issues/03/12/DataPoints/ Exploring SQL Server Triggers: Part 2 http://msdn.microsoft.com/msdnmag/issues/04/01/DataPoints/ Making use of INSTEAD-OF triggers in SQL Server 2005 http://articles.techrepublic.com.com/5100-9592_11-6113179.html As you can find if you read through the articles from the above links proposed approach could fail for large systems. But nobody did try to check how well/bad it will work for such large systems. If I will find free time in the near future I will try to check that but first I will try to collect all possible information on this subject to not waste time to "reinvent the (bad) wheel"... And of course similar agile "quick'n'dirty" approach can be applied by using stored procedures as an abstraction layer. In this latter case there is no doubts that there will be no any system reaction degradation but using SPs could be more laborious than INSTEAD OF triggers and what is also good with triggers from conceptual point of view is that they will *physically* belong to the objects(/VIEWs) depending on them - i.e. they will implement business rules for the business objects owning them... There are other advantages and disadvantages of views with INSTEAD OF triggers - you can read about them by following the above URLs... That's it for today. Your turn now :) Thank you. -- Shamil -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock Sent: Sunday, May 06, 2007 10:20 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Lazy,or Agile: that is the question... - Was Re:When to Use a JunctionTable Hi Shamil I see your point. The perfect solution that takes forever to implement is useless. However, it is my experience that once you've pinpointed if not the perfect solution then a "right" solution, it doesn't take that much longer to develop than a quick and dirty. Add to this two topics: first, the client may call on others to judge your quick'n'dirty delivery with the result that you are stamped as a non-pro. Second, programming should be fun. Personally I hate when I have to make "quick" solutions - it happens - and such work may even tend to take longer time than it should. /gustav <<< tail skipped >>> -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com