Yes, John I absolutely agree.. Steve McConnell is **excellent**! I probably need to read some of his more recent books..but I took "Code Complete" to heart( Yeah, it is from Microsoft Press).
Depending on the scope and audience, I develop in a similar manner to yours. For complex formal projects.... In real language, I determine the problem in as few words as possible. I follow that with an elaboration much in the same way a news-paper report does (who, why , what, how, when). After I have a good idea of the project, I architect it. ... Organize it .. do my first wave of design (prototype).. psuedo code at module level (high level functions), convert that to code then... Again, psuedo-code at the lower functional level. I find that the psuedo code allows me better expression of what I intend to accomplish at any level (more complete, fewer unforseen conditions). The psuedo code gets either converted into comments or into what effectively is self-documenting code. The benefits are wonderful: straightforward code that matches the problem as best it can (excellent impedence matching), structure that is as simple as the problem will allow, and clear direction/comments on the intended goal of each feature (for the next person..which usually is me) The whole point is to think outside the limits of the programming language and slowly move things back in.... Which brings up another question.... HOW DO YOU COPE WHEN YOU'VE GOT TO CORRECT, DEBUG, or EXPAND someone else's sucky code? (SESC) What are some of the problems/issues you deal with to that effect...? CMB -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of John Hebert Sent: Monday, January 17, 2005 7:12 AM To: [email protected] Subject: designing software was Re: [brlug-general] $BIG_NUM (was Supporting Linux vs. Linux Zealotry) I tend to write a lot of pseudocode and create block diagrams on a whiteboard first before I touch the keyboard. I've found this reduces debugging time and helps me plan the architecture of the app better. Once I start writing code statements, the details of the language and object structure tend to distract me. John --- David Jackson <[EMAIL PROTECTED]> wrote: > I can understand that, but I, myself, don't seperate > the design from the > implementation. Mostly because I do both > interchangeably (I design some > rough form, and then implement it, and then design > more as I go along). > However, I probably spend more time debugging and > enhancing (hacking) > than I do designing and implementing. > > David > > John Hebert wrote: > > >--- David Jackson <[EMAIL PROTECTED]> wrote: > > > > > >I see your point, but I separate the design of an > >application from the actual creation of code > >statements. In my opinion, the design is the most > >important phase of software development. I think > that > >is what Edmund was referring to. > > > >A good book to read about this very topic is > "Software > >Project Survival Guide" by Steve McConnell > >(http://www.stevemcconnell.com). Heck, all the > books > >he's written are great. > > > >John > > > > > > > >__________________________________ > >Do you Yahoo!? > >The all-new My Yahoo! - What will yours do? > >http://my.yahoo.com > > > >_______________________________________________ > >General mailing list > >[email protected] > >http://brlug.net/mailman/listinfo/general_brlug.net > > > > > > > > > _______________________________________________ > General mailing list > [email protected] > http://brlug.net/mailman/listinfo/general_brlug.net > __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail _______________________________________________ General mailing list [email protected] http://brlug.net/mailman/listinfo/general_brlug.net
