[r1zla]

Hello everyone,

I was just wondering how all of you plan you application? I've always been more of a sit down and do something kind of guy. But unfortunately I'm finding that as I learn more VB.Net and start creating more complex code I end up going in circles and eventually hitting a creative snag somewhere along the line. I really battle with deciding what functions to make and whether they perform multiple or single tasks. (eg. One function to compare running processes and append them to XML or two, one for each.)

Does anyone have any suggestions?

[motcom]

Hi,

Always try and improve on what you are currently doing, investigate everything before hand, if you can.

This will apply not only to coding but how you can assist your client, your fellow programmers etc.

I normally follow this route:

1. Get 2 huge white boards, the more the better. Get lots of different coloured pens as well.(and some cleaning stuff to clean the board) AND a camera to take pics from the board.

2. Get all the info from your client, as much as possible about the project you are to write.

3. Study the info and question EVERYTHING YOU DO NOT UNDERSTAND, KEEPING IN MIND THINGS THE CLIENT MIGHT FORGET. If some one tells you "it will most probably not happen" then in your head it should mean "if it could happen once, it will"

4. Once thats done, look at the information that was given to you, every "Noun" (a word like House or Cup) will in most cases be a table in a database and/or a class in your applicaiton.

5. Decide on what the properties of a "Cup" are, like Size, color, is it full etc. Try and apply this to every noun.

6. Next try and figure out what the "Cup" can do (verbs i think), it can be filled, it can be washed etc. These will be mostly the functions that will be applied to the "Cup". These thinks will help you in designing the classes in your app. Trust me it's easier working with classes as there is so much code that will become re-usable later on..

7. Design a database (if a database is needed on the white board), Don't over normalize just keep a very good balance. And study the layout over and over, as changes made to a database on a later stage can be very cumbersome.

8. Design the Forms on the whiteboard to get a feeling as to how the layout should be, and how they would interact with the data, consider also color schemes icons and logos.

9. Present the Layout to the client and expain to the client as to how the screens would work, make sure you explain it well, the client might want change certain things or add more to your the application. You might even find that you understand the whole concept differently than your client. (We had that alot in our projects and it really sucks if you have to redo things - it causes major delays) Also try and work out as to how long it will take to code the project. Give a good estimation about each stage to yourself and add some more days to each part. In my project, there is no time limit, but the client will tend to get irritated. However we did not follow this plan from the start, this is just what i learned through experience. Try and keep to your time limit you set, if you do not make it, let the client know asap, and re-evaluate the time it will take to complete. Testing of an app can take a lot of time as well so bear keep this in mind.

10. Once you and your client are happy, start coding in small stages, don't code the whole thing at once. Also consider as to how many projects you want to have, deviding projects in to smaller peices have pro's and con's, huge projects tend to make visual studio go slow. MAKE SURE YOU INCLUDE ERROR HANDLING AT ALMOST EVERY ASPECT AS THIS IS MOST PROBABLY THE MOST CODE YOU WILL WRITE, THE USER IS YOUR ENEMY, HE WILL EXPECT EVERYTHING IS WORKING FINE AND WILL COME TO A PLACE WHERE YOU HAVE NOT DONE GOOD ERROR CHECKING AND WILL MESS WITH IT UNTIL IT WORKS AND SOMETIMES THEY NEVER TELL YOU AND YOUR APP WILL GET SERIOUS PROBLEMS LATER ON

11. Invite the client to have a look at what you currently have done. It's always good to reflect as to progress made.

12. Get someone to test your program - it must be someone who is not a programmer (My personal opinion) because if you actually sit next to a user working on your app, you will find they do things very differenty than you, the programmer. Most users do not know a lot about pc's and applicaitons. KEEP THAT IN MIND, YOU HAVE TO THINK FOR THEM.

13. Keep your filing up to scratch, you will have lots of notes etc. and it vital you keep them, the client must not come back to you and tell you "We discussed this and where it the notes on that".

Lastly if it does not work, revise the whole thing.

Once you get to a release version, you will have to think about licensing, help files, updates, web pages - selling your app, marketing. Deping on what will apply to you.

This is just how we do it, we have limited programmers and we are trying to complete our projects by the end of May. It took about 3.5 years and all new module we have written are made accoring to this plan. I think if we did this from the start, we could have halved the time it would have taken...

But hey, i am open for suggestions.....always try and improve on your ways of doing things......

[r1zla]

Thank you motcom, that was a detailed and helpful read. I always try to plan ahead but seem to get frustrated when I'm not actually typing the code.

[motcom]

I know the feeling, but trust me its worse if you have to redo things later on...

[r1zla]

I can imagine. I'm thinking of redoing my project but it seems like such a pain in the ass. I suppose its necessary though. I didn't plan very well at all... so now I'm stuck with functions that don't quite do what I want them to and generally very messy code.

Messy code for the loss.

[motcom]

Don't feel bad, we purchased the components from Devexpress and found a major improvement in speed, less code and way more powerfull than the normal windows controls, so we decided on replacing ALL windows controls in our project. Took us 2 Months to complete (2 programmers), but hey, was it worth it, YES for the app, but NO for the programmer - at least not for the copy paste part...

[r1zla]

I think thats what it always comes down to, whether you're a programmer, networker or any other career in the I.T. industry (sales reps don't count). At the end of the day its customer satisfaction thats the main concern. Programmers struggle to make the application easier and prettier for the end user to use and look at. Administrators struggle to set up and manage the domain and applications to make life easier for their users. On the up side... atleast we get paid for it

[motcom]

Yeah most definitely...

The rewarding part whilst programming:

Only once, when it works (you can only get it right once hey?)

The not so rewarding part:

When it does not work,
When it has to work immediately,
and the phonecall "I tried this and now the whole program is useless because I can't clear my date in a datetime picker",
The Program must do it not me - even if user input is required???

BTW, i get to travel a lot, all paid for so thats nice. (nice only if you are single)

[JackOfAllTrades]

Moving to Software Development

[r1zla]

Luckily I tend to work bugs out fairly quickly. But like you said, it only really works the way you think it should once. Then come all of the tweeks and added functionality. The worst part is finishing the application and then realising that one fundamental area was left out. I could kick myself, but on one of my earlier projects i forgot to include the application.startuppath in the xml file path. So the xml file had to be manually moved to mydocument/visual basic 2008/projects/"project name"/bin/debug etc... Painful experience that one.

Thanks JackOfAllTrades

[motcom]

Hey R1zla, just remember, you are in the IT world and you will constantly learn more stuff. The more open you are to suggestions, the better you can achieve...

[krismania]

wow impressive post at the start motcom, lots of detail and stuff was real helpful

anyway I think Im kind of a "sit down and do something" guy like r1zla but a strategy that somehow works for me is:

get the man bit out of the way
test
refine, change bits
test again
small extras(the part everyone loves )
test...again

go back to refine and go over and over until I have a moderatly complicated program. then I get confused, but I am confused easy ^.^

and like molcom said keep open to suggestions and you will learn heaps, no one knows everything

also lots of testing!! I debug after adding a new control and then build on it. allways build on it. once something works well, use it forever!!... and Improve it of course

This post has been edited by krismania: 15 March 2010 - 10:12 PM

[no2pencil]

I think this would be a great read on the front of the site : Featured!

[krismania]

oh cool its featured now thanks no2pencil!!

[benbarian]

When I first started coding our text book gave some really good advice on planning. How every program had to be planned out in three phases, Design the Forms (drawing the pictures/diagrams of what it should look like), then listing every object you need with it's various properties in a table, and lastly a table listing every event and the procedures need to make the event happen. Then as you work you constantly have the whole program listed in it's various parts. It becomes very easy to plan when to do what and to see what's been done and what hasn't