Gustav Brock
Gustav at cactus.dk
Tue May 8 08:47:54 CDT 2007
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