Flowcharts

[WingedPanther]

Kromagnon, for small projects that works fairly well. If you write your programs in a disciplined way, you can even make that work for somewhat larger projects. After a while, though, it all catchs up with you.

I remember when I made my Yahtzee program. I wrote it with no planning. Then I'd realize I needed another parameter in a function, and have to change ALL the function calls for that function. Then I'd make another change and do it again. Then I decided to add a new feature... and had to change a BUNCH of function calls. Repeat for a while. If I had planned it out in advance, I could have coded each call once and not had to search through all my code looking for bad function calls.

[Kaabi]

When writing a large program it's imperative to have a plan, and WingedPanther provided the perfect example. Sorry you had to go through that, must've been frustrating.

[kromagnon]

Oh, I know good and well that I SHOULD have a plan... I just don't do it because i'm lazy

[WingedPanther]

BTW, there are two flowcharting programs that I can strongly recommend. Dia (for both Windows and Linux), and Dynamic Draw (Windows only). Dia feels more like Visio, but Dynamic Draw has versioning capabilities and the ability to easily create custom icons. If people are interested in the flowcharting/UML tools I made for Dynamic Draw, I can upload them.

[brackett]

While a certain amount of upfront design is reasonable, delving into function signatures and such is way too detailed. In any moderately complicated system, you will *never* think of all the possibilities, no matter how long you spend diagramming. And, of course, as you're diagramming and coding, requirements change.

It's easier for both your code and your tools to allow for flexibility and changes after coding is started or even completed. By removing (or lessening) the "penalties" for getting the design wrong, you can adapt and change your code as you go. Test Driven Development (TDD) tries to minimize the cost of change by:

a. Extensive Unit Testing - which can drive a coherent design and/or API, and also protects you from breaking existing working code with new changes

b. Pair Programming - spot bugs and make design decisions with 2 people instead of 1

c. KISS/YAGNI (Keep It Simple, Stupid and You Ain't Gonna Need It) - keep code as flexible as possible by not including features that you don't need *right now*

d. Refactoring - keep code and design clean at all times, so that changing code is easy(er)

e. Continuous Integration - keep code buildable and testable at all times, so that you get immediate feedback on quality

f. Short Iterations - give customer's a chance as often as possible to give feedback and drive development and design choices

So, are flowcharts and UML up front worth it? Sure, if they help you through the big picture logic. Or if you use them to work out logic for a story or feature. But once they become "documents" instead of "sketches", or are encased in "requirements", or delve into function signatures - I think you've lost the big picture angle and agility.

[Blaze]

I always found flowcharts to just confuse me more. Sure i can see the merits, but are they a necessity>
They do tend to create a whole lot more paperwork.

[WingedPanther]

They can be important. I just got a new job doing documentation at a software company and one of my first tasks will be documenting one of the scripting modules. Being able to trace through the sequence of steps will probably make my life much easier, both for understanding and explaining.

Having said all that, I know a lot of people who prefer pseudocode to flowcharting.