Re: framework or not

On Wed, Oct 23, 2013 at 11:23 AM, Jim Giner <jim.giner@albanyhandball.com>wrote: > On 10/23/2013 12:34 PM, Larry Martell wrote: > >> On Wed, Oct 23, 2013 at 10:26 AM, Tedd Sperling <tedd.sperling@gmail.com> >> **wrote: >> >> On Oct 23, 2013, at 12:04 AM, Robert Cummings <robert@interjinn.com> >>> wrote: >>> >>> On 13-10-22 05:38 PM, Larry Garfield wrote: >>>> >>>>> If you need more convincing, I will cite Fred Brooks: >>>>> >>>>> qòˆäç >>>>> Û‹ ÛÙksshttp://www.cs.nott.ac.uk/~cah/**G51ISS/Documents/**NoSilverBullet.html<http://www.cs.nott.ac.uk/~cah/G51ISS/Documents/NoSilverBullet.html> >>>>> >>>> >>>> Excellent article, thanks for the pointer. So many assertions have stood >>>> >>> the test of time thus far. >>> >>>> >>>> Cheers, >>>> Rob. >>>> >>> >>> Yes, it was an excellent article. >>> >>> One of the things I liked about the article was the concept of >>> "Incremental Development", which is something I have practiced since the >>> Old Apple ][ days (Incidentally, he states he learned of this in 1958 -- >>> is >>> that a typo?). >>> >>> In 1977, I started many of my programs with (pardon my failing memory of >>> AppleSoft syntax): >>> >>> Gosub GatherData() >>> Gosub ProcessData() >>> Gosub PresentDate() >>> END >>> >>> It ran, but didn't do anything. Incidentally, that resembles a one-pass >>> MVC design, does it not? >>> >>> In any event, I would flesh out the code until I got what I wanted. >>> >>> Maybe that's one of the reasons why Android or iOS Development starts >>> with >>> a Default "Hello World" App that does very little than run. >>> >>> Start simple, develop complex. >>> >>> >> Is there any other way to do it? I've been programming since 1975 and >> that's what I was taught and that's how always do it. >> >> Was it Brian Kernighan who said the 3 rules of programming are: >> >> 1. Keep it simple. >> 2. Build it in stages. >> 3. Let someone else do the hard part. >> >> I like your comment Larry. Been doing that same approach myself since > just a little before that time. And the place that the development > cycle/life always bogs down is when we get to the hard part, isn't it? > Suddenly a smooth project with some very grandiose pieces of designwork > ends up behind schedule and getting patched together as we go slower and > the user has few new 'ideas' to add, thus slowing it even more. > That's why I only work as a contractor and get paid by the hour.