belize has asked for the wisdom of the Perl Monks concerning the following question:
I know that we use the old "Flow Chart" method through several revisions. We refer to this Flow Chart a number of times, and will even develop specific ones for parts of a subroutine.
I would also think that these flow charts would be invaluable when trying to understand what others are doing, or going back after sometime and trying to under stand what YOU did.
Any comments, ideas, suggestions on the most efficient and "correct" way to plan or map out software prior to writing? Anyone use software to plan (i.e. Visio).
BTW, in all the Open Source code that I have looked at, I have never seen a flow chart or map of the logical flow of the software.
|
---|
Replies are listed 'Best First'. | |
---|---|
Re: Planning your software before writing
by chromatic (Archbishop) on Jan 08, 2001 at 21:39 UTC | |
Certain industries where accuracy and reliability need to be mathematically proven may have different requirements. XP practitioners try to 'code by intent', where they write a test case for the feature they're about to add, let the test fail, then write code to make the test pass. That's design in the small. For design in the large, they write stories about the features the software needs. The customer arranges them by their value in the shipped product, and the team tackles them in that order. Design is done as-you-go, with a little up front investment in the basic architecture (the simplest that could possibly work), breaking a story down into programmer-afternoon-sized-tasks, and continually refactoring. That may or may not work for you, and it may or may not work for my latest project. We'll see. | [reply] [Watch: Dir/Any] |
by zigster (Hermit) on Jan 08, 2001 at 22:41 UTC | |
Formal design is required for the following (off the top of my head) reasons -- Zigster | [reply] [Watch: Dir/Any] |
by chromatic (Archbishop) on Jan 08, 2001 at 23:31 UTC | |
It's not that design is hard, though it is, it's that up front design is very hard. That's why projects like the Gimp, Apache, Mozilla, and Slashcode are all facing fundamental rewrites. They invested some time in design before they started coding, but the uses and needs of their software grew beyond their original design. They designed themselves into a corner. XP may or may not completely alleviate that -- it depends on your team's abilities. Instead, it says, "Design is good. Let's design all the time." To address more of belize's post below, I'd take something like the Ultimate Bulletin Board, and write stories like the following: I, for one, would rather spend my resources completing the first few stories than building a database, arranging the tables just so, then having to modify the tables and convert the code four or five times. I'll probably have to do it once or twice, but the simpler the existing code and design by the time it is absolutely necessary to add the database, the less chaos there will be. It's not a case of no design vs. full design, it's a case of design only as much as you need for the next two weeks vs. design everything. One last what if... what if you spent a week designing the interface to a billing system your customer might want in a year, then he tells you that they have decided to use an existing front-end and want you to work on a batchloader? (Design what you need right now.) | [reply] [Watch: Dir/Any] |
by Anonymous Monk on Oct 28, 2004 at 14:53 UTC | |
by dragonchild (Archbishop) on Oct 28, 2004 at 14:58 UTC | |
Being right, does not endow the right to be rude; politeness costs nothing. | [reply] [Watch: Dir/Any] |
by belize (Deacon) on Jan 08, 2001 at 21:53 UTC | |
How would you rank a project such as Infopop's "Ultimate Bulletin Board" which appears to be very successful and continually growing. Or John Cokos "Hyperseek" search engine which has grown over the lsat few years. If you are not familiar with either one: http://www.interactive-web.net Both of these appear to be small applications. But would require some heavy duty planning and documentation to maintain. | [reply] [Watch: Dir/Any] |
by puck (Scribe) on Jan 10, 2001 at 03:08 UTC | |
Every two weeks you have have a meeting with the customer. At this meeting you go over what has been completed. The customer then hands over the next set of stories and you only accept the amount of work you know you can do in two weeks. In this manner you never have all the stories, you only work in the here and now. There are more things to be taken into account here, but I won't bother with them at the moment... Cheers! | [reply] [Watch: Dir/Any] |
Re: Planning your software before writing
by KM (Priest) on Jan 08, 2001 at 19:41 UTC | |
There is a lot in between (I could probably do a book on dos and do-nots of real-world software design), but those are some highlights I have seen work well. Generally I don't like to use any flowchart software (unless someone else will maintain the flowcharts) because whiteboards are better (if you are luckly, you have a whiteboard that prints). I love walking into a room and seeing all the whiteboards marked up with the flow of a big piece of software!
Cheers, | [reply] [Watch: Dir/Any] |
by belize (Deacon) on Jan 08, 2001 at 20:15 UTC | |
I am coming from a little smaller company (9 employees) that are struggling to fill the niche of customers that have around 10-15k to spend instead of the 800k or more for the big boys. I have often wondered whether it is better to built something form scratch or to look for something that has already been done and modify it. The first way takes more time, but gives you exactly what you want. The other takes less time, but often does not give you what you want. Programming always seems to be a trade off between time, money,and functionality (maybe we should add reliability?). | [reply] [Watch: Dir/Any] |
by KM (Priest) on Jan 08, 2001 at 21:13 UTC | |
Well, that depends on what you find to build on. If you find something (or some things) that were well designed to build off of, it can save you time. If you download crap to use, then you have crap to work with. I once had to do a calendaring system.. I found a Perl one on Sourceforge (don't recall the name right now) and it was decently written, and had much of the functionality I needed, and was easily expandable (I added tons of things, and now use my version for my own personal use). So, in that case it saved time. Before finding that one I looked at another, which was crap, and I saw a long hard road ahead. I didn't start from scratch because of my task load, and I happened to find something very usable. Programming always seems to be a trade off between time, money,and functionality (maybe we should add reliability?). I say, let the managers worry about money (and maybe the time) and the programmers worry about functionality (reliability, readability, scalability, and all other bilities). If you happen to have a boss who isn't afraid to tell a customer 'it will take an extra two weeks, because we want to make sure it is a good piece of software now, rather than fix things later', all the better. Crap gets created when you have someone saying 'Well, just make it work they want it on Friday'. Personally, I think a programmer should say 'No, it will be done when it is right', but some value the paycheck to much :) Anyways, when you have the 1000 foot view, it is a good time to research what is available that can be a base to work from, IMO.
Cheers, | [reply] [Watch: Dir/Any] |
Re: Planning your software before writing
by merlyn (Sage) on Jan 08, 2001 at 20:39 UTC | |
Then I look at code reuse, and figure out what bottom chunks are already written for me, and start writing glue in between the top level and bottom level. If I'm missing low-level technology, I code that, trying to be general enough to solve this problem as well as the next couple of predicted revisions or reuses. I've written a lot of code in my life, so predicting reuse is pretty second nature. {grin} I run my program after adding about every 10 lines of code or so, stopping to insert print statements if it doesn't run right. I never have to look at more than 5 or 10 lines to debug then. The program becomes its own test harness. | [reply] [Watch: Dir/Any] |
by belize (Deacon) on Jan 08, 2001 at 21:27 UTC | |
I think this method might work well with small applications, but as move on to bigger things on the net, it appears to reach a limit of usefulness. Of course I am not in the same league as merlyn when it comes to programming perl. | [reply] [Watch: Dir/Any] |
Re: Planning your software before writing
by zigster (Hermit) on Jan 08, 2001 at 20:43 UTC | |
Hay ho one can of worms opened ;-) Software design is a very passionate argument and one that I cannot do justice to here so I will simply point you at the two techniques I use most frequently. Jackson Structured Programming (JSP), a mature yet simple (and so useful) method for showing program flow. I use this to produce a road map for subsections of an application. I believe it is talked about in code complete McConnell (A good book to have, even if it does not cover JSP, I am -pretty- sure it does) I had a quick look and found a cobol esq view of JSP Although it is cobol based it does describe the method well. UML, this is in vogue atm as an OO modeling language, however as I have said before OO is only a way to understand a problem. There is no reason an OO design -has- to yeild an OO solution. As you mention flow charts I have assumed that you are writting nonOO code. Do not eliminate UML as a modeling language you will not regret learning it. UML allows whole system modeling. It defines a number of diagrams from use case (that allow you to capture and present user requirements) to sequence diagrams that show the calling flow (they model a similar attribute as JSP). Take a look at For UML related resources . There are CASE tools to help you write UML Together , to be honest not appropriate for perl projects it is slow and tightly coupled to java/C++ a better option would be dia a gtk tool that really rocks.
If you want more references or more specific suggestsions then post again I have lots and lots ;-)
| [reply] [Watch: Dir/Any] |
Re: Planning your software before writing
by clemburg (Curate) on Jan 08, 2001 at 23:34 UTC | |
You will want to read Code Complete by Steve McConnell. One simple trick that this book taught me is to write a high-level, natural-language description of your task, comment it out, and write the code corresponding to each modular part of the description. This way, you even get comments for free. Another good thing is to acquire a feeling for when top-down styles (structured programming, most OO stuff, flow-charts, etc.) and bottom-up styles (interactive environments, rapid prototyping, tool development) of programming are appropriate. Unfortunately, this is very hard. Since most of today's techniques are top-down style, I think it is good practice to learn a functional programming language (Scheme, Lisp, Haskell, etc.), since these tend to encourage bottom-up style.
Christian Lemburg | [reply] [Watch: Dir/Any] |
Re: Planning your software before writing
by neophyte (Curate) on Jan 08, 2001 at 21:16 UTC | |
XtremeProgramming gives lots of information about the Xtreme Programming technique, complete with examples. neophyte | [reply] [Watch: Dir/Any] |
Re: Planning your software before writing
by extremely (Priest) on Jan 08, 2001 at 19:59 UTC | |
-- | [reply] [Watch: Dir/Any] |
Re: Planning your software before writing
by blueAdept (Beadle) on Jan 08, 2001 at 20:38 UTC | |
Flowcharts alone don't go very far with me, they leave a lot unsaid..up to your interpretation/guesswork. If all you have is the flow diagram, you need to delineate where/how the various tasks in the flow are implemented in the coded routines. | [reply] [Watch: Dir/Any] |
by belize (Deacon) on Jan 08, 2001 at 21:23 UTC | |
Is this documentation of data structres done within the code, or do you make it a separate document? Wouldn't it best to develop a system where flow charts and data structures flow from one document attached to the software? I am just surprised that I have never seen any of this with any Open Source software that I have looked at. | [reply] [Watch: Dir/Any] |
by blueAdept (Beadle) on Jan 09, 2001 at 07:52 UTC | |
I've also worked with scripts written by others that were so heavily commented that it would have been easier to understand without any comments at all. Everyone is slightly religious about how the prep work/documentation of their application is done.. | [reply] [Watch: Dir/Any] |