How many prototypes do you throw away?

Started by
13 comments, last by GameDev.net 17 years, 5 months ago
How many prototypes have you typically thrown away when creating either a large application or an engine/library? I'm slowly working on an object oriented UDP/TCP network library in C++. I've been writing it in some form for a year or so (no time at home to work on it). I'm currently up to iteration 6, which is by the far the best design and cleanest code I've written yet. It doesn't do much as I'm still re-writing and re-designing the higher level classes. I'm re-using probably about 50% of the code/classes from the previous iteration as their functionality and design won't change. For whatever reason I've always found that I'm not that good at OO design for larger projects (ie. anything larger than a classroom lesson!). I know I can think in OO, but I tend to make mistakes when designing class hierarchies in terms of what inherits what functionality etc. I'm sure this won't be the final version as the more C++ and OO I learn, the more I refactor. I'm hoing this project can be added to my small portfolio for future job applications. So back to the original question: how many prototypes do you throw away? Thanks
---------------------http://www.stodge.net
Advertisement
Quote:Original post by stodge
How many prototypes have you typically thrown away when creating either a large application or an engine/library?

As many as it takes. However, in a large application or engine/library, the number of prototypes would be part of the plan.

John BoltonLocomotive Games (THQ)Current Project: Destroy All Humans (Wii). IN STORES NOW!
I never write the first draft using OO. That way I can focus purely on the logic.

Then when I've got it all hammered out, and the final form of everything solidifies in my mind, I go about wrapping it all in classes.

I just find it leads to less dead-ends and time spent working on class design (which I truly despise). Maybe I just suck at preliminary class design. :)
It all depends your attitude (or that of your team/company/whatever).

In the traditional corporate environment, you usually stick to the first design, even if it turns out to be bad. And if it doesn't work, you bend and twist it until enough bugs are introduced so that the side effects cancel each other out ;)

An agile programming team might not need to develop prototypes at all because the same is achieved through by constantly refactoring the code base. Instead of trying to come up with a design from insufficient informations, the optimal design will be found when development progresses into that area.

-Markus-

Professional C++ and .NET developer trying to break into indie game development.
Follow my progress: http://blog.nuclex-games.com/ or Twitter - Topics: Ogre3D, Blender, game architecture tips & code snippets.
Quote:Original post by stodge
I'm currently up to iteration 6, which is by the far the best design and cleanest code I've written yet.


And:

Quote:
I'm re-using probably about 50% of the code/classes from the previous iteration as their functionality and design won't change.


And:
Quote:
For whatever reason I've always found that I'm not that good at OO design for larger projects (ie. anything larger than a classroom lesson!).


Quote:
So back to the original question: how many prototypes do you throw away?

Thanks


So you've managed to do 6 iterations, all of which are an improvement on each other? And you've manage to re-use (reuse) 50% of the code? And you don't find you're good at OO design?

I can tell you that the only problem you're having (as far as I can tell anyway), is that you are working on a project with not enough experience (I call that learning by the way.) to do it the 'right way' from the start.

So how many 'prototypes' I throw away? I don't actually, I think of the design while coding, improving that design when it's not quite right yet and throwing away the things that just don't work. (Like my C++ templated Uber DataBase thing attempt)

The thing you need to be aware of is this: Set yourself a goal and a deadline and work to it. When done, reflect the lessons learned and start over. And if this is your a hobby, projects don't just get 100% done, cause there's always something else you can add or refactor, etc.


Next time I give my advice, I'll buy some bubblegum so I won't your kick ass!
If I'm designing a new feature, I will generally create one proof-of-concept that gets thrown away completely. It mostly serves as a chance for me to learn the tech behind the feature. We could call this version 1.

I will then create one prototype, call it version 2. I've basically worked on the design subconciously at this point. After the original proof-of-concept, I go on and do other things, like a mundane coding task, or my hour-long commute home, and let it sit in the back of my head (incidentally, this is how I write essays as well). This design is pretty heavy on OO and tends to grow very quickly.

That version gets heavily refactored, pretty much to the point where it is almost completely different from the first cut, I guess you could call it version 2.9. Most of the refactoring is centered around abstraction and refactoring duplicate code.

At that point, it will go into use and pretty much be copied verbatim into any quick projects that I have. In rare cases, I'll hit a point where I need to add a feature or five, and that sometimes requires a minor redesign, something that fits the major refactorings that I did to v 2 a little better. This redesign is typically the final version, something like v3.1. I haven't had anything go past a 3rd iteration yet.

If I have enough time to write unit tests for everything, I usually don't need the full 3rd iteration, and the current iteration is closer to v2.2 or something.

[Formerly "capn_midnight". See some of my projects. Find me on twitter tumblr G+ Github.]

Thanks for the replies - interesting reading!

"working on a project with not enough experience"

Exactly - I hadn't thought of that. Now you pointed this out I feel better about what I've done. Although each iteration isn't a vast improvement on the previous I'm learning enough each time to make it worthwhile. I still have a few design problems that need solving but each iteration is a step towards what I "think" is a reasonable design.

Cheers
---------------------http://www.stodge.net
I throw away as many prototypes as I have time to make. For my personal projects, this generally means all of them (so far) and for my professional projects, that typically means none.
"Walk not the trodden path, for it has borne it's burden." -John, Flying Monk
actually, I'd say in any sort of ongoing project is to always consider all of the code base to have sort of a "prototype character", that is: constant refactoring is key
One.

Any further changes are refactored. I figured a long time ago that when I start writing code in a large code-base, refactoring would be a much more useful skill to have than efficient prototyping. Of course, if my code's really bad (which was a common problem a couple of years ago), I would do a rewrite, but that's hardly prototyping.
[ search: google ][ programming: msdn | boost | opengl ][ languages: nihongo ]

This topic is closed to new replies.

Advertisement