Today I ran across this very interesting article from 1987 by Frederick P. Brooks, Jr. (of "Mythical Man-Month" fame).

No Silver Bullet: Essence and Accidents of Software Engineering is a very readable review of the idea of software engineering -- of processes to enable the creation of better software programs.

It's worth reading by any developer, but I'm posting it here because of his comments on "graphical programming." It reminded me immediately of some past comments by Josh on using a graphical metaphor to make programming easier to get right.

Brooks is skeptical:

Whether one diagrams control flow, variable-scope nesting, variable cross references, dataflow, hierarchical data structures, or whatever, one feels only one dimension of the intricately interlocked software elephant. If one superimposes all the diagrams generated by the many relevant views, it is difficult to extract any global overview.

In a clash like this one between "it needs to be done" and "it's really hard," both expressed by people who know what they're talking about, where do you place your bets?

In general, I think Brooks is right.

I do think, however, that there is one thing that comes close to a silver bullet:
In my experience, object-oriented programming is amazingly useful in combining code and data into one handy package. This greatly helps in understanding the architecture of non-trivial applications. It does not bring quite the order of magnitude in productivity Brooks defined as "silver bullet", but it is a significant improvement.

matrimony wrote:Hi guys.I accept your post.object orientated programming is a powerful for software language and it easier to develop software programing.Is it possible a using a graphical metaphor to write program easier?Please any one explain how it is possible.thanks Advance

If you're writing a complex program, it helps to break it down into parts. Start by listing all of the objects in your program; for example, if you were writing a library system (common example), your objects would be Book, User, Library.

These objects become your classes. Now draw the flow of the program in the form of a flowchart, such that each item in the flowchart is somewhere of the level of "add book" or "user returns book".

Each item then becomes a method. Break this down into smaller chunks, lather, rinse, repeat, and you essentially have your program before you know it.