Programming design, how do you prefer it?
Author
Today I'm curious about how you prefer sorting out your personal programming tasks.
Do you try to measure the time of a task, before designing the implementation? Do you feel that the design process can be timed well?
Is formulating use cases to identify code organization, something for you? Or do you like basing things on previous experience better?
Which things do you design first, functions (conditions, pseudo code) or data types (e.g. object-oriented)?
Quote:Original post by Dim_Yimma_HTime is hard to predict with any accuracy, so I tend to use an iterative approach. Get a basic framework/prototype up and running within an hour or two, and just keep refactoring while implementing features.
Do you try to measure the time of a task, before designing the implementation? Do you feel that the design process can be timed well?
Quote:Is formulating use cases to identify code organization, something for you? Or do you like basing things on previous experience better?I think, with enough experience, both approaches merge together. I might explicitly map out some general use cases before hand, but mostly I have a feeling for the structure.
Quote:Which things do you design first, functions (conditions, pseudo code) or data types (e.g. object-oriented)?I start with getting something up on screen, be it a coloured quad, a textual dump, or a basic GUI - the idea is to have something which can be used to gain a visible measure of progress.
Quote:Original post by swiftcoder
the idea is to have something which can be used to gain a visible measure of progress.
Even though that visible measure can be really deceiving if you forget what's actually going on underneath. But I do the same - I get something on screen first, everything else comes later. Usually input is second, so that I can actually affect the state of the world. Printing text to screen is pretty high up, too, since it's annoying to always look in the console or log file.
Quote:Original post by Dim_Yimma_H
Do you try to measure the time of a task, before designing the implementation? Do you feel that the design process can be timed well?
I can't time it at all.
Quote:Original post by Dim_Yimma_H
Is formulating use cases to identify code organization, something for you? Or do you like basing things on previous experience better?
I write use cases if I get lost. Which happens once in a while. Usually my use cases are simply screen progressions or flow charts, though.
Quote:Original post by Dim_Yimma_H
Which things do you design first, functions (conditions, pseudo code) or data types (e.g. object-oriented)?
I start with a mix of top-down and bottom-up. I write the main game loop, partly in pseudocode, then I start on the rendering and input systems bottom-up, then everything kind of comes together (or should).
Author
Quote:Original post by swiftcoder
Time is hard to predict with any accuracy, so I tend to use an iterative approach. Get a basic framework/prototype up and running within an hour or two, and just keep refactoring while implementing features.
Yeah, iterative methods may be really useful! Personally I think it's nice to have that framework in a ready state so it's rather better or worse, than incomplete, at different points during the development.
Quote:Original post by lightbringer
Even though that visible measure can be really deceiving if you forget what's actually going on underneath.
That's really true. The event I fear the most is when/if I realize the stuff I see is worth nothing compared to the daunting redesign I need to do to get the next feature (and it might continue like that for several "features"). That's why I'm finding useful design more and more appealing, it's like an evasive maneuver around eventual disappointment [smile]
I believe it shouldn't be overdone though.
Quote:Original post by Dim_Yimma_HI have been going through this over the last few weeks, while developing simplui. It started as a collection of quick-n-dirty GUI elements to edit debug parameters, and has developed into a full-fledged proposal fro a GUI toolkit. Interestingly enough, through three major iterations of the backend rendering, layout and event handling, the user API has remained largely unchanged.Quote:Original post by lightbringerThat's really true. The event I fear the most is when/if I realize the stuff I see is worth nothing compared to the daunting redesign I need to do to get the next feature (and it might continue like that for several "features"). That's why I'm finding useful design more and more appealing, it's like an evasive maneuver around eventual disappointment [smile]Quote:Original post by swiftcoderEven though that visible measure can be really deceiving if you forget what's actually going on underneath.
Time is hard to predict with any accuracy, so I tend to use an iterative approach. Get a basic framework/prototype up and running within an hour or two, and just keep refactoring while implementing features.
I believe it shouldn't be overdone though.
The key point here is that I designed the API with one goal in mind, to be as simple and user-friendly as possible. I halfway expected to have to make major changes to the interface, in order to support other features, but the truth is that simplicity makes a very good goal for API design [wink]
I tend to share swiftcoders opinion on using an iterative method - I find it better just to dive in and get a basic framework up and running, then work through a predefined list of features/requirements and fix bugs/refactor as I go. I'm currently on the 3rd refactor of my networking API - there are still many more iterations to go but personally I find it better doing it this way than trying to overdesign an imaginary system without having any implementation to debug and tweak.
Now I'm not saying it's bad to have an idea in your head, it's not - infact without one you wouldn't get very far - it just strikes me as a massive waste of time to design every complex feature of your system in full before you really know if it's needed/going to work the way you expect. You might find that you don't even think about things that are essential, which in turn mean something else won't work the same, etc, etc. It's better to have a base to work from so you can see actual results of your changes and judge the outcome from more than just your imagination.
Now I'm not saying it's bad to have an idea in your head, it's not - infact without one you wouldn't get very far - it just strikes me as a massive waste of time to design every complex feature of your system in full before you really know if it's needed/going to work the way you expect. You might find that you don't even think about things that are essential, which in turn mean something else won't work the same, etc, etc. It's better to have a base to work from so you can see actual results of your changes and judge the outcome from more than just your imagination.
Author
About iterations, does someone have a good idea on how to predict iterations, or do they get all the time they require?
That's a good point which I'd like to agree with. I tend to believe that some experience of each part is needed to put them together in a good way. For example, I looked back on my first scene graph and noticed it was overcomplicated because I tried to connect technical features without testing them properly before.
Quote:Original post by Badgerr
It's better to have a base to work from so you can see actual results of your changes and judge the outcome from more than just your imagination.
That's a good point which I'd like to agree with. I tend to believe that some experience of each part is needed to put them together in a good way. For example, I looked back on my first scene graph and noticed it was overcomplicated because I tried to connect technical features without testing them properly before.
I tend to prefer an iterative approach, as others have suggested.
I disagree that "object-oriented" necessarily has to be "data types."
Quote:Original post by Dim_Yimma_H
data types (e.g. object-oriented)?
I disagree that "object-oriented" necessarily has to be "data types."
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
