Printable View
I've heard this term alot, And in context it sounds like "I start writing something with an unclear end in sight, and it blows up into something totally different". Is this the meaning of the term? Also, what are some of your methods in planning/implementing programs? I seem to never finish anything because I can always "make it better".
Bill
Hi again. Ok then. Planning and design...
Here are some of the rules and religions I go by..
1. Everything starts with an idea, however cloudy or clear and present it may be, thats where they start, when they start is unclear. but what is clear is that you should note the idea down and get a few notes jotted down to back it up, so when you come to work more on it, youll know where youre at. I kind of work on them in my head a little (say about a week or so..) then start reviewing the finer details when ive ironed the logistics out in my head. If its a project that has been brought in by a seller or company that wants us to consult for them, well get toe the drawing board right away, but thats the general rule or how to map an idea. paper first.
2. After youve had the idea, start researching it. how is your idea going to be marketed or realised if its just home development project. every beginning has an end. thats a rule you cant ignore when researching. lookat what others have done. An idea is very rarely an origional one and thats a distinct advantage in this business, as you can quite happily freely look at other peoples work adn formulate your own ideas, its a standard practice and, with the information super-highway at hand youve got no problem finding info about your competition as they write about the features of their product to sell it, so they tell you how it works!!!
You can never do enough reseach. the more you do, the clearer the picture and the road youre going down becomes, the clearer the path is and, the more reseach you do, the clarity of your idea becomes clearer.
How is it going to look?
Who will use it?
How will they use it?
As a rule, i usually spend about a week or two on small projects of my own. although. Project Nexus (our current intranet & commerce server software suite we're developing, I took 5 months research into it, but thats huge.)
3. Development.
Now this is where people like yourselves get mixed up and take a wrong turn on the road. peeps often mistake development as the coding and "fun" process of getting your hands "dirty". It is, but not at this stage. Development at this stage is taking your idea to the drawing board. Mapping out its framework, the relational database diagrams, Client/Server relationship notes and diagrams, platform needs and requirements, GUI & API interfaces, etc.
Then after you have the visual development down and you have a clear visual picture of what its going to look like, the nmove to the coding, but not at the IDE yet!!!!
Next I would start by designing the pseudo framework and code. How will the code work and make your lookalike porsche into a driveable porsche, design your Components and Objects code ( opra rather a loose design of it anyways.).
Now if you step back, youll see you got all but a working model of your applicaiton, code, design and all. the thinkings done my man....
4. Implementation.
Now the fun starts. now you strt by making your designs real and code your classes, objects, design your forms and make your idea something you can touch. BUT it is easy to get ahead of yourself and leave your designs behind. Yes they will undego change and metamorphasis, just as the moth does, but dont stry from all the hard work. referr to your ideas regularly, make sure that the hard code is what its supposed to do adn whats the forms are supposed to look like intiially. This is how the frameworks built, how your porsche is going to be constructed and you dont want to get it wrong!! you dont want your porsche with a VW engine!!!
5. Run-time.
Afterall youve done, its time to run it and start seeing the results your worked hard for. rarely do you get them on first go, so you debug, make changes optimize and polish (not mould as youve done that..) you idea off. ths is where you "make it better" tweak it and shape it into your idea the way you want it to run.
Note: Thiis testing should be done in real time, and not in the IDE at all.
6. Deployment.
Youre done!!! go forth and revolutionise the world with what youve doen!!! and you deserve to as all the hard work youve put in, willpay off if you work hard at it..
for general rules on standards you should work to within the design process, se my signature for pointers.
If you stick to the guidelines, youllbe a killer developer adn be able to implement and design some slick stuff I can assure you. I generally teach this when I give lectures to first and second year degree and masters student on applied design and engineering in both software and hardware and its proven, as students who have left universsity keep in toucha d sing my praises for the work ive published and lectured upon...
Hope this helps
Kai :wave:
Thanks. That's what I was looking for in general. I have a brain that strays easily, and it isn't helped by the fact that I get such lovely requests as "Can you make a program that's easier to use than this one" and "Can you make it so a dummy can write a program in [proprietary machine programming utility designed by engineers FOR engineers.]" I have both the benefit and the curse of being given almost complete flexibility in design, but I find it tough to draw the line between ease of use, power, what users are familiar with, etc..
Bill
I dont think youre alon on this one bill. so dont feel all that bad.... :bigyello:
P.S. Rate the post!!! Need the rep points .. please.... :thumb:
Surely you are not serious. You lose all your debugging tools if you test outside the IDE. Debuging will take 10 times longer. If you have a decent tool at your disposal USE IT. When you are happy with it by all means send it out for testing on non-dev machines, but to ignore the debugging capabilities of the IDE is insane.Quote:
Originally Posted by kaihirst
We do both in my shop. The programmers test as they code. Once the program is compiled, we run another series of tests based on our Test Case document.Quote:
Originally Posted by kaihirst
Once that is done, the compiled program is turned over to our QA department, and they run the the same series of tests, based on a Test Case document, that we did, and they generally add some more cases to the Test Case document.
It only gets released to the customer once QA has signed off on it.
I'm with wossname on this. You have to test as you code and that is always done from the IDE (with no error trapping on...if it blows up, you need to know where. It is difficult to do that from a compiled .Exe). Once the code has passed the "IDE Test", then the error trapping is added, and it gets compiled.