Eric Barro
ebarro at verizon.net
Mon May 7 10:35:55 CDT 2007
Shamil,
I think that if you were to check with the principles of Agile Development
you will note that the goal is rapid application development (RAD) but not
at the expense of technical excellence and good design.
http://en.wikipedia.org/wiki/Agile_software_development
Specifically...
Some of the principles behind the Agile Manifesto are:
* Customer satisfaction by rapid, continuous delivery of useful software
* Working software is delivered frequently (weeks rather than months)
* Working software is the principal measure of progress
* Even late changes in requirements are welcomed
* Close, daily, cooperation between business people and developers
* Face-to-face conversation is the best form of communication
* Projects are built around motivated individuals, who should be trusted
* Continuous attention to technical excellence and good design
* Simplicity
* Self-organizing teams
* Regular adaptation to changing circumstances
--Eric
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Shamil
Salakhetdinov
Sent: Sunday, May 06, 2007 3:08 AM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Lazy, or Agile: that is the question... - Was Re:When
to Use a JunctionTable
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/c3761.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