[AccessD] Lazy, or Agile: that is the question... - Was Re:When to UseaJunctionTable

Shamil Salakhetdinov shamil at users.mns.ru
Tue May 8 16:58:44 CDT 2007


<<<
how can you prepare for *any* future change while at the same time perform
quick and lazy programming?
>>>
Yes, it sounds as a paradox Gustav but that is possible.
One example: I verbatim followed Kent Beck's now classical multi-currency
calculation sample application development where they start from simple
requirements and using unit testing and constant refinement of requirements
they finally get advanced and very flexible object model supporting
multi-currency calculations. I personally think that to design this object
model "right from the very beginning" an experienced OO developer would have
spent a couple of days. What they did to achieve the same result should take
a couple/four hours for experienced agile(/XP) developer - and by this
sample they also showed what means "to be prepared for any future changes" -
prompt reaction on new requirements with new version of software and being
100% sure that adaptation of existing software to the new requirements will
not break existing business rules if these are not changed by new
requirements...

<<<
normalized database structure - I have found to be the best way to prepare
for "any" future change,
>>>
Yes, and I'm not saying normalized stricture is bad - I'm just saying it
should naturally appear when first time needed because of requested new
functionality or because of the need to have such structure as being the
most effective to achieve requested level of the system productivity. If
requirements of higher system productivity or new functionality will never
come then highly normalized database structure will be never needed for a
certain project case i.e. it will be over engineering and waste of
resources...

<<<
and where I later was beaten by the poor design when changes were requested
>>>
Well, here is what an abstraction layer based on views (with INSTEAD OF
triggers) or stored procedures and UDFs is for - to minimize "poor design"
side effects when change requests come...

BTW, there are books published by respectful authors and publishers, which
prove that agile development and eXtreme Programming are not good/not
effective - one of them is:

"Extreme Programming Refactored: The Case Against XP" 
by Matt Stephens and Doug Rosenberg   
ISBN:1590590961 
Apress C 2003 


But many more are presenting/describing advantages of agile development...

What side to follow - here  everybody decides for themselves....

--
Shamil
 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock
Sent: Tuesday, May 08, 2007 5:48 PM
To: accessd at databaseadvisors.com
Subject: Re: [AccessD] Lazy,or Agile: that is the question... - Was Re:When
to UseaJunctionTable

Hi Shamil

OK, I think I understand you - and maybe not, because how can you prepare
for *any* future change while at the same time perform quick and lazy
programming?
Still, we may just be doing this lazy stuff here as we've never supplied a
model or database schema for a client, some don't even have any
documentation at all because the operation of the app is so straight
forward.

On the other hand, doing it "right" - and here I think of a (nearly)
normalized database structure - I have found to be the best way to prepare
for "any" future change, not that I have thought so much about it. 
I can think of a couple of examples from years ago where I had not done it
right (for example, but NOT for opening that discussion again, by using
"easy" natural keys!) and where I later was beaten by the poor design when
changes were requested.

/gustav


>>> shamil at users.mns.ru 08-05-2007 12:01 >>>
Hi Gustav,

I think we are still talking about different things: the key point of agile
in my opinion is to be always prepared to *any* change customers may wish to
implement in working deployed software. To *any* change not to *expected*
(by developer) change.

The more complicated modern software and database models and their
implementations become the less chances a developer has "to be a little
ahead of the client". Such being ahead just becomes impossible - read very
expensive both in time and money.

One partial solution of this issue are all kinds of application frameworks
and generic tunable vertical and horizontal markets solutions - ERP, CRM
systems etc. They are often all the customer needs but these solutions are
usually expensive for small businesses or are not flexible enough,
"heavy"...

Another solution is agile "lazy" development with its maxim to implement the
simplest possible solution, which satisfies current customers' needs and
which is affordable by customers' finances...

And experienced agile development practioner knows how to evolve such
minimalist "simple and lazy" solution into more complicated one while
refactoring it according to the change requests coming from customers as
they are getting more and more experience with this deployed "simplistic"
solution...

Modern agile solutions differ from past traditional (and even incremental
and iterative) way developed software grown from (phased) prototypes by
clean streamlined coding, clear software architecture, full acceptance and
as full as needed unit test coverage... - all that together with agile
development principles quoted here by Eric in another message make agile
solution promptly ready for any future changes not only for expected ones.
And without additional efforts to foresee these future changes. One can say
that there is no miracles and "free cheese" in this world - yes, I agree.
Where then agile gets time/resources to develop software code and structures
"ready for any future changes"? This "additional" time and resources come
from proven well organized automated agile software development process.
(Many good enough agile software development process automation tools are
free.) One of the "side effects: of this well organized process is that
agile developers are spending a way less time in debug mode. And everybody
knows that debugging/fixing bugs may take 80% of software development (I
mean its coding part) and that debugging is one of the toughest, less
predictable and most "unattractive" activities of software development. Is
here anybody who likes to spend hours in debugging mode? I doubts that (I
can be wrong).

Yes, creating child table takes a little but we are talking here not about
this simple case but about the difference of agile development and
traditional "right" development: 

Agile is ready to embrace *any* future changes and it handles these changes
with courage and fun, "right" development is trying to foresee future
changes - it often wastes resources by over engineering, it's followed by
"hatred and fear" of future changes because its attempts to foresee these
future changes often fail...

Gustav, I "have been there seen that" - I mean "right" development. And as I
noted before I'm still there in many projects but I'm also doing (trying to
do) other projects using (part of) agile approaches - and I see how well
they work - how they result in fun and courage and how they wash out "fear
and hatred"...

My postings in this thread is an exchange of ideas I currently explore to
find all "pro" and "contra" and to elaborate my own approach but mainly
based on agile principles for most of the future projects I will work on - I
have no doubt that agile principles will rule in the near future software
development..

Your turn now.

Thanks you.

--
Shamil
 
-----Original Message-----
From: accessd-bounces at databaseadvisors.com 
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock
Sent: Tuesday, May 08, 2007 12:24 PM
To: accessd at databaseadvisors.com 
Subject: Re: [AccessD] Lazy,or Agile: that is the question... - Was Re:When
to UseaJunctionTable

Hi Shamil

Charlotte can certainly speak for herself, but I think she wishes to stress
that doing it right the first time is optimum. And "right" - in my opinion -
is always to be a little ahead of the client. Your experience will tell what
the client's next step/wish could be, and then you program to be prepared.
To create a child table takes so little time for us so if I can foresee it
will be needed later, I just create it. What's more important is, that some
clients regard you as "the expert" and they expect you to be ahead of their
minds and to suggest possible improvements to their specifications.

I'm quite sure that this is the way you - and probably most of our fellow
listers - actually operate, so it is more a comment on the lazy "just create
in the fastest possible way what the client exactly requests without a
glimse on the future".

/gustav

>>> shamil at users.mns.ru 07-05-2007 18:35 >>>
Charlotte,

That would have been great if we have been able to develop a database model,
a software functionality,... once then deliver it and then forget it...

But "the only constant thing in the modern software development is the
constant change"...

--
Shamil

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com




More information about the AccessD mailing list