From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,c406e0c4a6eb74ed X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews2.google.com!not-for-mail From: kevin.cline@gmail.com (Kevin Cline) Newsgroups: comp.lang.ada Subject: Re: ADA Popularity Discussion Request Date: 30 Aug 2004 12:08:10 -0700 Organization: http://groups.google.com Message-ID: References: <49dc98cf.0408110556.18ae7df@posting.google.com> <4CsVc.28876$9Y6.4063@newsread1.news.pas.earthlink.net> NNTP-Posting-Host: 198.23.26.253 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1093892890 13812 127.0.0.1 (30 Aug 2004 19:08:10 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 30 Aug 2004 19:08:10 +0000 (UTC) Xref: g2news1.google.com comp.lang.ada:3180 Date: 2004-08-30T12:08:10-07:00 List-Id: Georg Bauhaus wrote in message news:... > Kevin Cline wrote: > > : The efficacy of much pre-code activity is debatable. Many > : organizations have had great success with more agile methods of > : minimal up-front design followed by test-driven development and > : continuous refactoring. > > Yes and even some tricks can be helpful to get something going. > But how can "refactoring" be done well without quite some thinking > and planning, that is without something that happens before coding? > Isn't "refactoring" sometimes a redesign of the modular structure of > some software? I wouldn't call this activity "coding". Most refactoring is local -- observing common code in two methods and collecting it into a new method. But sometimes, indeed, one sees that larger structural improvements would be beneficial. Following agile methods, you never undertake a gross rewrite of working software. Instead you make incremental changes to the code, testing after each change, until the desired new structure is achieved. It takes a bit of practice to learn how to get large changes done incrementally, but it can be done. So you design a little, code a little, and test a little until it's done. Rarely is there "quite some thinking and planning". I find that designing for a long time without coding, or coding for a long time without testing is like trying to driver a car while only looking at the road once every fifteen seconds. You tend to spend a lot of time getting back on the road.