Main Area and Open Discussion > Living Room

Planning a major programming project - tips requested

<< < (3/5) > >>

skwire:
I just start randomly hitting the keyboard and hope it compiles at the end.   :D

app103:
Since most of my applications do have a GUI, I begin there, designing it in my head, imagining myself as the user and using the application mentally. When I feel comfortable with the mental image, I begin drawing it on paper, with notes as to what each control will do when activated and other text based notes about its unseen inner workings.

Then before I ever open my IDE, I give a full explanation of my idea to someone else that I consider an experienced coder. I highly recommend mouser's Idea Explosionifier, even if you want to keep things simple. It will help you to avoid coding yourself into a corner if you ever decide to add any of the plethora of additional features he will think up. Be careful though, it's easy to get caught up in the thought that you have to turn your project into the uncodable nightmare that will be produced by the Idea Explosionifier. You don't. You shouldn't. If you even consider trying, you'll just become overwhelmed and get discouraged and not even bother with the project. Just consider the future possibilities and make sure you leave room for adding them.

Then work on the GUI of your app only. Make a screenshot and run it through the Idea Explosionifier again. The results may be very different than before.

If this is going to be a large project, it's likely that the Idea Explosionifier will come up with about 10 years worth of ideas to keep your project alive.  :P

wraith808:
Since most of my applications do have a GUI, I begin there, designing it in my head, imagining myself as the user and using the application mentally. When I feel comfortable with the mental image, I begin drawing it on paper, with notes as to what each control will do when activated and other text based notes about its unseen inner workings.
-app103 (January 13, 2012, 11:44 AM)
--- End quote ---

From a different perspective, I design my UI last, and my data first.  Sometimes I find that GUI implementations can limit your functionality and data model by the fact that they are already constrained by preconceptions put in place by the UI.  Then once I have my data modeled, I base my UI design around the primary entrance point into the data, i.e. if it is something contact based, the primary entry point might be a person's basic data.

Taking that contact paradigm a little further to illustrate what I mean, I might design the contact form to have the address information built in if I start UI first.  If I start data first, then I might see that I have a need to have many addresses per user, so my UI design might then follow with the address information on some sort of container that can be changed out depending on which address is being utilized.

Just my .02.

Ath:
@Josh, any reply or reaction or are you just overwhelmed by all these nice responses? ;D :P

TaoPhoenix:
Okay, while it's not "programming", I have something worth at least 1.7 cents if not two cents.

For me, a bit of "dive in" needs equal parts of planning. I am redesigning an estimating database so that the new structure matches new accounting codes, but our lead estimator still wants it to look and feel like it does now so he can keep his throughput up.  

It depends on your intuition - right away I noticed variants on Many-to-One and One-to-Many logic puzzles. But rather like files in windows, you can't just make them "all the same name" so it calls for an intermediate shuffle step.

For me the big danger of big projects is that you can "fake it" some 75% of the way there, then a design decision just sinks you. If you spent a ton of time doing "similar steps" for all the cases, yeah, I'm no fan of throwing it all out.

Instead, what "feels like the scary part"? Maybe you know how 75% of the program is a snap, just requiring ... beverages... for motivation, but is some piece of core logic really brittle? The more interlocking stuff is, the more it risks creaking at the seams when you want to do Version 2.0 when a new feature becomes a Must-Have.

Navigation

[0] Message Index

[#] Next page

[*] Previous page