Thread: A rather broad code design question

Sounds like you've reached the point where you've figured out that, in order to go on a trip, you must first stand up.

Designing entire systems from scratch is something that must be learned through practice. At this phase of your experience, it's probably better to take an iterative approach of designing a small sub-part, then implementing it, designing another sub-part, implementing it, etc... You may find that the pieces don't fit together elegantly, or at all. That's just something which comes with experience.

The point is to actually do something instead of getting mired in the design. Unless you actually write code you won't be able to learn what works and what doesn't.

Paraphrased from Fred Brook's book The Mythical Man Month: plan to throw the first one away -- you will anyhow.

Originally Posted by brewbuck

Sounds like you've reached the point where you've figured out that, in order to go on a trip, you must first stand up.

Paraphrased from Fred Brook's book The Mythical Man Month: plan to throw the first one away -- you will anyhow.

Side question: The above is how I used to approach systems where I did not have clear ideas on hard requirements and code structure...then over the years I have sort of adopted the test-driven development method which assures no extra code is written while at the same time you code everything you need. IOW you know when you are "done". Query: is this inappropriate for younger/less experienced coders would you say?

Originally Posted by jeffcobb

Side question: The above is how I used to approach systems where I did not have clear ideas on hard requirements and code structure...then over the years I have sort of adopted the test-driven development method which assures no extra code is written while at the same time you code everything you need. IOW you know when you are "done". Query: is this inappropriate for younger/less experienced coders would you say?

No, as long as it doesn't get in the way of writing code. It's never bad to learn how things are done in practice. But it's not beneficial if you deadlock yourself and don't end up doing ANYTHING.

Interesting. To me, this starts me writing code earlier than long drawn-out attempts to pre-document a system that I don't fully understand. Basically, writing an app to test a system I don't know helps sort out what functionality goes where plus what data structure needs what to work. Then when I have that, writing code to do what the test requires is simple and I know I am not missing anything.

And then I am done. ^__^.

Sorry did not mean to hijack the thread.