Shamil Salakhetdinov
shamil at users.mns.ru
Thu Aug 18 14:13:20 CDT 2005
> Both are into highest-level improvisation, working from a basic set of rules > that can combine in thousands of ways. XP DOES base its core practices on improvisation and basic set of proven rules/patterns, which can be combined in thousand ways! And it's well known that high level improvisation is "1% inspiration, and 99% perspiration."... > So perhaps you may think that I am contradicting myself, but I don't see > it that way Yes :) > If we have to rewrite, the design was wrong. We should > simply accommodate, adding a new bedroom if required but not changing the > structure of the house and neither betraying its aesthetics. I think that XP and true Classical (Behavioral) OOD&P gurus have knowledge and experience I, mere mortal, still to try to get acquired and used in my practice. They do state the way they work will not create any problems with adapting software to the constantly changing business and customer requirements. They do have experience in real life projects with very impressive results - read the book "MS Object Thinking"... Just think - they create low coupled, highly cohesive (with a few exposed methods) "interlligent" objects. These objects are independent and they just react predicted way (because their functionality is unit tested "to death") on external signals/messages. They subsribe to/know about/react on only the known for them signals/messages. They do use proven design patterns to combine all that stuff.... The often methaphor they use to explain how this system works is a traffic light on crossroad and cars and pedestrians - they are all independent - they just react on traffic light signals - and this system works very well... > Look at Habitat. Listen to Track 3 on the first Shakti CD. These are my > goalposts. Will do, thanks! Shamil ----- Original Message ----- From: "Arthur Fuller" <artful at rogers.com> To: "'Access Developers discussion and problem solving'" <accessd at databaseadvisors.com> Sent: Thursday, August 18, 2005 10:25 PM Subject: RE: [AccessD] OT(?): Big Design Up Front (BDUF) vs. XP any comments,ideas, experience? > Good reply, Shamil. I am not a fanatic (at least I don't think so LOL), but > I AM very big on BDUF -- this opinion qualified by the realization (as > captured in a famous N.A. ad wherein the guy tells you that GoodYear does > tires but now tune-ups as well. So we are caught between rock and roll and > and a hard disk: by the time you write the software, the company is in a new > business. No doubt about it, this happens! And more than once to me. > > So the architecture has to be something like the correct way to design a > house: you should be able to add rooms at any moment without destroying the > scheme. Your next child might be triplets, which would in time radically > alter the design of your home. > > Without wanting to lead this thread too far astray, I will mention that my > two principal influences in software design are Moshe Safde and Zakir > Hussain, the former the architect who designed Habitat and many other great > buildings, the latter probably the greatest tabla player who has ever lived. > Both are into highest-level improvisation, working from a basic set of rules > that can combine in thousands of ways. Habitat, IMO, is one of the greatest > edifices ever built. And Zakir, in the realm of music and more specifically > drumming, is without parallel. These two men are the goalposts of my > software ambitions. > > So perhaps you may think that I am contradicting myself, but I don't see it > that way. Architecture locked in space and time is dead. It must be as fluid > as improvised music -- and more importantly to this discussion, so must > software. Software must be designed with the anticipation that you will have > another child next year, and be ready to bend and fold and otherwise enhance > said child's life. If we have to rewrite, the design was wrong. We should > simply accommodate, adding a new bedroom if required but not changing the > structure of the house and neither betraying its aesthetics. > > This is not simple to do. I appreciate that. I mention it as my goal not my > resume. Now and then I have come close. That is the best I can say. I am > neither Safde nor Hussain. > > Look at Habitat. Listen to Track 3 on the first Shakti CD. These are my > goalposts. > > Arthur > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Shamil > Salakhetdinov > Sent: August 18, 2005 1:15 PM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] OT(?): Big Design Up Front (BDUF) vs. XP any > comments,ideas, experience? > > <<< > I am _way_ big on BDUF! Avoid coding until the last possible moment -- > that's my motto. > >>> > Arthur, but what you described and you said "it worked brilliantly" - this > is more XP than anything else, isn't it? > > Yes, I understand you're writing specs and you do a lot of upfront design - > it may happen it's not needed to do them that much upfront? > I'm not XP advocate (yet) - I'm just learning it and yet to see really big > projects developed this way but my feelings are that it's very promising and > it should give higher percent of positive results than BDUF does give - 60% > of projects fail, many go a way out of budget etc. - these are > statistics... > > No, I do not want to make "BDUF vs. XP" yet another "religious" debate > here - I'm trying to find my best way "in between" of these two working > approaches by sharing my experience and by acquiring yours... > > Shamil > > ----- Original Message ----- > From: "Arthur Fuller" <artful at rogers.com> > To: "'Access Developers discussion and problem solving'" > <accessd at databaseadvisors.com> > Sent: Thursday, August 18, 2005 8:21 PM > Subject: RE: [AccessD] OT(?): Big Design Up Front (BDUF) vs. XP any > comments,ideas, experience? > > > > About a decade ago I headed a development team for an insurance company. > > Half the job was to take some mainframe programmers and acquaint them with > > PC development tools and best practices. XP was not a big thing then, but > I > > improvised an approximation of it at that time. I started with 2 > > programmers, and had them sit with me as I coded. They were learning lots > of > > things at once -- syntax, editor keystrokes, shortcuts, etc. At first I > was > > moving so quickly that they couldn't even see what I was doing > (particularly > > in the editor itself), but a few explanations and we were over that hump. > > The hardest thing to teach them was "1 proc does exactly one thing"... No, > > upon reflection, the hardest thing to teach them was "avoid coding until > the > > last possible moment." The first two programmers then took on a programmer > > each and repeated the "semester", as it were, and then those two took on a > > programmer each. By the end of the project, we had a team of capable > > programmers, and we stuck to the rule of "two programmers per keyboard" > all > > the way through the project. It worked brilliantly -- about equivalent to > > debugging while writing the code. The second programmer might watch the > > first start a recursive routine and say, "Hey, wait, let's break it out > into > > two routines and avoid the recursion problems." They might kick it around > > for a bit before choosing one or the other approach, and also document why > > they elected that choice. > > > > I am _way_ big on BDUF! Avoid coding until the last possible moment -- > > that's my motto. I started out as a cowboy coder, but no more. I spend a > > _lot_ of time db-design tools such as DeZign, and I don't even begin > > creating sample data until I've been through about 3 revisions of the > given > > DB design. Then I write use-cases describing each function the software > must > > perform, using English not pseudo-code -- in fact, I have learned to avoid > > any specific references to tables, and instead to write such statements > as, > > "When the user selects a product and quantity she wishes to buy, place a > > 5-minute hold on that quantity. When the user's credit card payment is > > authorized, deplete inventory by the specified quantity and remove the > > hold." > > > > Once the DB design is finalized, and the purpose of each table, view, > sproc > > and UDF described, then even a relatively new hire can take the spec > > described above and implement it easily. In the example I gave, there are > > the following steps: > > > > 1. Obtain the product ID and desired quantity > > 2. Check to see said quantity exists (we'll sidestep the issue of > > back-orders for now). > > 3. Place a hold on said quantity, with a timer mechanism of some sort (SQL > > Server is great at this, much better than an Access timer). > > 4. Obtain the credit card info, fire it off and check the return status. > > 5. If the payment went through, deplete the quantity available. > > 6. Remove the hold. > > > > Each of these steps can be reduced to exactly one procedure. You (as > > manager) could even assign each step to a different programmer. So long as > > the DB design is solid, there should be no issues. > > > > I haven't read either book you mentioned, but I'll put them on my list of > > things to read. > > > > Arthur > > > > -----Original Message----- > > From: accessd-bounces at databaseadvisors.com > > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Shamil > > Salakhetdinov > > Sent: August 18, 2005 5:50 AM > > To: !DBA-MAIN > > Subject: [AccessD] OT(?): Big Design Up Front (BDUF) vs. XP any > > comments,ideas, experience? > > > > Hi All, > > > > I've got this this today from JoelOnSoftware subscription list: > > > > <<<<<< > > "As I worked through the screens that would be needed to allow > > either party to initiate the process, I realized that Aardvark > > would be just as useful, and radically simpler, if the helper > > was required to start the whole process. Making this change in > > the spec took an hour or two. If we had made this change in code, > > it would have added weeks to the schedule. I can't tell you how > > strongly I believe in Big Design Up Front, which the proponents > > of Extreme Programming consider anathema. I have consistently > > saved time and made better products by using BDUF and I'm proud > > to use it, no matter what the XP fanatics claim. They're just > > wrong on this point and I can't be any clearer than that." > > > > - From my latest article: > > > > The Project Aardvark Spec > > http://www.joelonsoftware.com/articles/AardvarkSpec.html > > >>>>> > > No comments. > > > > It happened that I'm currently reading: > > > > "Microsoft Object Thinking" > > by David West > > ISBN:0735619654 > > Microsoft Press C 2004 > > > > and > > > > "Extreme Programming Adventures in C# " > > by Ron Jeffries > > ISBN:0735619492 > > Microsoft Press C 2004 > > > > These two books are from Microsoft Press and they have a lot of useful > > information on eXterme Programming, Unit Testing and Classical(Behavioral) > > vs. currently existing in most implementations "real life" UML-based(RUP) > > OOD&P. > > > > When MS Press publishes books on such more computer-science than > > used in real life projects subjects then they are very probably > "cultivating > > the ground" for the soon to become true "dreams". (I remember I watched a > > movie "Microsoft, Year 2004"(form MS of course) somewhere in year 1995 or > > so - and as I see now their by that time science-fiction is now real-life, > > exactly in year 2004-2005. > > > > I must say I impressed with both books (and there are just a few technical > > books I liked because most of them are just "chewing" MSDN or other docs > > without almost any new ideas). > > The more I read them the more I like them and I see a lot of sense in what > > is written in them and I see a lot of my own ideas and experience are > there > > too. I'm glad my thinking is in the mainstream (of course what they say > is > > much more elaborated and thought through and based on their own rich > > experience). > > > > So my guess/thinking is that XP, Unit Testing and Behavioral (Extreme) > > OOD&P are becoming mainstream for real-life development of the projects of > > any size - in fact as authors of these books state (based on their > > experience) that the stuff they are writing about is the "only" agile way > > to solve the challenges of nowadays customers and projects requests. And > > they are not fanatics I think - they base their writing on deep analysis > of > > all the previous 50 years experience in software development and not only > in > > software - "Microsoft Object Thinking" is more philosophical than > > technical book and it has quotes from Plato (year 400 B.C.) - these quotes > > are used to explain how to "attack" complicated/vague projects' > > requirements... > > > > > > What do you think about the subject and related issues? > > > > Do we need Access/VBA Unit Testing added here - > > http://opensourcetesting.org/unit_misc.php (Open source tools for software > > testing professionals) - it can be done - does it make sense? > > > > Shamil > > > > -- > > AccessD mailing list > > AccessD at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/accessd > > Website: http://www.databaseadvisors.com > > > > -- > > AccessD mailing list > > AccessD at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/accessd > > Website: http://www.databaseadvisors.com > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com